From ekr@networkresonance.com Tue Apr 7 08:44:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2003A69E3 for ; Tue, 7 Apr 2009 08:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNOfyyMFyiaR for ; Tue, 7 Apr 2009 08:44:05 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 320583A6CB5 for ; Tue, 7 Apr 2009 08:44:05 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id BF787124C21; Tue, 7 Apr 2009 08:46:07 -0700 (PDT) Date: Tue, 07 Apr 2009 08:46:07 -0700 From: Eric Rescorla To: Stefan Santesson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090407154607.BF787124C21@kilo.networkresonance.com> Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2009 15:44:05 -0000 Stefan, As we discussed in SFO, I think this is a good idea, but I would generalize it a bit. Your current syntax only supports cert caching. I would add one more level of indirection: enum { cached_information(TBD), (65535) } ExtensionType; enum { certificate_chain(1), trusted_cas(2), (255) } CachedInformationType; struct { HashAlgorithm hash; opaque hash_value<1..255>; } CachedInformationHash; struct { CachedInformationType type; CachedInformationHash hashes<1..2^16-1>; } CachedInformation; Note that this also supports the minimal level of hash agility we discussed in the meeting. -Ekr From Nicolas.Williams@sun.com Tue Apr 7 14:56:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F283A685B for ; Tue, 7 Apr 2009 14:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uFejXydzFcP for ; Tue, 7 Apr 2009 14:56:19 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 076F93A6C9B for ; Tue, 7 Apr 2009 14:56:18 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n37LvPdu012276 for ; Tue, 7 Apr 2009 21:57:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n37LvOEt012740 for ; Tue, 7 Apr 2009 15:57:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n37LeY8V006091; Tue, 7 Apr 2009 16:40:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n37LeXDP006090; Tue, 7 Apr 2009 16:40:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 7 Apr 2009 16:40:33 -0500 From: Nicolas Williams To: Dean Anderson Message-ID: <20090407214033.GK1667@Sun.COM> References: <20090324231250.GQ9992@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090324231250.GQ9992@Sun.COM> User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2009 21:56:20 -0000 On Tue, Mar 24, 2009 at 06:12:50PM -0500, Nicolas Williams wrote: > The only things missing then would be: > > - how to put SAML/whatever authorization elements into Kerberos V > tickets and PKIX certificates > > - how to use SASL in TLS > > The latter is a variant of "how to use the GSS-API inside TLS", and that > has been controversial and has never progressed within the TLS WG. IIRC > the controversy arises from the fact that the GSS-API supports > arbitrary round trips, and the same is true of SASL -- so you're likely > to run into the same issue. > > However, I think we might be able to do something about that: ride some > of the SASL/GSS-API messages in TLS handshake extensions and complete > the SASL/GSS-API authentication exchange after the TLS exchange > completes if the SASL/GSS-API mechanism requires further round-trips. > Such a protocol would only be usable by applications that support such a > protocol as that'd not be "TLS" -- but consider how many SASL apps run > over TLS. Though, I should point out, this would be negotiable as it's merely an optional round-trip optimization for the application protocol. It's only applicable when it is safe to defer integrity protection for inital application protocol messages. This extension that I'm proposing is a therefore a bit more general than TLS+SASL or TLS+GSS-API. So I see several documents: 1) An extension to TLS client and server hello and handshake messages for carrying application protocol messages that can safely have integrity protection delayed. 2) A document describing how to use (1) with SASL and the new SASL/GSS bridge to get SASL and GSS-API authentication in TLS applications in a round-trip optimized fashion. 5) A document describing a Kerberos V authorization-data element by which clients and KDCs can transport SAML assertions. 4) A document describing a PKIX certificate extension for carrying SAML assertions. Combined with PKU2U (a GSS-API mechanism based on PKIX) you'd get both, CA- and client-asserted SAML assertions. (Yes, using PKU2U over TLS would be wasteful, but you'd do it once and use session resumption. Also, it's a small price to pay for an unencumbered protocol. > A bit roundabout. But I don't see how there could exist patents that > cover this, short of submarine patents by really clever people or > submarine patents filed by someone who overheard early discussions of > putting SAML into Kerberos some three or so years ago. Also, IIRC Martin Rex and I discussed something like the above in a jabber room for one or more WGs several IETF meetings ago. I.e., there have been descriptions of this idea in IETF fora, which ought to preclude patents covering it (but IANAL). Nico -- From dean@av8.com Tue Apr 7 16:53:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917123A69AA for ; Tue, 7 Apr 2009 16:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5fYw0Zpvx4c for ; Tue, 7 Apr 2009 16:53:15 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 7D0193A697D for ; Tue, 7 Apr 2009 16:53:15 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n37NsKnF025496 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Apr 2009 19:54:20 -0400 Date: Tue, 7 Apr 2009 19:54:19 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2009 23:53:16 -0000 Eric Rescorla says email "problem" fixed... ---------- Forwarded message ---------- Date: Tue, 7 Apr 2009 14:30:21 -0400 (EDT) From: Dean Anderson To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? What was the result? Is there interest? --Dean On Tue, 24 Mar 2009, Eric Rescorla wrote: > Discussing this topic at a meeting is pretty much a prerequisite > to deciding to work on it. A number of people followed up to say > they had interest in this topic, but I haven't had any requests for > agenda time as of yet. If there is someone in SFO who wants to > talk about this on Thursday, please e-mail me. > > -Ekr > > > On Tue, Mar 17, 2009 at 8:55 PM, Eric Rescorla wrote: > > Hi folks, > > > > As you may know, the IESG declined to advance > > draft-housley-tls-authz as PS. However, during the > > IETF Last Call, there were some expressions of interest > > in work in this general area, for which the TLS WG > > would be the appropriate venue. > > > > The TLS WG is meeting at IETF 74 in San Francisco. > > If there are people who want the TLS WG to take on > > work in this area, this would be the appropriate time > > to ask for agenda time to discuss it. > > > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Nicolas.Williams@sun.com Tue Apr 7 22:37:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3727E3A6967 for ; Tue, 7 Apr 2009 22:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.509 X-Spam-Level: X-Spam-Status: No, score=-5.509 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGXw+R7V7wbn for ; Tue, 7 Apr 2009 22:37:37 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 19B063A6893 for ; Tue, 7 Apr 2009 22:37:37 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n385chdi010180 for ; Wed, 8 Apr 2009 05:38:44 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n385ch0a045039 for ; Tue, 7 Apr 2009 23:38:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n385LqO0006324; Wed, 8 Apr 2009 00:21:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n385Lp0U006323; Wed, 8 Apr 2009 00:21:51 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 00:21:51 -0500 From: Nicolas Williams To: Dean Anderson Message-ID: <20090408052151.GH1500@Sun.COM> References: <20090324231250.GQ9992@Sun.COM> <20090407214033.GK1667@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090407214033.GK1667@Sun.COM> User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2009 05:37:38 -0000 On Tue, Apr 07, 2009 at 04:40:33PM -0500, Nicolas Williams wrote: > Though, I should point out, this would be negotiable as it's merely an > optional round-trip optimization for the application protocol. It's > only applicable when it is safe to defer integrity protection for inital > application protocol messages. This extension that I'm proposing is a > therefore a bit more general than TLS+SASL or TLS+GSS-API. I missed a problem: channel binding can't be done through the normal GSS (and now SASL) method because the channel binding data will not be available at that time. Channel binding can still be done using MIC tokens, but this adds between 1/2 and 1 round-trip (and this is tricky to do with SASL). Not fatal, but any proposal needs to address this. Nico -- From sshen@huawei.com Wed Apr 8 00:34:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED923A659C for ; Wed, 8 Apr 2009 00:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 475RICSDUuwX for ; Wed, 8 Apr 2009 00:34:47 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B0F4E3A68B0 for ; Wed, 8 Apr 2009 00:34:46 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHR006H9UFF30@szxga02-in.huawei.com> for tls@ietf.org; Wed, 08 Apr 2009 15:35:39 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHR003L9UFF4U@szxga02-in.huawei.com> for tls@ietf.org; Wed, 08 Apr 2009 15:35:39 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHR00M9EUFEJ7@szxml06-in.huawei.com> for tls@ietf.org; Wed, 08 Apr 2009 15:35:39 +0800 (CST) Date: Wed, 08 Apr 2009 15:35:38 +0800 From: Sean Shen In-reply-to: <20090407214033.GK1667@Sun.COM> To: 'Nicolas Williams' , 'Dean Anderson' Message-id: <009d01c9b81c$9d04eab0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acm3y9n5dq/V/ErAQJ2iCph5pfqolgATtSLA Cc: 'Eric Rescorla' , tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2009 07:34:47 -0000 Hi, Nicolas, =20 >On Tue, Mar 24, 2009 at 06:12:50PM -0500, Nicolas Williams wrote: >> The only things missing then would be: >>=20 >> - how to put SAML/whatever authorization elements into Kerberos V >> tickets and PKIX certificates >>=20 >> - how to use SASL in TLS >>=20 >> The latter is a variant of "how to use the GSS-API inside TLS", and=20 >> that has been controversial and has never progressed within the TLS=20 >> WG. IIRC the controversy arises from the fact that the GSS-API=20 >> supports arbitrary round trips, and the same is true of SASL -- so=20 >> you're likely to run into the same issue. >>=20 >> However, I think we might be able to do something about that: ride=20 >> some of the SASL/GSS-API messages in TLS handshake extensions and=20 >> complete the SASL/GSS-API authentication exchange after the TLS=20 >> exchange completes if the SASL/GSS-API mechanism requires=20 >further round-trips. >> Such a protocol would only be usable by applications that=20 >support such=20 >> a protocol as that'd not be "TLS" -- but consider how many SASL apps=20 >> run over TLS. > >Though, I should point out, this would be negotiable as it's=20 >merely an optional round-trip optimization for the application=20 >protocol. It's only applicable when it is safe to defer=20 >integrity protection for inital application protocol messages.=20 > This extension that I'm proposing is a therefore a bit more=20 >general than TLS+SASL or TLS+GSS-API. > >So I see several documents: > >1) An extension to TLS client and server hello and handshake messages > for carrying application protocol messages that can safely have > integrity protection delayed. Does this mean to have more rounds before [ChangeCipherSpec]? In this = way, as you said, it would not be "TLS" anymore, and certainly definitions of = new messages are needed besides extensions. If extra rounds are finished after [ChangeCipherSpec]=A3=ACthese = messages will have integrity protection, in this case, it's the application data which = are defered. Or did I misunderstand something? Sean From huangmin123@huaweisymantec.com Fri Apr 10 00:04:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36133A69A6 for ; Fri, 10 Apr 2009 00:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.094 X-Spam-Level: **** X-Spam-Status: No, score=4.094 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGRxDsNjSg6v for ; Fri, 10 Apr 2009 00:04:32 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 6FD373A6D1C for ; Fri, 10 Apr 2009 00:04:31 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHV001SNID01230@hstga02-in.huaweisymantec.com> for TLS@ietf.org; Fri, 10 Apr 2009 15:05:26 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHV00GF7ICY6L00@hstml02-in.huaweisymantec.com> for TLS@ietf.org; Fri, 10 Apr 2009 15:05:24 +0800 (CST) Received: from [10.27.154.144] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 10 Apr 2009 15:05:22 +0800 From: huangmin To: Stefan Santesson Message-id: Date: Fri, 10 Apr 2009 15:05:22 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: References: <200903101654.n2AGs4ED024335@fs4113.wdf.sap.corp> Content-transfer-encoding: quoted-printable Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 07:04:33 -0000 Hi=2CStefan I also have the same consideration as Martin about actions of caching=2C= updating and/or replacing the certificate path taken by the client=2E = I think there may be not much necessary to collect/cache more than one c= ertificates=2E In TLS Handshake process=2Cserver would treat the same cl= ient(or the same kind of clients) in the same way=2C which means that th= e server would like to send the same certificate or certificate path to = the same client(or the same kind of clients) all most of the time=2E And I imagine this is the= most general case in practice=2E = If collect/cache more than one certificate paths=2C take certificate ren= ewal into account=2C client will both cache the old(revocation) certific= ate path and the new certificate path(in fact=2C the old certificate pat= h has turn to be redundant now)=2C there will be a revocation mechanism = of certificate hashes required=2Cor the client would send the more and m= ore hash values everytime when it do TLS handshake with the same server=2E= This is just one exam ple=2E That is=2C when client is designed to collect/cache more than one= certificate paths=2C it may hold some useless/not much useful certifica= te paths=2C and send them to the sever during every TLS handshake=2E The= re should be some methods=2C which may be complex=2C to deal with it=2E = So=2C why not collect/cache just one certificate path of the server=3F In addition=2C here is another question=2C the server would send the has= h of the certificate path contained in the extension of the server hello= message=2C and then again in the server certificate message=2E The aim = is to inform and be checked the client that the cached certificate path = is valid=2C so once must be enough=2C do you think sending the same hash= es twice from server to client is redundant=3F regards=2C Min Huang ----- =D4=AD=CA=BC=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Stefan Santesson =3Cstefans=40exmsft=2Ecom=3E =C8=D5=C6=DA=3A 2009=C4=EA 3=D4=C2 13=C8=D5=2C =D0=C7=C6=DA=CE=E5=2C =C9= =CF=CE=E72=3A16 =D6=F7=CC=E2=3A Re=3A =5BTLS=5D New =22Fast-Track=22 draft posted =CA=D5=BC=FE=C8=CB=3A martin=2Erex=40sap=2Ecom =B3=AD=CB=CD=3A huangmin123=40huaweisymantec=2Ecom=2C TLS=40ietf=2Eorg =3E Martin=2C =3E = =3E Thanks for your extensive feedback=2E Comments in-line=2E =3E = =3E /Stefan =3E = =3E = =3E On 3/10/09 5=3A54 PM=2C =22Martin Rex=22 =3CMartin=2ERex=40sap=2Eco= m=3E wrote=3A =3E = =3E =3E Stefan Santesson wrote=3A =3E =3E=3E = =3E =3E=3E I included the possibility for the client to send more than = one = =3E hash simply =3E =3E=3E because I was not sure that there are no situation where tha= t = =3E could be =3E =3E=3E useful=2E =3E =3E=3E = =3E =3E=3E So as the text is written now=2C the client may include a nu= mber of = =3E hashes=2C =3E =3E=3E matching different sets of server certificate paths=2E This = may for = =3E example be =3E =3E=3E 2 hashes for the same server certificate calculated over dif= ferent =3E =3E=3E certificate paths=2E =3E =3E=3E The server will compare the hashes against the hash of the = =3E certificate path =3E =3E=3E it intended to send=2E If there is a match=2C the server wil= l indicate = =3E the =3E =3E=3E omitted path by including the corresponding hash in its Hell= o message=2E =3E =3E = =3E =3E = =3E =3E I think the peculiarities of the caching of the =22server = =3E certification path=22 =3E =3E should be described with a few examples in order to make it cle= ar what =3E =3E is actually meant here=2E At first=2C I was wondering why a cl= ient would =3E =3E collect/cache more than one certification path as =22valid=22 i= n the = =3E first place=2E =3E =3E = =3E = =3E Agree=2C I think it is reasonable to make such clarification=2E =3E = =3E =3E = =3E =3E Certainly there is no need to preculude that the client can lea= rn =3E =3E certificates in an out-of-band fashion and that it could =22gue= ss=22 =3E =3E hashes for certification paths that a server might send based o= n =3E =3E certificates there were learned/configured out-of-band--but it = is =3E =3E not the general case that this spec should address=2E =3E =3E = =3E I also imagine that we may have situations with clusters of hosts a= nd/or =3E proxies with slight difference in configuration and where some = =3E servers are =3E configured to send e=2Eg=2E The whole path and another only the ser= ver =3E certificate=2C or where multiple paths are configured due to some C= A =3E certificate renewals=2E My conclusion was that it would hurt more t= o = =3E not have =3E the ability to include more than one hash if we need it than to = =3E provide the =3E capability even though it=27s not used=2E =3E = =3E = =3E =3E Normally=2C the client should learn (=22cache=22) the path from= a previous =3E =3E full handshake with the server=2C and the client should probabl= y =3E =3E replace the cached certification path entirely if the server =3E =3E does respond with a full path instead of the omission--rather =3E =3E than collecting pathes and starting to announce all of the =3E =3E hashes for all of the cached certification pathes that a specif= ic =3E =3E server has ever used in the past=2E =3E =3E = =3E I was actually only thinking of caching=2C but in some environments= it = =3E might =3E actually be logical to do it in another way as you mention=2E =3E = =3E =3E = =3E =3E Now what exactly are the characteristics for assuming that it a= lready =3E =3E possesses a server certification path (this is related to the c= lients =3E =3E decision when to propose resuming a cached TLS session=2C but i= t=27s =3E =3E slightly different)=2E =3E =3E = =3E =3E When client-side proxies are involved (aka HTTP CONNECT proxies= )=2C =3E =3E then the target IP-address visible at the network socket is pre= tty =3E =3E useless for distinguishing entries in the client-side cache=2E =3E =3E The client probably needs access to the hostname that was used =3E =3E to open the network connection (or the proxy CONNECT)=2E =3E =3E = =3E =3E A TLS session resume always implies a fixed set of connection a= ttributes =3E =3E (ciphersuite=2C server certification path)=2E =3E =3E = =3E =3E How much should a cached server certification path imply=3F =3E =3E Any particular certification path (if agreed to by the server) =3E =3E will restrict the subset of TLS ciphersuites that can be used =3E =3E based on the keytype of the server certificate in that path=2C =3E =3E e=2Eg=2E DSA-cihpersuites require a server cert with a DSA-key= =2C =3E =3E ECDSA-ciphersuites require a server cert with an ECDSA-key=2C =3E =3E RSA-ciphersuites require a server cert with an RSA-key=2C =3E =3E DHE-RSA ciphersuites require a server cert with an RSA-key =3E =3E which must have =22digitalSignature=22 keyUsage asserted=2C =3E =3E DH-RSA ciphersuites require a server cert with a DH key=2C etc=2E= =3E =3E = =3E I think it should imply exactly the same as if that server = =3E certificate path =3E was sent over the wire=2E =3E = =3E =3E = =3E =3E I think the document should provide guidance when to =22update =3E =3E the cache=22 when the server sends a full certification path =3E =3E instead of the omission=2C and when the client should or could =3E =3E store the full certification path sent by the server as a =3E =3E valid alternative=2E =3E =3E = =3E Good suggestion=2E =3E = =3E = =3E =3E = =3E =3E -Martin =3E = =3E = =3E From stefan@aaa-sec.com Fri Apr 10 02:13:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1658F3A6915 for ; Fri, 10 Apr 2009 02:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIynuJu95KGH for ; Fri, 10 Apr 2009 02:13:44 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id EDDCF3A6768 for ; Fri, 10 Apr 2009 02:13:39 -0700 (PDT) Received: (qmail 93814 invoked from network); 10 Apr 2009 09:14:49 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Apr 2009 09:14:49 -0000 Received: (qmail 15215 invoked from network); 10 Apr 2009 09:14:46 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2009 09:14:46 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 10 Apr 2009 11:14:45 +0200 From: Stefan Santesson To: Eric Rescorla Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm5vMn0VwaJkxPWoU6b+ZJlp8dXjQ== In-Reply-To: <20090407154607.BF787124C21@kilo.networkresonance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 09:13:45 -0000 Thank you Eric, This looks great. I will get on with updating the draft next week after Easter. Just a few questions. Could you elaborate what would get hashed and cached when identifying the type trusted_cas? Should we allow hashing of multiple information types in the same extension? E.g. like: struct { CachedInformationType type; CachedInformationHash hashes<1..2^16-1>; } CachedObject; struct { CachedObject cached_info<1..2^24-1>;; } CachedInformation; /Stefan On 4/7/09 5:46 PM, "Eric Rescorla" wrote: > Stefan, > > As we discussed in SFO, I think this is a good idea, but I would > generalize it a bit. Your current syntax only supports cert > caching. I would add one more level of indirection: > > enum { > cached_information(TBD), (65535) > } ExtensionType; > > enum { > certificate_chain(1), trusted_cas(2), (255) > } CachedInformationType; > > struct { > HashAlgorithm hash; > opaque hash_value<1..255>; > } CachedInformationHash; > > struct { > CachedInformationType type; > CachedInformationHash hashes<1..2^16-1>; > } CachedInformation; > > Note that this also supports the minimal level of hash agility > we discussed in the meeting. > > -Ekr > > From stefan@aaa-sec.com Fri Apr 10 02:32:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9896B3A6969 for ; Fri, 10 Apr 2009 02:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_26=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZUC4kPwXVPs for ; Fri, 10 Apr 2009 02:32:14 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 43B503A6D69 for ; Fri, 10 Apr 2009 02:32:13 -0700 (PDT) Received: (qmail 9672 invoked from network); 10 Apr 2009 09:33:23 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Apr 2009 09:33:23 -0000 Received: (qmail 75745 invoked from network); 10 Apr 2009 09:33:20 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2009 09:33:20 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 10 Apr 2009 11:33:19 +0200 From: Stefan Santesson To: huangmin Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm5v2Hz4H2iBHCQgUmYNylFvqCNOA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 09:32:15 -0000 Hi Min, A point raised I think would also be the possibility to provide hashes of different kinds for the same certificate path, i.e. One SHA-1 and one SHA-2 hash. To accommodate the possibility to send more than one hash is very easy. I personally believe much more in the benefit of generality, than I fear the danger of allowing multiple hash values. On your second note it would appear at a first glance that sending the hash twice is redundant. However I do think this redundancy make sense for the state machine. The client benefits from knowing that the cashed information is accepted through the server hello, to prepare for the altered handshake. In the handshake, it make sense to include the data that will be processed for the TLS finished message in order to leave that logic unchanged. /Stefan On 4/10/09 9:05 AM, "huangmin" wrote: > Hi,Stefan I also have the same consideration as Martin about actions of > caching, updating and/or replacing the certificate path taken by the client. > I think there may be not much necessary to collect/cache more than one > certificates. In TLS Handshake process,server would treat the same client(or > the same kind of clients) in the same way, which means that the server would > like to send the same certificate or certificate path to the same client(or > the same kind of clients) all most of the time. And I imagine this is the > most general case in practice. If collect/cache more than one certificate > paths, take certificate renewal into account, client will both cache the > old(revocation) certificate path and the new certificate path(in fact, the old > certificate path has turn to be redundant now), there will be a revocation > mechanism of certificate hashes required,or the client would send the more and > more hash values everytime when it do TLS handshake with the same server. This > is just one exam ple. That is, when client is designed to collect/cache more > than one certificate paths, it may hold some useless/not much useful > certificate paths, and send them to the sever during every TLS handshake. > There should be some methods, which may be complex, to deal with it. So, why > not collect/cache just one certificate path of the server? In addition, here > is another question, the server would send the hash of the certificate path > contained in the extension of the server hello message, and then again in the > server certificate message. The aim is to inform and be checked the client > that the cached certificate path is valid, so once must be enough, do you > think sending the same hashes twice from server to client is > redundant? regards, Min Huang From ekr@networkresonance.com Fri Apr 10 06:41:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498673A6E16 for ; Fri, 10 Apr 2009 06:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0+yd8qRLoiD for ; Fri, 10 Apr 2009 06:41:26 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 4B2113A6E32 for ; Fri, 10 Apr 2009 06:40:52 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 502B4128B1A; Fri, 10 Apr 2009 06:43:12 -0700 (PDT) Date: Fri, 10 Apr 2009 06:43:12 -0700 From: Eric Rescorla To: Stefan Santesson In-Reply-To: References: <20090407154607.BF787124C21@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090410134312.502B4128B1A@kilo.networkresonance.com> Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 13:41:27 -0000 At Fri, 10 Apr 2009 11:14:45 +0200, Stefan Santesson wrote: > > Thank you Eric, > > This looks great. I will get on with updating the draft next week after > Easter. Just a few questions. > > Could you elaborate what would get hashed and cached when identifying the > type trusted_cas? I was thinking CertificateRequest.certificate_authorities. The problem with having it be the CertificateRequest is that the CR also serves as a request to authenticate. Maybe that's OK though... > Should we allow hashing of multiple information types in the same extension? > E.g. like: > > struct { > CachedInformationType type; > CachedInformationHash hashes<1..2^16-1>; > } CachedObject; > > struct { > CachedObject cached_info<1..2^24-1>;; > } CachedInformation; You're totally right. That's what I meant. I just got lost in the syntax. -Ekr From housley@vigilsec.com Fri Apr 10 08:09:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5F83A6DF2 for ; Fri, 10 Apr 2009 08:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAN8JIuMkkWg for ; Fri, 10 Apr 2009 08:09:13 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id F42223A6DEE for ; Fri, 10 Apr 2009 08:09:12 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 083679A474E; Fri, 10 Apr 2009 11:10:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id y3LIUZTiR3p8; Fri, 10 Apr 2009 11:10:18 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A54859A47B6; Fri, 10 Apr 2009 11:10:38 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Apr 2009 11:10:10 -0400 To: Eric Rescorla From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090410151038.A54859A47B6@odin.smetech.net> Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 15:09:13 -0000 Eric, I'm not quite sure how this approach works out with the extension negotiation mechanism. From the shorthand here, I'm assuming that the client offers the cached_information extension in the ClientHello, and if the Sever indicates support for it in the ServerHello, then the client sends CachedInformation. So, if the server indicates support because it has code for certificate_chain(1), then the client sends yet_to_be_specified_stuff(48), then the negotiation has not helped because the granularity of the negotiation does not align with the potential information that the client is considering. Russ On 4/7/09 5:46 PM, "Eric Rescorla" wrote: > Stefan, > > As we discussed in SFO, I think this is a good idea, but I would > generalize it a bit. Your current syntax only supports cert > caching. I would add one more level of indirection: > > enum { > cached_information(TBD), (65535) > } ExtensionType; > > enum { > certificate_chain(1), trusted_cas(2), (255) > } CachedInformationType; > > struct { > HashAlgorithm hash; > opaque hash_value<1..255>; > } CachedInformationHash; > > struct { > CachedInformationType type; > CachedInformationHash hashes<1..2^16-1>; > } CachedInformation; > > Note that this also supports the minimal level of hash agility > we discussed in the meeting. > > -Ekr > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Fri Apr 10 09:59:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17643A692F for ; Fri, 10 Apr 2009 09:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SvyRCPZ34Lh for ; Fri, 10 Apr 2009 09:59:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 605C03A682D for ; Fri, 10 Apr 2009 09:59:15 -0700 (PDT) Received: (qmail 23429 invoked from network); 10 Apr 2009 17:00:28 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Apr 2009 17:00:28 -0000 Received: (qmail 60495 invoked from network); 10 Apr 2009 17:00:21 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2009 17:00:21 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 10 Apr 2009 19:00:20 +0200 From: Stefan Santesson To: Russ Housley , Eric Rescorla Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm5/dSDtoepBlmdH0G6qIkwMF1Cxg== In-Reply-To: <20090410151038.A54859A47B6@odin.smetech.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 16:59:17 -0000 Russ, No this is not the way I originally intended the logic, and how I think Eric meant either. The client send the cashed information in the ClientHello, not after the server response. The server includes the hashes of the cashed information types it supports in the ServerHello. So, if the server responds with the hash of cashed information type 1 but not the hash of the cashed information type 2, then the client will assume that only the cashed information of type 1 matches and is supported by the server. Does this make sense? /Stefan On 4/10/09 5:10 PM, "Russ Housley" wrote: > Eric, > > I'm not quite sure how this approach works out with the extension > negotiation mechanism. > > From the shorthand here, I'm assuming that the client offers the > cached_information extension in the ClientHello, and if the Sever > indicates support for it in the ServerHello, then the client sends > CachedInformation. So, if the server indicates support because it > has code for certificate_chain(1), then the client sends > yet_to_be_specified_stuff(48), then the negotiation has not helped > because the granularity of the negotiation does not align with the > potential information that the client is considering. > > Russ > > On 4/7/09 5:46 PM, "Eric Rescorla" wrote: > >> Stefan, >> >> As we discussed in SFO, I think this is a good idea, but I would >> generalize it a bit. Your current syntax only supports cert >> caching. I would add one more level of indirection: >> >> enum { >> cached_information(TBD), (65535) >> } ExtensionType; >> >> enum { >> certificate_chain(1), trusted_cas(2), (255) >> } CachedInformationType; >> >> struct { >> HashAlgorithm hash; >> opaque hash_value<1..255>; >> } CachedInformationHash; >> >> struct { >> CachedInformationType type; >> CachedInformationHash hashes<1..2^16-1>; >> } CachedInformation; >> >> Note that this also supports the minimal level of hash agility >> we discussed in the meeting. >> >> -Ekr >> >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Fri Apr 10 10:04:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062E73A6C92 for ; Fri, 10 Apr 2009 10:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6c3Bf2K8cNE for ; Fri, 10 Apr 2009 10:04:49 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 05FB83A6A7E for ; Fri, 10 Apr 2009 10:04:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,168,1238976000"; d="scan'208";a="71456441" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 10 Apr 2009 17:05:58 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3AH5tUG024570; Fri, 10 Apr 2009 10:05:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n3AH5tiJ017498; Fri, 10 Apr 2009 17:05:55 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 10:05:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Apr 2009 10:05:53 -0700 Message-ID: In-Reply-To: <20090407154607.BF787124C21@kilo.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm3l9kjUflTvtE9R+iLgrKmVuoT2wCZUeVQ References: <20090407154607.BF787124C21@kilo.networkresonance.com> From: "Joseph Salowey (jsalowey)" To: "Eric Rescorla" , "Stefan Santesson" X-OriginalArrivalTime: 10 Apr 2009 17:05:55.0750 (UTC) FILETIME=[9CA28C60:01C9B9FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1595; t=1239383155; x=1240247155; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20New=20=22Fast-Track=22=20draft= 20posted |Sender:=20; bh=eR30Hax0rSwaLiXuUSPYGPUdnHvJuEBr2EXre6Qd7SU=; b=HgKDrW9L70X8/8QfYXQZIjNqGmZDY7WMbjVzv/jeLbJDiDljwB2a7+JkpE DVsSIgE0pe/abwUU0Msvlejzzim2e6VHqVq0b25GbHcL3WCYjsUK4MJrtv+U WW8omygWJ7; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 17:04:50 -0000 For trusted CAs it would be useful if the client could indicate that it does not want to receive the list even though it may not have information cached. This could be indicated by either allowing the CachedInformationHash to be omitted or reserving a specific hashAlgorithm in the client hello to indicate no interest in the information. =20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Eric Rescorla > Sent: Tuesday, April 07, 2009 8:46 AM > To: Stefan Santesson > Cc: TLS wg > Subject: Re: [TLS] New "Fast-Track" draft posted >=20 > Stefan, >=20 > As we discussed in SFO, I think this is a good idea, but I=20 > would generalize it a bit. Your current syntax only supports=20 > cert caching. I would add one more level of indirection: >=20 > enum { > cached_information(TBD), (65535) > } ExtensionType; >=20 > enum { > certificate_chain(1), trusted_cas(2), (255) > } CachedInformationType; >=20 > struct { > HashAlgorithm hash; > opaque hash_value<1..255>; > } CachedInformationHash; >=20 > struct { > CachedInformationType type; > CachedInformationHash hashes<1..2^16-1>; > } CachedInformation; >=20 > Note that this also supports the minimal level of hash=20 > agility we discussed in the meeting. >=20 > -Ekr >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From housley@vigilsec.com Fri Apr 10 11:04:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2C73A6928 for ; Fri, 10 Apr 2009 11:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP3BRLGfhc9B for ; Fri, 10 Apr 2009 11:04:03 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id ED1FB3A67B1 for ; Fri, 10 Apr 2009 11:04:02 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D22449A476A; Fri, 10 Apr 2009 14:05:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id LK6WX77vWGeB; Fri, 10 Apr 2009 14:05:10 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B9CC19A4725; Fri, 10 Apr 2009 14:05:26 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Apr 2009 14:04:54 -0400 To: Stefan Santesson , Eric Rescorla From: Russ Housley In-Reply-To: References: <20090410151038.A54859A47B6@odin.smetech.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090410180526.B9CC19A4725@odin.smetech.net> Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 18:04:03 -0000 Stefan: Thanks. That makes a lot more sense. Russ At 01:00 PM 4/10/2009, Stefan Santesson wrote: >Russ, > >No this is not the way I originally intended the logic, and how I think Eric >meant either. > >The client send the cashed information in the ClientHello, not after the >server response. > >The server includes the hashes of the cashed information types it supports >in the ServerHello. > >So, if the server responds with the hash of cashed information type 1 but >not the hash of the cashed information type 2, then the client will assume >that only the cashed information of type 1 matches and is supported by the >server. > >Does this make sense? > >/Stefan > >On 4/10/09 5:10 PM, "Russ Housley" wrote: > > > Eric, > > > > I'm not quite sure how this approach works out with the extension > > negotiation mechanism. > > > > From the shorthand here, I'm assuming that the client offers the > > cached_information extension in the ClientHello, and if the Sever > > indicates support for it in the ServerHello, then the client sends > > CachedInformation. So, if the server indicates support because it > > has code for certificate_chain(1), then the client sends > > yet_to_be_specified_stuff(48), then the negotiation has not helped > > because the granularity of the negotiation does not align with the > > potential information that the client is considering. > > > > Russ > > > > On 4/7/09 5:46 PM, "Eric Rescorla" wrote: > > > >> Stefan, > >> > >> As we discussed in SFO, I think this is a good idea, but I would > >> generalize it a bit. Your current syntax only supports cert > >> caching. I would add one more level of indirection: > >> > >> enum { > >> cached_information(TBD), (65535) > >> } ExtensionType; > >> > >> enum { > >> certificate_chain(1), trusted_cas(2), (255) > >> } CachedInformationType; > >> > >> struct { > >> HashAlgorithm hash; > >> opaque hash_value<1..255>; > >> } CachedInformationHash; > >> > >> struct { > >> CachedInformationType type; > >> CachedInformationHash hashes<1..2^16-1>; > >> } CachedInformation; > >> > >> Note that this also supports the minimal level of hash agility > >> we discussed in the meeting. > >> > >> -Ekr > >> > >> > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Fri Apr 10 13:17:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120863A69F9 for ; Fri, 10 Apr 2009 13:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neH5gL+k3Khn for ; Fri, 10 Apr 2009 13:17:17 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id B42173A680C for ; Fri, 10 Apr 2009 13:17:16 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3AKIPYv012673 for ; Fri, 10 Apr 2009 20:18:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3AKIOTp021805 for ; Fri, 10 Apr 2009 14:18:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3AJs14O008427; Fri, 10 Apr 2009 14:54:01 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3AJrwNJ008426; Fri, 10 Apr 2009 14:53:58 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 10 Apr 2009 14:53:58 -0500 From: Nicolas Williams To: Sean Shen Message-ID: <20090410195357.GZ1500@Sun.COM> References: <20090407214033.GK1667@Sun.COM> <009d01c9b81c$9d04eab0$800c6f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <009d01c9b81c$9d04eab0$800c6f0a@china.huawei.com> User-Agent: Mutt/1.5.7i Cc: 'Eric Rescorla' , tls@ietf.org Subject: [TLS] TLS/SA (Re: Interest in TLS authorization?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 20:17:18 -0000 On Wed, Apr 08, 2009 at 03:35:38PM +0800, Sean Shen wrote: > >So I see several documents: > > > >1) An extension to TLS client and server hello and handshake messages > > for carrying application protocol messages that can safely have > > integrity protection delayed. > > Does this mean to have more rounds before [ChangeCipherSpec]? In this way, No, it does not! > as you said, it would not be "TLS" anymore, and certainly definitions of new > messages are needed besides extensions. It is not a new protocol, actually. It's just an optimization of the application's app-layer authentication round-trips. > If extra rounds are finished after [ChangeCipherSpec]，these messages will > have integrity protection, in this case, it's the application data which are > defered. Or did I misunderstand something? Correct. I just posted an individual I-D for this extension: http://www.ietf.org/internet-drafts/draft-williams-tls-app-sasl-opt-01.txt (it will be there shortly; I forgot to include important text in -00 so I'm re-submitting momentarily). It allows the application to do the SASL mechanism negotiation in the first TLS round trip and then the first round trip of the selected SASL mechanism in the next TLS round trip. With the new SASL/GS2 mechanism family we also get support for GSS-API mechanisms. If the application negotiates the use of the Kerberos V GSS-API mechanism through the SASL/GS2 bridge, which requires one round trip, then it will complete the TLS and SASL authentication in just two round-trips instead of four. There is one odd sleight of hand, but I think it's OK. Can you find it? Is it acceptable? I think we should call this "TLS/SA" -- "SA" for the Simple Authentication half of SASL (we don't need the Security Layers half). Through these SASL and GSS-API mechanisms and the GSS-API "naming" extensions we'll get support for authorizations in TLS, and in a patent-free way (since all these things have been discussed publicly to some degree over the last few years, as I mentioned earlier, and I have no knowledge of any patents or patent applications covering any of the components of this proposal nor the proposal as a whole -- that does not mean there can't be applicable patents or patent applications though, and remember, IANAL). Comments? Nico -- From stefan@aaa-sec.com Fri Apr 10 14:10:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB94C3A6B8F for ; Fri, 10 Apr 2009 14:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohPzin30ysSp for ; Fri, 10 Apr 2009 14:10:31 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 1FC0E3A6981 for ; Fri, 10 Apr 2009 14:10:29 -0700 (PDT) Received: (qmail 12680 invoked from network); 10 Apr 2009 21:11:44 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Apr 2009 21:11:44 -0000 Received: (qmail 36371 invoked from network); 10 Apr 2009 21:11:35 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2009 21:11:35 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 10 Apr 2009 23:11:35 +0200 From: Stefan Santesson To: "Joseph Salowey (jsalowey)" , Eric Rescorla , Stefan Santesson Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm3l9kjUflTvtE9R+iLgrKmVuoT2wCZUeVQAAjzTFA= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 21:10:31 -0000 I'm sorry but I don't understand this proposal. How can the client know that the CA is trusted if it has not previously connected to the server? Secondly I would not omit data from the handshake without replacing it with a hash as it would alter the security properties of the TLS finished message e.g. its value as channel binding token would be changed. /Stefan On 4/10/09 7:05 PM, "Joseph Salowey (jsalowey)" wrote: > For trusted CAs it would be useful if the client could indicate that it > does not want to receive the list even though it may not have > information cached. This could be indicated by either allowing the > CachedInformationHash to be omitted or reserving a specific > hashAlgorithm in the client hello to indicate no interest in the > information. > > > > > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Tuesday, April 07, 2009 8:46 AM >> To: Stefan Santesson >> Cc: TLS wg >> Subject: Re: [TLS] New "Fast-Track" draft posted >> >> Stefan, >> >> As we discussed in SFO, I think this is a good idea, but I >> would generalize it a bit. Your current syntax only supports >> cert caching. I would add one more level of indirection: >> >> enum { >> cached_information(TBD), (65535) >> } ExtensionType; >> >> enum { >> certificate_chain(1), trusted_cas(2), (255) >> } CachedInformationType; >> >> struct { >> HashAlgorithm hash; >> opaque hash_value<1..255>; >> } CachedInformationHash; >> >> struct { >> CachedInformationType type; >> CachedInformationHash hashes<1..2^16-1>; >> } CachedInformation; >> >> Note that this also supports the minimal level of hash >> agility we discussed in the meeting. >> >> -Ekr >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From Nicolas.Williams@sun.com Fri Apr 10 15:14:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5DD3A6981; Fri, 10 Apr 2009 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHYYcqncW-I1; Fri, 10 Apr 2009 15:14:53 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id A45713A68AE; Fri, 10 Apr 2009 15:14:53 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3AMG27t010368; Fri, 10 Apr 2009 22:16:02 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3AMG1AH012594; Fri, 10 Apr 2009 16:16:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3AM6d2q008558; Fri, 10 Apr 2009 17:06:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3AM6dcM008557; Fri, 10 Apr 2009 17:06:39 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 10 Apr 2009 17:06:39 -0500 From: Nicolas Williams To: tls@ietf.org Message-ID: <20090410220638.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Subject: [TLS] Optimizing use of SASL/GS2 over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 22:14:54 -0000 [Note: SASL and KITTEN WGs are Bcc'ed.] I've submitted an I-D describing how to reduce the number of round trips needed for SASL/GS2 mechanism negotiation and authentication when running over TLS: draft-williams-tls-app-sasl-opt-01.txt This can be seen as a variant of the TLS/GSS proposal from a while back as it achieves the same result: you can use the GSS-API for authentication _and_ TLS for session protection without having to pay a round trip penalty. But it does it in a slightly different and simpler way. I'm hoping this proposal will be less controversial than the TLS/GSS proposal. Comments? Nico -- From jsalowey@cisco.com Fri Apr 10 16:42:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7198928C0FB for ; Fri, 10 Apr 2009 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xiy4qF9kpL5m for ; Fri, 10 Apr 2009 16:42:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 709D93A6AEA for ; Fri, 10 Apr 2009 16:42:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,170,1238976000"; d="scan'208";a="284174136" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2009 23:43:27 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3ANhRhu022888; Fri, 10 Apr 2009 16:43:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3ANhRsI028968; Fri, 10 Apr 2009 23:43:27 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 16:43:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Apr 2009 16:43:26 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm3l9kjUflTvtE9R+iLgrKmVuoT2wCZUeVQAAjzTFAAAs6jEA== References: From: "Joseph Salowey (jsalowey)" To: "Stefan Santesson" , "Eric Rescorla" , "Stefan Santesson" X-OriginalArrivalTime: 10 Apr 2009 23:43:27.0382 (UTC) FILETIME=[2550C360:01C9BA36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3453; t=1239407007; x=1240271007; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20New=20=22Fast-Track=22=20draft= 20posted |Sender:=20; bh=SIok7y+ug7+nDsa9E7Yc1pait1ocXkEoba7IcjP9juY=; b=TFeJgxCiKo8W7bN6BOkVLjR5g43fdOiYstdwY/TqLa9iI+i95wU/FnMV/J E0cyvqPlbcXHctjyIWcFzL41DR1p9PZUrG9uaSTzgbiURRpHHbJ0IOticI1H eV2u7mFHoK; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2009 23:42:19 -0000 The server can include a list of certificate_authorities in the certificate request handshake message. If the server is configured with public CAs this list can be very long (longer that the certificate chain). In many cases the client has only one certificate or no certificate, so the trusted CA information is useless to the client because it has no choice to make. This is really a request for the server not to send this information so I don't see any problem with the finished message. =20 One option is to include this functionality in a single extension with the hash optimization. Another option would be to create a separate extension that tells the server that the information is not needed. My preference would be to use the same extension if it isn't too difficult. Does this help? Thanks, Joe > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 > Sent: Friday, April 10, 2009 2:12 PM > To: Joseph Salowey (jsalowey); Eric Rescorla; Stefan Santesson > Cc: TLS wg > Subject: Re: [TLS] New "Fast-Track" draft posted >=20 > I'm sorry but I don't understand this proposal. >=20 > How can the client know that the CA is trusted if it has not=20 > previously connected to the server? >=20 > Secondly I would not omit data from the handshake without=20 > replacing it with a hash as it would alter the security=20 > properties of the TLS finished message e.g. its value as=20 > channel binding token would be changed. >=20 > /Stefan >=20 >=20 > On 4/10/09 7:05 PM, "Joseph Salowey (jsalowey)"=20 > wrote: >=20 > > For trusted CAs it would be useful if the client could=20 > indicate that=20 > > it does not want to receive the list even though it may not have=20 > > information cached. This could be indicated by either allowing the=20 > > CachedInformationHash to be omitted or reserving a specific=20 > > hashAlgorithm in the client hello to indicate no interest in the=20 > > information. > >=20 > >=20 > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org]=20 > On Behalf Of=20 > >> Eric Rescorla > >> Sent: Tuesday, April 07, 2009 8:46 AM > >> To: Stefan Santesson > >> Cc: TLS wg > >> Subject: Re: [TLS] New "Fast-Track" draft posted > >>=20 > >> Stefan, > >>=20 > >> As we discussed in SFO, I think this is a good idea, but I would=20 > >> generalize it a bit. Your current syntax only supports=20 > cert caching.=20 > >> I would add one more level of indirection: > >>=20 > >> enum { > >> cached_information(TBD), (65535) > >> } ExtensionType; > >>=20 > >> enum { > >> certificate_chain(1), trusted_cas(2), (255) > >> } CachedInformationType; > >>=20 > >> struct { > >> HashAlgorithm hash; > >> opaque hash_value<1..255>; > >> } CachedInformationHash; > >>=20 > >> struct { > >> CachedInformationType type; > >> CachedInformationHash hashes<1..2^16-1>; > >> } CachedInformation; > >>=20 > >> Note that this also supports the minimal level of hash agility we=20 > >> discussed in the meeting. > >>=20 > >> -Ekr > >>=20 > >>=20 > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >>=20 >=20 >=20 >=20 From stefan@aaa-sec.com Fri Apr 10 17:02:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55113A69AA for ; Fri, 10 Apr 2009 17:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGqoTiklF0WO for ; Fri, 10 Apr 2009 17:02:34 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 75E9D3A693C for ; Fri, 10 Apr 2009 17:02:32 -0700 (PDT) Received: (qmail 70354 invoked from network); 11 Apr 2009 00:03:49 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Apr 2009 00:03:49 -0000 Received: (qmail 19164 invoked from network); 11 Apr 2009 00:03:39 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Apr 2009 00:03:39 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 11 Apr 2009 02:03:37 +0200 From: Stefan Santesson To: "Joseph Salowey (jsalowey)" , Eric Rescorla , Stefan Santesson Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm3l9kjUflTvtE9R+iLgrKmVuoT2wCZUeVQAAjzTFAAAs6jEAADM3bR In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2009 00:02:34 -0000 Thank you, Yes it helped a lot :) /Stefan On 4/11/09 1:43 AM, "Joseph Salowey (jsalowey)" wrote: > The server can include a list of certificate_authorities in the > certificate request handshake message. If the server is configured > with public CAs this list can be very long (longer that the certificate > chain). In many cases the client has only one certificate or no > certificate, so the trusted CA information is useless to the client > because it has no choice to make. This is really a request for the > server not to send this information so I don't see any problem with the > finished message. > > One option is to include this functionality in a single extension with > the hash optimization. Another option would be to create a separate > extension that tells the server that the information is not needed. My > preference would be to use the same extension if it isn't too difficult. > > > Does this help? > > Thanks, > > Joe > >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Friday, April 10, 2009 2:12 PM >> To: Joseph Salowey (jsalowey); Eric Rescorla; Stefan Santesson >> Cc: TLS wg >> Subject: Re: [TLS] New "Fast-Track" draft posted >> >> I'm sorry but I don't understand this proposal. >> >> How can the client know that the CA is trusted if it has not >> previously connected to the server? >> >> Secondly I would not omit data from the handshake without >> replacing it with a hash as it would alter the security >> properties of the TLS finished message e.g. its value as >> channel binding token would be changed. >> >> /Stefan >> >> >> On 4/10/09 7:05 PM, "Joseph Salowey (jsalowey)" >> wrote: >> >>> For trusted CAs it would be useful if the client could >> indicate that >>> it does not want to receive the list even though it may not have >>> information cached. This could be indicated by either allowing the >>> CachedInformationHash to be omitted or reserving a specific >>> hashAlgorithm in the client hello to indicate no interest in the >>> information. >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] >> On Behalf Of >>>> Eric Rescorla >>>> Sent: Tuesday, April 07, 2009 8:46 AM >>>> To: Stefan Santesson >>>> Cc: TLS wg >>>> Subject: Re: [TLS] New "Fast-Track" draft posted >>>> >>>> Stefan, >>>> >>>> As we discussed in SFO, I think this is a good idea, but I would >>>> generalize it a bit. Your current syntax only supports >> cert caching. >>>> I would add one more level of indirection: >>>> >>>> enum { >>>> cached_information(TBD), (65535) >>>> } ExtensionType; >>>> >>>> enum { >>>> certificate_chain(1), trusted_cas(2), (255) >>>> } CachedInformationType; >>>> >>>> struct { >>>> HashAlgorithm hash; >>>> opaque hash_value<1..255>; >>>> } CachedInformationHash; >>>> >>>> struct { >>>> CachedInformationType type; >>>> CachedInformationHash hashes<1..2^16-1>; >>>> } CachedInformation; >>>> >>>> Note that this also supports the minimal level of hash agility we >>>> discussed in the meeting. >>>> >>>> -Ekr >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >> >> >> From simon@josefsson.org Sat Apr 11 03:04:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4203A694D for ; Sat, 11 Apr 2009 03:04:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXgJjX8z+VAp for ; Sat, 11 Apr 2009 03:04:40 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CF0473A67F9 for ; Sat, 11 Apr 2009 03:04:33 -0700 (PDT) Received: from m90-137-75-44.cust.tele2.se ([90.137.75.44] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Lsa5h-0004FD-KG for tls@ietf.org; Sat, 11 Apr 2009 12:05:40 +0200 From: Simon Josefsson To: tls@ietf.org References: <20090410220638.GM1500@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090411:tls@ietf.org::m8amro/GB5APyXyV:VpI0 Date: Sat, 11 Apr 2009 12:05:28 +0200 In-Reply-To: <20090410220638.GM1500@Sun.COM> (Nicolas Williams's message of "Fri, 10 Apr 2009 17:06:39 -0500") Message-ID: <878wm7wlnb.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [TLS] Optimizing use of SASL/GS2 over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2009 10:04:40 -0000 Nicolas Williams writes: > I've submitted an I-D describing how to reduce the number of round trips > needed for SASL/GS2 mechanism negotiation and authentication when > running over TLS: > > draft-williams-tls-app-sasl-opt-01.txt > > This can be seen as a variant of the TLS/GSS proposal from a while back > as it achieves the same result: you can use the GSS-API for > authentication _and_ TLS for session protection without having to pay a > round trip penalty. But it does it in a slightly different and simpler > way. > > I'm hoping this proposal will be less controversial than the TLS/GSS > proposal. > > Comments? Interesting work! I think it is worthwhile to continue explore this approach. I'm interested in helping with the draft and implement it if appears to meet more approval than TLS/GSS. I'd be interested in hearing comments from people working on the TLS/GSS effort. Some comments: * The SaslSML message is not explained? I assume it contains the normal list of SASL mechs supported by the server, separated with SPC? That needs to be defined. * The second paragraph of 2.1 doesn't work: I assume you meant that the SASL mechanism name plus NUL is sent in the first message from the client at all times? * The server needs the ability to reject client-chosen mechanism and the client should be able to recover. This argues for using a separate message type for the mechanism-selection (and success/failure?) packets. * The somewhat ugly all-set four-byte token with additional application information could probably also better be sent using a separate message type. * 2^16-1.. please use 2^32-1 instead, even 2^24-1 are on short size when considering authorization information. * How would EXTERNAL work? If requested, the TLS channel hasn't been set up yet, so it may be premature to decide whether to honor it or not. It would work if there has already been a TLS handshake, though. Architecturally, I'm not convinced involving SASL is required. It seems you can achieve the same goals by defining your protocol directly against GSS-API. SCRAM will be usable as a GSS-API mechanism, covering one of the two use cases (Kerberos V5 being the other). But it may be an easier upgrade path for application writers who are already familiar with TLS and SASL. So that is OK by me. /Simon From stefan@aaa-sec.com Sat Apr 11 17:22:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66E83A6876 for ; Sat, 11 Apr 2009 17:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDI-6RnKFWit for ; Sat, 11 Apr 2009 17:22:23 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 64F173A680B for ; Sat, 11 Apr 2009 17:22:22 -0700 (PDT) Received: (qmail 11273 invoked from network); 12 Apr 2009 00:23:40 -0000 Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Apr 2009 00:23:40 -0000 Received: (qmail 84906 invoked from network); 12 Apr 2009 00:23:29 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Apr 2009 00:23:29 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sun, 12 Apr 2009 02:23:24 +0200 From: Stefan Santesson To: "Joseph Salowey (jsalowey)" , Eric Rescorla Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm3l9kjUflTvtE9R+iLgrKmVuoT2wCZUeVQAAjzTFAAAs6jEAADM3bRADL7e1E= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2009 00:22:24 -0000 Thinking more about this I can't find a way to accomplish this that I feel really comfortable with. The current extension syntax follows a common and simple principle. That is, this is an extension that supports caching, and the way to signal that you have cached information is that you can provide a hash of it. To allow you to signal that you don't want to receive information, not because you have cached it, but simply because you don't ever want to receive it, requires too much deviation from both the extension semantics as well as its syntax. I would rather let the client receive the CA information once and then present its hash on every following occasion. I don't think it is worth the effort to save the bandwidth also the very first time of connection. /Stefan On 09-04-11 2:03 AM, "Stefan Santesson" wrote: > Thank you, > > Yes it helped a lot :) > > /Stefan > > > On 4/11/09 1:43 AM, "Joseph Salowey (jsalowey)" wrote: > >> The server can include a list of certificate_authorities in the >> certificate request handshake message. If the server is configured >> with public CAs this list can be very long (longer that the certificate >> chain). In many cases the client has only one certificate or no >> certificate, so the trusted CA information is useless to the client >> because it has no choice to make. This is really a request for the >> server not to send this information so I don't see any problem with the >> finished message. >> >> One option is to include this functionality in a single extension with >> the hash optimization. Another option would be to create a separate >> extension that tells the server that the information is not needed. My >> preference would be to use the same extension if it isn't too difficult. >> >> >> Does this help? >> >> Thanks, >> >> Joe >> >>> -----Original Message----- >>> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >>> Sent: Friday, April 10, 2009 2:12 PM >>> To: Joseph Salowey (jsalowey); Eric Rescorla; Stefan Santesson >>> Cc: TLS wg >>> Subject: Re: [TLS] New "Fast-Track" draft posted >>> >>> I'm sorry but I don't understand this proposal. >>> >>> How can the client know that the CA is trusted if it has not >>> previously connected to the server? >>> >>> Secondly I would not omit data from the handshake without >>> replacing it with a hash as it would alter the security >>> properties of the TLS finished message e.g. its value as >>> channel binding token would be changed. >>> >>> /Stefan >>> >>> >>> On 4/10/09 7:05 PM, "Joseph Salowey (jsalowey)" >>> wrote: >>> >>>> For trusted CAs it would be useful if the client could >>> indicate that >>>> it does not want to receive the list even though it may not have >>>> information cached. This could be indicated by either allowing the >>>> CachedInformationHash to be omitted or reserving a specific >>>> hashAlgorithm in the client hello to indicate no interest in the >>>> information. >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] >>> On Behalf Of >>>>> Eric Rescorla >>>>> Sent: Tuesday, April 07, 2009 8:46 AM >>>>> To: Stefan Santesson >>>>> Cc: TLS wg >>>>> Subject: Re: [TLS] New "Fast-Track" draft posted >>>>> >>>>> Stefan, >>>>> >>>>> As we discussed in SFO, I think this is a good idea, but I would >>>>> generalize it a bit. Your current syntax only supports >>> cert caching. >>>>> I would add one more level of indirection: >>>>> >>>>> enum { >>>>> cached_information(TBD), (65535) >>>>> } ExtensionType; >>>>> >>>>> enum { >>>>> certificate_chain(1), trusted_cas(2), (255) >>>>> } CachedInformationType; >>>>> >>>>> struct { >>>>> HashAlgorithm hash; >>>>> opaque hash_value<1..255>; >>>>> } CachedInformationHash; >>>>> >>>>> struct { >>>>> CachedInformationType type; >>>>> CachedInformationHash hashes<1..2^16-1>; >>>>> } CachedInformation; >>>>> >>>>> Note that this also supports the minimal level of hash agility we >>>>> discussed in the meeting. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>> >>> >>> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Mon Apr 13 09:23:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6A23A6DBC for ; Mon, 13 Apr 2009 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWBJDiOV2os6 for ; Mon, 13 Apr 2009 09:23:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B30C73A6C3D for ; Mon, 13 Apr 2009 09:23:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,180,1238976000"; d="scan'208";a="285339651" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2009 16:24:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3DGOvlt007905; Mon, 13 Apr 2009 09:24:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3DGOv66017823; Mon, 13 Apr 2009 16:24:57 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 09:24:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Apr 2009 09:24:56 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm3l9kjUflTvtE9R+iLgrKmVuoT2wCZUeVQAAjzTFAAAs6jEAADM3bRADL7e1EAU5sV8A== References: From: "Joseph Salowey (jsalowey)" To: "Stefan Santesson" , "Eric Rescorla" X-OriginalArrivalTime: 13 Apr 2009 16:24:57.0572 (UTC) FILETIME=[62AF9A40:01C9BC54] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5784; t=1239639897; x=1240503897; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20New=20=22Fast-Track=22=20draft= 20posted |Sender:=20; bh=2dWjWcnMzZvoRewQ3j4QrXsB6WdhY9dBxmsOElLMvg8=; b=SK04zNSZWizk0YfVNQg8E5xktz+H708RSM11RUeiH56l+dQS+g0bm2xB06 FOPOYhHFdy0Ss/LssB5gbjsfELCC/BqDxnuy+F0ixzhe+qvYdVK6YT1NG2HU rEDMffANsS; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2009 16:23:48 -0000 I see your point. The current semantics would be an improvement over the current situation. =20 I wonder if it may still be worthwhile to optimize the initial case. Does anyone see a separate extension to tell the server not to send specific data such as the trusted CA list as useful? =20 Thanks, Joe > -----Original Message----- > From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 > Sent: Saturday, April 11, 2009 5:23 PM > To: Joseph Salowey (jsalowey); Eric Rescorla > Cc: TLS wg > Subject: Re: [TLS] New "Fast-Track" draft posted >=20 > Thinking more about this I can't find a way to accomplish=20 > this that I feel really comfortable with. >=20 > The current extension syntax follows a common and simple=20 > principle. That is, this is an extension that supports=20 > caching, and the way to signal that you have cached=20 > information is that you can provide a hash of it. >=20 > To allow you to signal that you don't want to receive=20 > information, not because you have cached it, but simply=20 > because you don't ever want to receive it, requires too much=20 > deviation from both the extension semantics as well as its syntax. >=20 > I would rather let the client receive the CA information once=20 > and then present its hash on every following occasion. I=20 > don't think it is worth the effort to save the bandwidth also=20 > the very first time of connection. >=20 > /Stefan >=20 >=20 > On 09-04-11 2:03 AM, "Stefan Santesson" wrote: >=20 > > Thank you, > >=20 > > Yes it helped a lot :) > >=20 > > /Stefan > >=20 > >=20 > > On 4/11/09 1:43 AM, "Joseph Salowey (jsalowey)"=20 > wrote: > >=20 > >> The server can include a list of certificate_authorities in the > >> certificate request handshake message. If the server is=20 > configured > >> with public CAs this list can be very long (longer that the=20 > >> certificate chain). In many cases the client has only one=20 > >> certificate or no certificate, so the trusted CA information is=20 > >> useless to the client because it has no choice to make. This is=20 > >> really a request for the server not to send this information so I=20 > >> don't see any problem with the finished message. > >>=20 > >> One option is to include this functionality in a single extension=20 > >> with the hash optimization. Another option would be to create a=20 > >> separate extension that tells the server that the=20 > information is not=20 > >> needed. My preference would be to use the same extension=20 > if it isn't too difficult. > >>=20 > >>=20 > >> Does this help? > >>=20 > >> Thanks, > >>=20 > >> Joe > >>=20 > >>> -----Original Message----- > >>> From: Stefan Santesson [mailto:stefan@aaa-sec.com] > >>> Sent: Friday, April 10, 2009 2:12 PM > >>> To: Joseph Salowey (jsalowey); Eric Rescorla; Stefan Santesson > >>> Cc: TLS wg > >>> Subject: Re: [TLS] New "Fast-Track" draft posted > >>>=20 > >>> I'm sorry but I don't understand this proposal. > >>>=20 > >>> How can the client know that the CA is trusted if it has not=20 > >>> previously connected to the server? > >>>=20 > >>> Secondly I would not omit data from the handshake without=20 > replacing=20 > >>> it with a hash as it would alter the security properties=20 > of the TLS=20 > >>> finished message e.g. its value as channel binding token would be=20 > >>> changed. > >>>=20 > >>> /Stefan > >>>=20 > >>>=20 > >>> On 4/10/09 7:05 PM, "Joseph Salowey (jsalowey)" > >>> wrote: > >>>=20 > >>>> For trusted CAs it would be useful if the client could > >>> indicate that > >>>> it does not want to receive the list even though it may not have=20 > >>>> information cached. This could be indicated by either=20 > allowing the=20 > >>>> CachedInformationHash to be omitted or reserving a specific=20 > >>>> hashAlgorithm in the client hello to indicate no interest in the=20 > >>>> information. > >>>>=20 > >>>>=20 > >>>>=20 > >>>> =20 > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] > >>> On Behalf Of > >>>>> Eric Rescorla > >>>>> Sent: Tuesday, April 07, 2009 8:46 AM > >>>>> To: Stefan Santesson > >>>>> Cc: TLS wg > >>>>> Subject: Re: [TLS] New "Fast-Track" draft posted > >>>>>=20 > >>>>> Stefan, > >>>>>=20 > >>>>> As we discussed in SFO, I think this is a good idea,=20 > but I would=20 > >>>>> generalize it a bit. Your current syntax only supports > >>> cert caching.=20 > >>>>> I would add one more level of indirection: > >>>>>=20 > >>>>> enum { > >>>>> cached_information(TBD), (65535) > >>>>> } ExtensionType; > >>>>>=20 > >>>>> enum { > >>>>> certificate_chain(1), trusted_cas(2), (255) > >>>>> } CachedInformationType; > >>>>>=20 > >>>>> struct { > >>>>> HashAlgorithm hash; > >>>>> opaque hash_value<1..255>; > >>>>> } CachedInformationHash; > >>>>>=20 > >>>>> struct { > >>>>> CachedInformationType type; > >>>>> CachedInformationHash hashes<1..2^16-1>; > >>>>> } CachedInformation; > >>>>>=20 > >>>>> Note that this also supports the minimal level of hash=20 > agility we=20 > >>>>> discussed in the meeting. > >>>>>=20 > >>>>> -Ekr > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> TLS mailing list > >>>>> TLS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tls > >>>>>=20 > >>>=20 > >>>=20 > >>>=20 > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 From Nicolas.Williams@sun.com Tue Apr 14 11:20:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649B23A6EA7 for ; Tue, 14 Apr 2009 11:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fln86QF6mDzT for ; Tue, 14 Apr 2009 11:20:54 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 273D23A6EC3 for ; Tue, 14 Apr 2009 11:20:42 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EILr6f015985 for ; Tue, 14 Apr 2009 18:21:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3EILrwu052115 for ; Tue, 14 Apr 2009 12:21:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EICRmd010738; Tue, 14 Apr 2009 13:12:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EICRnt010737; Tue, 14 Apr 2009 13:12:27 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 14 Apr 2009 13:12:27 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20090414181227.GL1500@Sun.COM> References: <20090410220638.GM1500@Sun.COM> <878wm7wlnb.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878wm7wlnb.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Optimizing use of SASL/GS2 over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2009 18:20:55 -0000 On Sat, Apr 11, 2009 at 12:05:28PM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > Comments? > > Interesting work! I think it is worthwhile to continue explore this > approach. I'm interested in helping with the draft and implement it if > appears to meet more approval than TLS/GSS. I'd be interested in > hearing comments from people working on the TLS/GSS effort. Excellent! That is good news. > Some comments: > > * The SaslSML message is not explained? I assume it contains the normal > list of SASL mechs supported by the server, separated with SPC? That > needs to be defined. I'm adding more text in -02, which I'll submit today. Yes, SaslSML is the server's SASL mechanism list. > * The second paragraph of 2.1 doesn't work: I assume you meant that the > SASL mechanism name plus NUL is sent in the first message from the > client at all times? Yes. > * The server needs the ability to reject client-chosen mechanism and the > client should be able to recover. This argues for using a separate > message type for the mechanism-selection (and success/failure?) > packets. It can now: just send the outcome of authentication message immediately and then the optimization ends, at which point the application protocol starts as if nothing had happened (except that there's now no need to list the server mechanisms) and the client can re-try SASL authentication in the normal application protocol. > * The somewhat ugly all-set four-byte token with additional application > information could probably also better be sent using a separate > message type. No need: by that time we're clearly in the "Application Data" phase of the TLS protocol, and defining a new message type would seem like too much of a change to me. > * 2^16-1.. please use 2^32-1 instead, even 2^24-1 are on short size when > considering authorization information. I know that 2^16-1 is small, but that comes from the limit on Hello extensions. I wasn't sure that handshake messages could be longer. I'll check into that. > * How would EXTERNAL work? If requested, the TLS channel hasn't been > set up yet, so it may be premature to decide whether to honor it or > not. It would work if there has already been a TLS handshake, though. -02 will clarify that this extension is applicable only to SASL/GS2 mechanisms. The server mechanism list can contain other SASL mechanisms, but if the client wishes to select one of those then it needs to do it in the normal application protocol. > Architecturally, I'm not convinced involving SASL is required. It seems > you can achieve the same goals by defining your protocol directly > against GSS-API. SCRAM will be usable as a GSS-API mechanism, covering > one of the two use cases (Kerberos V5 being the other). But it may be > an easier upgrade path for application writers who are already familiar > with TLS and SASL. So that is OK by me. Doing mechanism negotiation the SASL way is, IMO, part of what makes it possible to build this extension in a way that should pass muster with the TLS WG (unlike TLS/GSS). You're correct that this does not mean that this extension should be in SASL terms as opposed to GSS-API terms. However: a) it ought to be possible to optimize SASL apps this way, b) it ought to be possible to optimize GSS-API apps this way, c) with SASL/GS2 we get (a) and (b) at once, therefore using SASL seems like the best way to go. Thanks so much for your comments! Nico -- From Martin.Rex@sap.com Tue Apr 14 12:27:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5113A6EC8 for ; Tue, 14 Apr 2009 12:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OEM_BRC=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8ScusdkiKLy for ; Tue, 14 Apr 2009 12:27:09 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id EE6593A6A11 for ; Tue, 14 Apr 2009 12:27:08 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n3EJQD4G020221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 21:26:13 +0200 (MEST) From: Martin Rex Message-Id: <200904141926.n3EJQCe9015225@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 14 Apr 2009 21:26:12 +0200 (MEST) In-Reply-To: from "Joseph Salowey" at Apr 10, 9 04:43:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: stefans@exmsft.com, TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@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, 14 Apr 2009 19:27:10 -0000 Joseph Salowey wrote: > > The server can include a list of certificate_authorities in the > certificate request handshake message. If the server is configured > with public CAs this list can be very long (longer that the certificate > chain). In many cases the client has only one certificate or no > certificate, so the trusted CA information is useless to the client > because it has no choice to make. This is really a request for the > server not to send this information so I don't see any problem with the > finished message. While I do mostly agree that omitting the list of certification_authorities is probably not going to change the security properties of the TLS session, I STRONGLY object to omitting that parameter. Unless there is a clear requirement for a future TLS revision to ignore unsolicited client certificates and "gracefully" continue the handshake exactly as when the client did not send the unsolicited certificate, then it is a serious problem to the TLS handshake to omit the list of certification_authorities from the CertificateRequest handshake message. With "unsolicited" client certificate I mean one for which the client does could not positively confirm that the server will be able to build a certification path to one of its trust anchors. In SSLv3 and TLSv1.0 it was explicitly prohibited in the spec to omit the certificate_authorities list. Starting with TLS v1.1 it is allowed as an option, but in general a pretty bad idea to do so (and in particular it is a pretty dumb idea to create a Server where such a list can not be configured). Our (OEM) SSL implementation is going to fatally abort the SSL handshake if the server is sent a client certificate for which it can not build a certification path to one of its trust anchors -- and that is independent from whether it requires a client certificate or only requests a client certificate and would complete the handshake when the client did not send one. I previously raised two other serious problems with an empty certification_authorities list: it is significant problem for the widespread use of multiple independent client certificates. The issue with client certs is not so much different from those plastic cards that almost everyone carries around in his wallet today-- most of us have more than one of them, and we really expect the vendors/mechants to post signs of those cards that they accept for everyone to see instead of going through trial-and-error loops through all of your cards when trying to get access somewhere or trying to pay. The other issue was "credentials access", which may create unnecessary and annoying user-popups to enter a pin/passphrase for client credentials or entering of the PIN/Passphrase on a secure SmartCard terminal on each access without the slightest confirmation that the use of that credentials has any chance to succeed in case that the server did NOT send a list of trusted certification authorities. The one thing that the current TLS-spec does not address is the PKI-free environment (which seems to be not uncommon). For this, one should probably define a protocol element to mean "I am willing to accept certain self-signed certs" in the CertificateRequest message in addition to the announced list of certification_authorities. -Martin From Martin.Rex@sap.com Tue Apr 14 12:40:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A51B28C176 for ; Tue, 14 Apr 2009 12:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU0r+f7ED2fI for ; Tue, 14 Apr 2009 12:40:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0049628C139 for ; Tue, 14 Apr 2009 12:40:02 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n3EJfChI011317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 21:41:12 +0200 (MEST) From: Martin Rex Message-Id: <200904141941.n3EJfBV7016209@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Tue, 14 Apr 2009 21:41:11 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Apr 10, 9 11:14:45 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@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, 14 Apr 2009 19:40:04 -0000 Stefan Santesson wrote: > > E.g. like: > > struct { > CachedInformationType type; > CachedInformationHash hashes<1..2^16-1>; > } CachedObject; > > struct { > CachedObject cached_info<1..2^24-1>;; > } CachedInformation; I'm wondering about the sizes of the cached objects here. The maximum size of an SSL record is 2^14 plaintext plus something. <1..2^16-1> is 64 KBytes and almost 4x the max size of an SSL record <1..2^24-1> is 16 MBytes and almost 1024x the max size of an SSL record I mean, I do understand that you really would want to cache such large objects, but are we really going to have such large elements in a single SSL handshake message? I'm not a SSL/TLS implementor, but the largest size that seems to occur in a regular SSL handshake seems to be a "feature" of the Microsoft SSL/TLS implementation for certain handshake messages, but still below 64KBytes. -Martin From Nicolas.Williams@sun.com Tue Apr 14 12:55:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE5A3A699A for ; Tue, 14 Apr 2009 12:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9Vxq+zqTSbS for ; Tue, 14 Apr 2009 12:55:05 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id CA2A928C125 for ; Tue, 14 Apr 2009 12:55:05 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EJuHh5023105 for ; Tue, 14 Apr 2009 19:56:17 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3EJuHFM047545 for ; Tue, 14 Apr 2009 13:56:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EJkrC0010790; Tue, 14 Apr 2009 14:46:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EJkpbN010789; Tue, 14 Apr 2009 14:46:51 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 14 Apr 2009 14:46:51 -0500 From: Nicolas Williams To: tls@ietf.org Message-ID: <20090414194650.GP1500@Sun.COM> References: <20090410220638.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090410220638.GM1500@Sun.COM> User-Agent: Mutt/1.5.7i Cc: Simon Josefsson Subject: Re: [TLS] Optimizing use of SASL/GS2 over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2009 19:55:06 -0000 I've posted -02: http://www.ietf.org/internet-drafts/draft-williams-tls-app-sasl-opt-02.txt Nico -- From Nicolas.Williams@sun.com Tue Apr 14 13:07:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDF03A6943 for ; Tue, 14 Apr 2009 13:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlIybgxxEUtA for ; Tue, 14 Apr 2009 13:07:25 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 6E6A13A68D3 for ; Tue, 14 Apr 2009 13:07:21 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3EK8VPL020638 for ; Tue, 14 Apr 2009 20:08:31 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3EK8US4057344 for ; Tue, 14 Apr 2009 14:08:30 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EJpabl010812; Tue, 14 Apr 2009 14:51:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EJpVr1010811; Tue, 14 Apr 2009 14:51:31 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 14 Apr 2009 14:51:31 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20090414195131.GQ1500@Sun.COM> References: <200904141941.n3EJfBV7016209@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904141941.n3EJfBV7016209@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2009 20:07:26 -0000 On Tue, Apr 14, 2009 at 09:41:11PM +0200, Martin Rex wrote: > I'm wondering about the sizes of the cached objects here. > The maximum size of an SSL record is 2^14 plaintext plus something. That's what fragmentation is for :) > <1..2^16-1> is 64 KBytes and almost 4x the max size of an SSL record Lots of TLS 1.2 types are specified as being u pto 2^16-1 bytes... > <1..2^24-1> is 16 MBytes and almost 1024x the max size of an SSL record Yes, that strikes me as rather large for a TLS handshake message, yet 64KB strikes me as rather small (we're bound to run into that boundary). So 2^24-1 seems like a reasonable next larger size. Nico -- From stefan@aaa-sec.com Tue Apr 14 22:55:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6203A6B91 for ; Tue, 14 Apr 2009 22:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFwf4Gw-e7Ai for ; Tue, 14 Apr 2009 22:55:54 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 805473A697F for ; Tue, 14 Apr 2009 22:55:33 -0700 (PDT) Received: (qmail 29281 invoked from network); 15 Apr 2009 05:56:45 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Apr 2009 05:56:45 -0000 Received: (qmail 98332 invoked from network); 15 Apr 2009 05:56:43 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Apr 2009 05:56:43 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 15 Apr 2009 07:56:35 +0200 From: Stefan Santesson To: Nicolas Williams , Martin Rex Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm9ju8HQ4VQCyv32kmvKInfUT1Jmg== In-Reply-To: <20090414195131.GQ1500@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2009 05:55:55 -0000 I agree that the boundaries for these messages are quite large, and I don't suggest that anyone should try to use them to their limits :) I just took these boundaries from what I have seen in similar TLS specs. However, in this case I think we could safely use 2^16-1 for both as we only ship hashes here. /Stefan On 09-04-14 9:51 PM, "Nicolas Williams" wrote: > On Tue, Apr 14, 2009 at 09:41:11PM +0200, Martin Rex wrote: >> I'm wondering about the sizes of the cached objects here. >> The maximum size of an SSL record is 2^14 plaintext plus something. > > That's what fragmentation is for :) > >> <1..2^16-1> is 64 KBytes and almost 4x the max size of an SSL record > > Lots of TLS 1.2 types are specified as being u pto 2^16-1 bytes... > >> <1..2^24-1> is 16 MBytes and almost 1024x the max size of an SSL record > > Yes, that strikes me as rather large for a TLS handshake message, yet > 64KB strikes me as rather small (we're bound to run into that boundary). > So 2^24-1 seems like a reasonable next larger size. > > Nico From jsalowey@cisco.com Thu Apr 16 17:28:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793563A691B for ; Thu, 16 Apr 2009 17:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OEM_BRC=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of-1E2ojpdph for ; Thu, 16 Apr 2009 17:28:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5ED053A6917 for ; Thu, 16 Apr 2009 17:28:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,201,1238976000"; d="scan'208";a="287728386" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Apr 2009 00:29:20 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3H0TKGe017395; Thu, 16 Apr 2009 17:29:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3H0TKRX018067; Fri, 17 Apr 2009 00:29:20 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 17:29:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 17:29:17 -0700 Message-ID: In-Reply-To: <200904141926.n3EJQCe9015225@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acm9NuIaqNzM0NwHRu2DPH9wzfajtgBGhc3Q References: from "Joseph Salowey" at Apr 10, 9 04:43:26 pm <200904141926.n3EJQCe9015225@fs4113.wdf.sap.corp> From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 17 Apr 2009 00:29:20.0634 (UTC) FILETIME=[8CDC2DA0:01C9BEF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5142; t=1239928160; x=1240792160; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20New=20=22Fast-Track=22=20draft= 20posted |Sender:=20; bh=Uywmm6gBWf2EH0HsCcB0kazhOVO+S/yrqQxlJTMqxVM=; b=xLa6GNfP/2a2jRgNXvZ4tkXRjoG/ZatXd4QX4xdh4XAnfqnpZwi2wbemnE bKfpnVzCHx0zKJH+L7Kcpb/ikCyDXZC1sW5ai2dDdC7YubkyRVlht6d2sYTf +p7Cy81BXw; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: stefans@exmsft.com, TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2009 00:28:08 -0000 Hi Martin, While there are cases where the client has multiple certificates to choose from, there are also cases where the client only has one. What is a client without multiple certificates going to do with the certificate authorities list if it receives one? =20 If I understand you correctly, what you would expect in this case is that the client would not authenticate with its certificate if it was not rooted in the trust list. This would prevent the fatal error in your implementation and allow the handshake to continue and possibly succeed or fail at a later point. =20 I'm not sure I really see a problem here. The client is not required to send this extension. If it has multiple certificates to choose from then it shouldn't send an extension to suppress the list. Likewise, the server is not required to use the extension and may still send the list if it is important for its implementation. =20 I think there still is a question as to whether an extension to suppress the list provides a significant improvement over the hashing scheme. =20 Cheers, Joe > -----Original Message----- > From: Martin Rex [mailto:Martin.Rex@sap.com]=20 > Sent: Tuesday, April 14, 2009 12:26 PM > To: Joseph Salowey (jsalowey) > Cc: stefan@aaa-sec.com; ekr@networkresonance.com;=20 > stefans@exmsft.com; TLS@ietf.org > Subject: Re: [TLS] New "Fast-Track" draft posted >=20 > Joseph Salowey wrote: > >=20 > > The server can include a list of certificate_authorities in the > > certificate request handshake message. If the server is configured > > with public CAs this list can be very long (longer that the=20 > > certificate chain). In many cases the client has only one=20 > certificate=20 > > or no certificate, so the trusted CA information is useless to the=20 > > client because it has no choice to make. This is really a=20 > request for=20 > > the server not to send this information so I don't see any problem=20 > > with the finished message. >=20 > While I do mostly agree that omitting the list of=20 > certification_authorities is probably not going to change the=20 > security properties of the TLS session, I STRONGLY object to=20 > omitting that parameter. >=20 > Unless there is a clear requirement for a future TLS revision=20 > to ignore unsolicited client certificates and "gracefully"=20 > continue the handshake exactly as when the client did not=20 > send the unsolicited certificate, then it is a serious=20 > problem to the TLS handshake to omit the list of=20 > certification_authorities from the CertificateRequest=20 > handshake message. >=20 > With "unsolicited" client certificate I mean one for which=20 > the client does could not positively confirm that the server=20 > will be able to build a certification path to one of its=20 > trust anchors. >=20 > In SSLv3 and TLSv1.0 it was explicitly prohibited in the spec=20 > to omit the certificate_authorities list. Starting with TLS=20 > v1.1 it is allowed as an option, but in general a pretty bad=20 > idea to do so (and in particular it is a pretty dumb idea to=20 > create a Server where such a list can not be configured). >=20 >=20 > Our (OEM) SSL implementation is going to fatally abort the=20 > SSL handshake if the server is sent a client certificate for=20 > which it can not build a certification path to one of its=20 > trust anchors -- and that is independent from whether it=20 > requires a client certificate or only requests a client=20 > certificate and would complete the handshake when the client=20 > did not send one. >=20 >=20 > I previously raised two other serious problems with an empty=20 > certification_authorities list: it is significant problem=20 > for the widespread use of multiple independent client certificates. >=20 > The issue with client certs is not so much different from=20 > those plastic cards that almost everyone carries around in=20 > his wallet today-- most of us have more than one of them, and=20 > we really expect the vendors/mechants to post signs of those=20 > cards that they accept for everyone to see instead of going=20 > through trial-and-error loops through all of your cards when=20 > trying to get access somewhere or trying to pay. >=20 > The other issue was "credentials access", which may create=20 > unnecessary and annoying user-popups to enter a=20 > pin/passphrase for client credentials or entering of the=20 > PIN/Passphrase on a secure SmartCard terminal on each access=20 > without the slightest confirmation that the use of that=20 > credentials has any chance to succeed in case that the server=20 > did NOT send a list of trusted certification authorities. >=20 >=20 > The one thing that the current TLS-spec does not address is=20 > the PKI-free environment (which seems to be not uncommon). > For this, one should probably define a protocol element to=20 > mean "I am willing to accept certain self-signed certs" in=20 > the CertificateRequest message in addition to the announced=20 > list of certification_authorities. >=20 >=20 >=20 > -Martin >=20 From Nicolas.Williams@sun.com Fri Apr 17 12:47:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D750B28C12D for ; Fri, 17 Apr 2009 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsdr9J-czRWZ for ; Fri, 17 Apr 2009 12:47:50 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id CBDD228C1B1 for ; Fri, 17 Apr 2009 12:46:28 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3HJlgbq014458 for ; Fri, 17 Apr 2009 19:47:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3HJlg3l051753 for ; Fri, 17 Apr 2009 13:47:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3HJcFw5013166 for ; Fri, 17 Apr 2009 14:38:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3HJcFcf013165 for tls@ietf.org; Fri, 17 Apr 2009 14:38:15 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 17 Apr 2009 14:38:15 -0500 From: Nicolas Williams To: tls@ietf.org Message-ID: <20090417193814.GV1500@Sun.COM> References: <20090410220638.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090410220638.GM1500@Sun.COM> User-Agent: Mutt/1.5.7i Subject: Re: [TLS] Optimizing use of SASL/GS2 over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2009 19:47:50 -0000 I've submitted -03, with a large simplification over earlier versions. The only thing in this I-D that can be thought of as a state machine change is the option to allow the application to send application data before the server's Finished message is received (but, of course, after the client's Finished message is sent). Nico -- From mbadra@gmail.com Mon Apr 20 05:52:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3899328C2AB for ; Mon, 20 Apr 2009 05:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apE-CRax24dQ for ; Mon, 20 Apr 2009 05:52:11 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 2E45E28C2A6 for ; Mon, 20 Apr 2009 05:52:11 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so186271fgb.18 for ; Mon, 20 Apr 2009 05:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=jTCuDfvZv5z2HISLwj7m6hWde/NuYOBO6m3vBldwaRU=; b=pJhcfwJI0/JV8R1oKm3lp8+z5B5H/jtu/ouH13skQKKtENXCwFQDnwFYVZkETEtbCv aLjwnACXHYDte87K+KkOdrjalWHiqa1HMNK5mno8mVKZp/Li7bId992AsrrFoHwRgqzT 84FZiCA4P6ybJhNwuT2Kyvql//atVOlY9XoFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=tnOS3k0X8LD1KK+KQ5pL+AcklMUiPrdyXbvV6mlWY17m8DCPgKJDIUkpU6AhLGRfUb fXgcW/YBUYgYxjSkt4YionwXPRW/uTGOetvtVBXmtv3qlMVHPoCtJVBq/XEGMCjgemZN kCR7KwB0ZncJguY01Wh/7DTUd2VqIob5V1hdg= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.49.13 with SMTP id w13mr3891091fgw.67.1240232005842; Mon, 20 Apr 2009 05:53:25 -0700 (PDT) Date: Mon, 20 Apr 2009 14:53:25 +0200 X-Google-Sender-Auth: 4ae2102b614324a1 Message-ID: From: Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=000e0cd245ea25b6d50467fc0402 Subject: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 12:52:12 -0000 --000e0cd245ea25b6d50467fc0402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, We have posted a document that describes "multi-threaded application" multiplexing over a single TLS session. Comments are welcome. Best regards, Badra The Transport Layer Security (TLS) is the most widely deployed protocol for securing network traffic. It provides mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex single-application multiple-stream applications that commonly use parallel connections to the same logical and/or physical server application data. This document describes a mechanism to multiplex single-application multiple-stream over TLS. It extends TLS to multiplex parallel connections of a given application over a single TLS session, avoiding additional delay related to the TLS/TCP session/connection setup. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt --000e0cd245ea25b6d50467fc0402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
We have posted a document that describes "multi= -threaded application" multiplexing over=A0a single TLS session= .
=A0
Comments are welcome.
Best regards,
Badra
=A0
The Transport Layer Security (TLS) is the most widely deployed
prot= ocol for securing network traffic. =A0It provides mutual
authentication,= data confidentiality and integrity, key generation
and distribution, an= d security parameters negotiation. =A0However,
missing from the protocol is a way to multiplex single-application
multi= ple-stream applications that commonly use parallel connections
to the sa= me logical and/or physical server application data.

This document de= scribes a mechanism to multiplex single-application
multiple-stream over TLS. =A0It extends TLS to multiplex parallel
connec= tions of a given application over a single TLS session,
avoiding additio= nal delay related to the TLS/TCP session/connection
setup.

A URL = for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-badra-= tls-multiplexing-00.txt
--000e0cd245ea25b6d50467fc0402-- From stefan@aaa-sec.com Mon Apr 20 09:27:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6144A3A6F50 for ; Mon, 20 Apr 2009 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSBQF1zLMUvS for ; Mon, 20 Apr 2009 09:27:09 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 3D5613A6F7E for ; Mon, 20 Apr 2009 09:27:08 -0700 (PDT) Received: (qmail 48921 invoked from network); 20 Apr 2009 16:28:28 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Apr 2009 16:28:28 -0000 Received: (qmail 45804 invoked from network); 20 Apr 2009 16:28:21 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Apr 2009 16:28:21 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 20 Apr 2009 18:28:20 +0200 From: Stefan Santesson To: Min Huang , "'Joseph Salowey (jsalowey)'" , Message-ID: Thread-Topic: =?Big5?B?tarOYA==?=: [TLS] New "Fast-Track" draft posted Thread-Index: Acm9NuIaqNzM0NwHRu2DPH9wzfajtgBGhc3QAMbaT5AAGihsxg== In-Reply-To: <000601c9c197$621ed4e0$909a1b0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: stefans@exmsft.com, TLS@ietf.org Subject: Re: [TLS] =?big5?b?tarOYCA6ICBOZXcgIkZhc3QtVHJhY2siIGRyYWZ0IHBvc3Rl?= =?big5?b?ZA==?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 16:27:10 -0000 I think we agree but why would the client send an empty cashedInformationHash instead of sending a hash over the cached information? /Stefan On 09-04-20 11:07 AM, "Min Huang" wrote: > The > client may cache this information sent by the specific server at the first > time they > communicate with each other. The corresponding CachedInformationHash > contained in the extension of the Client hello message may be empty. It > indicates that the client has already known the trusted CA list of the > server and it > has certificates trusted by the server. From Michael.G.Williams@nokia.com Mon Apr 20 09:36:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0853A6EB0 for ; Mon, 20 Apr 2009 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNols-L0s3dF for ; Mon, 20 Apr 2009 09:36:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5E4603A6F7E for ; Mon, 20 Apr 2009 09:36:57 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3KGbgBF003463; Mon, 20 Apr 2009 19:38:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 19:37:52 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 19:37:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 19:37:47 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 20 Apr 2009 18:37:40 +0200 From: To: Date: Mon, 20 Apr 2009 18:37:38 +0200 Thread-Topic: Mobi-d next steps Thread-Index: Acm9NuIaqNzM0NwHRu2DPH9wzfajtgBGhc3QAMbaT5AAGihsxgAAL6Rg Message-ID: References: <000601c9c197$621ed4e0$909a1b0a@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2009 16:37:47.0296 (UTC) FILETIME=[565E6A00:01C9C1D6] X-Nokia-AV: Clean Cc: tuexen@fh-muenster.de, Michael.G.Williams@nokia.com, Jeremey.Barrett@nokia.com Subject: [TLS] Mobi-d next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 16:36:58 -0000 Thanks to Eric and Joe for the time slot to get started on mobile DTLS. Aft= er the meeting, several more people came up and requested to be involved an= d voiced support for taking the work on. That is great. The chairs have requested we pull in some more mobility expertise to the TL= S team, so Michael Tuexen was chosen to help with that. Please contact Mich= ael and myself if you are interested in implementation, further devlopment = of the spec, and can provide mobility expertise. Kind Regards, Michael = From Nicolas.Williams@sun.com Mon Apr 20 09:48:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5768E3A6F88 for ; Mon, 20 Apr 2009 09:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ov8mlwfyHUB for ; Mon, 20 Apr 2009 09:48:29 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 229543A6F86 for ; Mon, 20 Apr 2009 09:48:29 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KGngoZ014710 for ; Mon, 20 Apr 2009 16:49:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3KGngSk001430 for ; Mon, 20 Apr 2009 10:49:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3KGeD77014640; Mon, 20 Apr 2009 11:40:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3KGe2NF014639; Mon, 20 Apr 2009 11:40:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 20 Apr 2009 11:40:02 -0500 From: Nicolas Williams To: Badra Message-ID: <20090420164002.GI1500@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 16:48:30 -0000 On Mon, Apr 20, 2009 at 02:53:25PM +0200, Badra wrote: > We have posted a document that describes "multi-threaded application" > multiplexing over a single TLS session. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt Seems very similar in scope to SSHv2's multiplexing. Have you looked at SSHv2, specifically RFC4254? There have been problems getting SSHv2 implementations to grow channel windows so that the maximum available bandwidth can be used. Have you looked at these issues? Nico -- From n.mavrogiannopoulos@gmail.com Mon Apr 20 09:52:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0C83A6FA6 for ; Mon, 20 Apr 2009 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poZuybwir8mz for ; Mon, 20 Apr 2009 09:52:39 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 8C9893A6B1A for ; Mon, 20 Apr 2009 09:52:39 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so949955fkq.5 for ; Mon, 20 Apr 2009 09:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=/QKELcXkHAM1/Wgc6UXswnipIhkMtldWxzvg95Yqa+4=; b=AehhGxZ4SuoQ65sjwj4hkqr++KcGAxnXW3b7/SqccfiSLo2qzolnwOUcnlNGjxoDWk Eor9LeYZ0Pb42/ZtSm3O96i1xoRquTW3onu40+w1vir2k1kYZ8BH7SowSDmbhiyFAaet 2mfyG9KrNRx0hoxYd/LOpeB97GX2IA4PiwMS8= 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=lWpsCs14el6TNJF99ZJ8gwcQelYAvIvBKCV1+GCIfH9LBW7hM0+vKwVBx7NHWCDZiQ u7DOLKE5j4EsS37ciKkKVh21R/yWy5M5aLbv9bT9U+T3oCZxHD8x9EPdUORkfC1zKXS/ bNGUb6Ej0DUUlT4wCsRUfytwA6g8ZGntnbikg= Received: by 10.103.213.19 with SMTP id p19mr3221374muq.9.1240246434815; Mon, 20 Apr 2009 09:53:54 -0700 (PDT) Received: from ?10.100.1.196? (adsl108-163.ath.forthnet.gr [79.103.119.163]) by mx.google.com with ESMTPS id y6sm14456955mug.25.2009.04.20.09.53.52 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 09:53:53 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <49ECA89D.9010404@gnutls.org> Date: Mon, 20 Apr 2009 19:53:49 +0300 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Badra References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 16:52:40 -0000 Badra wrote: > Hi all, > > We have posted a document that describes "multi-threaded application" > multiplexing over a single TLS session. Hello, Is TLS the appropriate level to do this protocol? Couldn't it be over TLS, or over any protocol that is being used at the moment? It looks it has a broader applicability than just TLS. regards, Nikos From mbadra@gmail.com Mon Apr 20 10:19:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3AD28C0FD for ; Mon, 20 Apr 2009 10:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp8J+GjtwegY for ; Mon, 20 Apr 2009 10:19:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 85C583A6AA5 for ; Mon, 20 Apr 2009 10:19:06 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so211407fge.18 for ; Mon, 20 Apr 2009 10:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Lz06L6pWA98pD/HmdoCaJOZaDpfRvJiv3SrSPHgAqQ4=; b=WkzeXnA5rcafSAYvUvBZDibZ64WXJD8RgcIhlN/CQe/jQAgUqJ5dezfXsueYvuncmt Xt2DVxBry1eWbfCf2HwhB4O8HRnoZdWKdA2JwOyxLPr275VPHi20HkGnIYxEWNrU5CUZ 5axJJDPkQjT4Dop2XeGxvR/9jIDRief4bXHDM= 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; b=M6K2Oi9R1yvktRGCIx+JM2VmlITLBu6DKP6FMsbVAZFYB210nUSb/kLiiI+gyVWBJf bSlvAYEXJ/ElK7n8qXwgtiS1L4K3JGP31zirHUCrnPLZVlaWaDEH06VKlQ7L9XagVLKz Gacx4WfMpzxjnTBuHYhpSHmBTpRKbLCRetgnQ= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.51.10 with SMTP id y10mr4095647fgy.51.1240248021816; Mon, 20 Apr 2009 10:20:21 -0700 (PDT) In-Reply-To: <49ECA89D.9010404@gnutls.org> References: <49ECA89D.9010404@gnutls.org> Date: Mon, 20 Apr 2009 19:20:21 +0200 X-Google-Sender-Auth: 8574b0c78ae341ce Message-ID: From: Badra To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=000e0cd3404ec616b00467ffbe4c Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 17:19:07 -0000 --000e0cd3404ec616b00467ffbe4c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > We have posted a document that describes "multi-threaded application" > > multiplexing over a single TLS session. > > Hello, > Is TLS the appropriate level to do this protocol? Couldn't it be over > TLS, or over any protocol that is being used at the moment? It looks it > has a broader applicability than just TLS. Hi Nikos, This could be done over TLS, but IMO, it is better to negotiate the multiplexing functionality early during TLS Handshake and to share the same code for several applications running over TLS. (An expired document describes it over TLS draft-badra-hajjeh-mtls-04) Best regards, Badra --000e0cd3404ec616b00467ffbe4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> We have posted a document that describes "multi-threaded app= lication"
> multiplexing over a single TLS session.

Hello,
=A0Is TLS the appropriate level to do this protocol? Couldn'= t it be over
TLS, or over any protocol that is being used at the moment? It looks it
= has a broader applicability than just TLS.
=A0
=A0
Hi Nikos,
=A0
This could be done over TLS, but IMO, it is bett= er to negotiate the multiplexing functionality early during TLS Handshake a= nd to share the same code for several applications running over TLS. (An ex= pired document describes it over TLS=A0draft-badra-hajjeh-mtls-04)
=A0
Best regards,
Badra
--000e0cd3404ec616b00467ffbe4c-- From mbadra@gmail.com Mon Apr 20 10:20:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB603A69B7 for ; Mon, 20 Apr 2009 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+0+0FuKZ6gf for ; Mon, 20 Apr 2009 10:20:32 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id B71D63A6AA5 for ; Mon, 20 Apr 2009 10:20:31 -0700 (PDT) Received: by fxm2 with SMTP id 2so2083923fxm.37 for ; Mon, 20 Apr 2009 10:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=n7taUKLkFzpmH4vNF8oLqUzcH6emt9ddS0lcjL10sT8=; b=HB9TNRyGoBmhzfdsnlQbMf0nr0epxB/5B0k4WEAL5FplrVOKBKxbOmCbY0CxB+8Kxc QR9p6gjR+m1f3ivGos+HfN7v0MYnw99e9B3dNBTNef52ahh8VQjfN3f9atg5Qp3lo64M ffV9f7l/MIpXbGTNVuBir19FOV4q/r8Wa6x1E= 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; b=pxlSb8DdF8xLb95JXYehyXcUQuKlhM/DT7xVV77Uu2SaDLmPAVubcLnNdN/S7AlTNk Fk5JckydDh71J8YVNGoeJexPATQ1EZwYH+if0c/Uoj0GSPyJeNMVEn+F19I2yROPt8VZ FvDf+uJWMAkMkybKFWV0axVHMbcq1BaM6nBo4= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.80.5 with SMTP id d5mr4155672fgb.6.1240248106450; Mon, 20 Apr 2009 10:21:46 -0700 (PDT) In-Reply-To: <20090420164002.GI1500@Sun.COM> References: <20090420164002.GI1500@Sun.COM> Date: Mon, 20 Apr 2009 19:21:46 +0200 X-Google-Sender-Auth: c3951d9f71d20e28 Message-ID: From: Badra To: Nicolas Williams Content-Type: multipart/alternative; boundary=000e0cd297f0d17e980467ffc391 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 17:20:32 -0000 --000e0cd297f0d17e980467ffc391 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Apr 20, 2009 at 6:40 PM, Nicolas Williams wrote: > On Mon, Apr 20, 2009 at 02:53:25PM +0200, Badra wrote: > > We have posted a document that describes "multi-threaded application" > > multiplexing over a single TLS session. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt > > Seems very similar in scope to SSHv2's multiplexing. > > Have you looked at SSHv2, specifically RFC4254? There have been > problems getting SSHv2 implementations to grow channel windows so that > the maximum available bandwidth can be used. Have you looked at these > issues? > > Hi Nicolas, I agree, the document provides some of the RFC4254 services, but honestly I am not aware of SSHv2 problems. Any link, help or suggestion to avoid these issues are appreciated. Best regards, Badra --000e0cd297f0d17e980467ffc391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 20, 2009 at 6:40 PM, Nicolas William= s <Nicolas.Williams@sun.com> wrote:
On Mon, Apr 20, 2009 at 02:53:25PM +0200, Badra wrote:
> We have= posted a document that describes "multi-threaded application"> multiplexing over a single TLS session.
>
Seems very similar in scope to SSHv2's multiplexing.

H= ave you looked at SSHv2, specifically RFC4254? =A0There have been
proble= ms getting SSHv2 implementations to grow channel windows so that
the max= imum available bandwidth can be used. =A0Have you looked at these
issues?

=A0

=A0
Hi Nicolas,

=A0
I agree, the document provides some o= f the RFC4254 services, but honestly I am not aware of SSHv2 problems. Any = link, help=A0or suggestion to avoid these issues=A0are appreciated.
=A0<= /div>

Best regards,
Badra
--000e0cd297f0d17e980467ffc391-- From stpeter@stpeter.im Mon Apr 20 10:26:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E013A6EAE for ; Mon, 20 Apr 2009 10:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt-ZUAjYhS0D for ; Mon, 20 Apr 2009 10:26:08 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 972213A6F81 for ; Mon, 20 Apr 2009 10:25:59 -0700 (PDT) Received: from wrk165.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id AD28DE803D; Mon, 20 Apr 2009 11:27:14 -0600 (MDT) Message-ID: <49ECB072.8070908@stpeter.im> Date: Mon, 20 Apr 2009 11:27:14 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <49ECA89D.9010404@gnutls.org> In-Reply-To: <49ECA89D.9010404@gnutls.org> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 17:26:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/20/09 10:53 AM, Nikos Mavrogiannopoulos wrote: > Badra wrote: >> Hi all, >> >> We have posted a document that describes "multi-threaded application" >> multiplexing over a single TLS session. > > Hello, > Is TLS the appropriate level to do this protocol? Couldn't it be over > TLS, or over any protocol that is being used at the moment? It looks it > has a broader applicability than just TLS. In the XMPP community we are interested in something similar: the ability to multiplex multiple domain-to-domain streams over a single encrypted connection. Joe Hildebrand and I plan to write up at least a requirements I-D about that soon. It's not yet clear to me if our use case is in scope for draft-badra-tls-multiplexing. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknssHIACgkQNL8k5A2w/vxkKACgjym7ECIL4ntl/45SBbRQEo05 1+EAn2IsB/kkkYd/bEmL5gDqwku6VTck =f4Xx -----END PGP SIGNATURE----- From Nicolas.Williams@sun.com Mon Apr 20 11:11:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45B33A6B42 for ; Mon, 20 Apr 2009 11:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRw8HprEabJP for ; Mon, 20 Apr 2009 11:11:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id BBD863A6B13 for ; Mon, 20 Apr 2009 11:11:03 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KICJlW003250 for ; Mon, 20 Apr 2009 18:12:19 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3KICIbs050422 for ; Mon, 20 Apr 2009 12:12:18 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3KI2ouB014705; Mon, 20 Apr 2009 13:02:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3KI2j7c014704; Mon, 20 Apr 2009 13:02:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 20 Apr 2009 13:02:45 -0500 From: Nicolas Williams To: Badra Message-ID: <20090420180244.GL1500@Sun.COM> References: <20090420164002.GI1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 18:11:11 -0000 On Mon, Apr 20, 2009 at 07:21:46PM +0200, Badra wrote: > I agree, the document provides some of the RFC4254 services, but honestly I > am not aware of SSHv2 problems. Any link, help or suggestion to avoid these > issues are appreciated. A comparison of your proposal to RFC4254 would be useful: what are you doing differently from SSHv2 and why. Here's one link regarding SSHv2 and high performance networking: http://www.psc.edu/networking/projects/hpn-ssh/ I'm not sure that there's anything wrong with the actual protocol though. There's no way to reduce a channel's window other than by not adjusting it for received data, but I'm not sure that that's a problem. Of course, I'm not sure anyone is actually trying to mix interactive, small packet traffic with bulk data transfers in an high performance networking environment... Nico -- From ekr@networkresonance.com Mon Apr 20 11:30:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DBE28C2F7 for ; Mon, 20 Apr 2009 11:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baGld1z9Vh6P for ; Mon, 20 Apr 2009 11:30:17 -0700 (PDT) Received: from kilo.networkresonance.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C3CC328C2EB for ; Mon, 20 Apr 2009 11:30:17 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 81FB6185AE0; Mon, 20 Apr 2009 11:33:41 -0700 (PDT) Date: Mon, 20 Apr 2009 11:33:41 -0700 From: Eric Rescorla To: Badra In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090420183341.81FB6185AE0@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 18:30:18 -0000 At Mon, 20 Apr 2009 14:53:25 +0200, Badra wrote: > We have posted a document that describes "multi-threaded application" > multiplexing over a single TLS session. Are there any IETF WGs who are interested in TLS providing this functionality? -Ekr From mbadra@gmail.com Mon Apr 20 11:49:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10B428C18F for ; Mon, 20 Apr 2009 11:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hFR333uNooH for ; Mon, 20 Apr 2009 11:49:52 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 9C7B43A6FD4 for ; Mon, 20 Apr 2009 11:49:51 -0700 (PDT) Received: by bwz7 with SMTP id 7so1374394bwz.37 for ; Mon, 20 Apr 2009 11:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=PyON0y97yrMgh77vxDW4oFRNOU4SZPk/XVrQhaIAVlE=; b=B+a07v8YFquI+BykEnRf3bSY6M60uDAftrayg83VkQS6sOGv9uRkRtmR6+U8DN5f/A uLtwR3fKFsYNMATwno5AYgd13IfvAMRRd1TY2RneEoU51LxMZGsv4I21dUxiSxplnQA1 mhOkVhACYtJxrJ0/EdDsu58m07IHW6wng67Q4= 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; b=qE2VBTLN0GPcDbBvKo3zq7PWznXMd68DjJnBL9nZRLLUsnTtFA69UCsfTAvttZAmQD TBEc6kgdHlH0IyOfjOVe6rZMg1Ms4aLBnhpM5FcXp0yrQ8nnRaDTY0GR4qlk6s2fpg2Q +1p9FZs2jGORwozrm1M0bgdReLsk3TErn52qE= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.204.58.9 with SMTP id e9mr5669185bkh.23.1240253466514; Mon, 20 Apr 2009 11:51:06 -0700 (PDT) In-Reply-To: <20090420183341.81FB6185AE0@kilo.networkresonance.com> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> Date: Mon, 20 Apr 2009 20:51:06 +0200 X-Google-Sender-Auth: 19055e1b7b170636 Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=001636c5bcc54d95b20468010320 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 18:49:52 -0000 --001636c5bcc54d95b20468010320 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > We have posted a document that describes "multi-threaded application" > > multiplexing over a single TLS session. > > Are there any IETF WGs who are interested in TLS providing this > functionality? > > -Ekr > Hi Eric, I think the transport folks could be interested. They have concerns with bad congestion control properties of the massive parallel connection practice in contemporary web browsers. Best regards, Badra --001636c5bcc54d95b20468010320 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> We have posted a document that describes "multi-threaded app= lication"
> multiplexing over a single TLS session.

Are there any IETF WGs who are interested in TLS providing this
functio= nality?

-Ekr

=A0
Hi Eric,
=A0
I think the transport folks could be interested. They=A0have concerns = with bad congestion control properties of the massive parallel connection p= ractice in contemporary web browsers.
=A0
Best regards,
Badra
--001636c5bcc54d95b20468010320-- From Nicolas.Williams@sun.com Mon Apr 20 12:04:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2D328C333 for ; Mon, 20 Apr 2009 12:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.871 X-Spam-Level: X-Spam-Status: No, score=-5.871 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxE0fm5vRrId for ; Mon, 20 Apr 2009 12:04:29 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 5F95F28C338 for ; Mon, 20 Apr 2009 12:03:17 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KJ4XKd027140 for ; Mon, 20 Apr 2009 19:04:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3KJ4X6h045328 for ; Mon, 20 Apr 2009 13:04:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3KIt58h014773; Mon, 20 Apr 2009 13:55:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3KIt3Kn014772; Mon, 20 Apr 2009 13:55:03 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 20 Apr 2009 13:55:03 -0500 From: Nicolas Williams To: Badra Message-ID: <20090420185503.GS1500@Sun.COM> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 19:04:30 -0000 On Mon, Apr 20, 2009 at 08:51:06PM +0200, Badra wrote: > I think the transport folks could be interested. They have concerns with bad > congestion control properties of the massive parallel connection practice in > contemporary web browsers. So this is about HTTP? Or do you have other applications in mind as well. I think there are fairly few Internet protocols that could benefit from this (e.g., IMAP, LDAP -- these don't need to multiplex data streams as they are already capable of multiplexing their operations), but HTTP certainly seems like one of those that could. SMTP might also be able to use multiplexing as a way to keep a single connection open without having to queue small messages behind large ones. Nico -- From mbadra@gmail.com Mon Apr 20 12:26:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE73C3A696F for ; Mon, 20 Apr 2009 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSns1PwG22qE for ; Mon, 20 Apr 2009 12:26:06 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 9ED693A6FDD for ; Mon, 20 Apr 2009 12:25:57 -0700 (PDT) Received: by bwz7 with SMTP id 7so1392772bwz.37 for ; Mon, 20 Apr 2009 12:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=D+8tFu+/6xn/tvIhUSZRplFMtMUEH7HRg4+Lu3MTGMI=; b=F/oEO/+p0IQmh7ZqdD4ElA4E8UkDkHR8tfiDZFVJ9jynwLxbyGZuItjtLsAQqFABnr 4318LpRrd7n3owRADYIHr0iHbXNZW4HYEPBIwWWjOWiJyHLdI+u8P7ME2J/N1IEDvfxv TX3tBczYt3AGNtEAYBuc7ULBdZIbRJ/+OQJ+4= 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; b=LPTAVdfhbkZfz/vLOib2U8nRANqmTPhBcWzH9LWO/haQNLvC4wKojNP92Z4pVmZpc9 aZ0t9wxteixeSJJOC7lqW8zych7KouH9H89xtaxDAewzCgDRgdAFe5TpJYiNawwwBSC8 6ulsxQgbGeGa/jAyiAzTFPGQhsEY2s/a/wO0Q= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.204.61.204 with SMTP id u12mr5676875bkh.149.1240255632629; Mon, 20 Apr 2009 12:27:12 -0700 (PDT) In-Reply-To: <20090420185503.GS1500@Sun.COM> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420185503.GS1500@Sun.COM> Date: Mon, 20 Apr 2009 21:27:12 +0200 X-Google-Sender-Auth: 57d3adc74dc5d3a7 Message-ID: From: Badra To: Nicolas Williams Content-Type: multipart/alternative; boundary=001636c5b27c69df4804680184ef Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 19:26:07 -0000 --001636c5b27c69df4804680184ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Apr 20, 2009 at 8:55 PM, Nicolas Williams wrote: > On Mon, Apr 20, 2009 at 08:51:06PM +0200, Badra wrote: > > I think the transport folks could be interested. They have concerns with > bad > > congestion control properties of the massive parallel connection practice > in > > contemporary web browsers. > > So this is about HTTP? Or do you have other applications in mind as > well. > No, I just gave an example. It is about any application (over TLS) that doesn't provide connection mutiplexing. Best regards, Badra --001636c5b27c69df4804680184ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 20, 2009 at 8:55 PM, Nicolas William= s <Nicolas= .Williams@sun.com> wrote:
On Mon, Apr 20, 2009 at 08:51:06PM +0200, Badra wrote:> I think the transport folks could be interested. They have concerns w= ith bad
> congestion control properties of the massive parallel conne= ction practice in
> contemporary web browsers.

So this is about HTTP? =A0Or d= o you have other applications in mind as
well.
=A0
=A0
No, I just gave an example. It is about any application (over TLS) tha= t doesn't provide connection mutiplexing.
Best regards,
Badra
--001636c5b27c69df4804680184ef-- From ekr@networkresonance.com Mon Apr 20 12:38:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AA03A6B3E for ; Mon, 20 Apr 2009 12:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX28WsupxH6J for ; Mon, 20 Apr 2009 12:38:31 -0700 (PDT) Received: from kilo.networkresonance.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 220F13A6A6C for ; Mon, 20 Apr 2009 12:38:31 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E72DC185B38; Mon, 20 Apr 2009 12:41:54 -0700 (PDT) Date: Mon, 20 Apr 2009 12:41:54 -0700 From: Eric Rescorla To: Badra In-Reply-To: References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090420194154.E72DC185B38@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 19:38:32 -0000 At Mon, 20 Apr 2009 20:51:06 +0200, > I think the transport folks could be interested. They have concerns with bad > congestion control properties of the massive parallel connection practice in > contemporary web browsers. I have a fair amount of skepticism about the relevance of this application: 1. My understanding is that the browser manufacturers consider the transport impacts (higher link share utilization, no head of line blocking) of multiple connections to be a feature, not a bug, regardless of what the IETF Transport Area thinks. 2. Just thinking about how, e.g., Apache is architected, it seems to me that making use of this functionality would likely entail fairly substantial modifications to the Web server in many cases. 3. Given that most Web traffic happens not over HTTPS, I would expect that there would be much more interest in a solution which worked above the TLS layer and therefore would work for all Web traffic. Has anyone from the Web community expressed interest in this feature? -Ekr From dean@av8.com Mon Apr 20 13:16:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31CC3A6FEA for ; Mon, 20 Apr 2009 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aec0dLqZZQ6 for ; Mon, 20 Apr 2009 13:16:31 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id B77953A6FD7 for ; Mon, 20 Apr 2009 13:16:21 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n3KKHaXq022449 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 20 Apr 2009 16:17:36 -0400 Date: Mon, 20 Apr 2009 16:17:35 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla In-Reply-To: <20090420194154.E72DC185B38@kilo.networkresonance.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 20:16:32 -0000 I think HTTP request multiplexing is definitely a good idea, especially for things like ajax, which sometimes start multiple TCP connections on the server with all the overhead or else have to be serialized. I definitely encourage your idea, but I think it should be independent of TLS. I don't think its a good idea to do this at the TLS layer. --Dean On Mon, 20 Apr 2009, Eric Rescorla wrote: > At Mon, 20 Apr 2009 20:51:06 +0200, > > I think the transport folks could be interested. They have concerns with bad > > congestion control properties of the massive parallel connection practice in > > contemporary web browsers. > > I have a fair amount of skepticism about the relevance of this application: > > 1. My understanding is that the browser manufacturers consider the > transport impacts (higher link share utilization, no head of > line blocking) of multiple connections to be a feature, not > a bug, regardless of what the IETF Transport Area thinks. > > 2. Just thinking about how, e.g., Apache is architected, it > seems to me that making use of this functionality would > likely entail fairly substantial modifications to the Web server > in many cases. > > 3. Given that most Web traffic happens not over HTTPS, I would expect > that there would be much more interest in a solution which > worked above the TLS layer and therefore would work for all > Web traffic. > > Has anyone from the Web community expressed interest in this feature? > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From mbadra@gmail.com Mon Apr 20 13:22:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8E03A692C for ; Mon, 20 Apr 2009 13:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDEFsVr1Baxp for ; Mon, 20 Apr 2009 13:22:02 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 9E1ED3A6813 for ; Mon, 20 Apr 2009 13:22:01 -0700 (PDT) Received: by fxm2 with SMTP id 2so2176964fxm.37 for ; Mon, 20 Apr 2009 13:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=xB+IzVcZYeGZt8W+KmCbtNlIzKbD79B6DI894sWmQ1g=; b=XGfB00EuYHZxmLdR/g2pr9+MqjfbCK330UH7l8ZamaVx/dpQKVMHeGtbzoC2hU1WCa YH4IQCvLj0/cX2dVavuqUt/dZR1s86fA8IZv4haeoRfruCeOatA27XaYpvS/F44ZcUIi Ty6d4hmFUPL/PzA75u1NcMGuYCp6xofhiJyhU= 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; b=WbdExg1mU68YUQIwh95137C4Bis9FQktNHBYMiYwcpCn6qtr4u3i5B0OJLjML7Mtlz Zrxjn8T2CYITYOIcNu8Ii7nsyN1E606/JYNqEnOW8s0HECCSy8HMn3NDh0i/t4kP8lGk u2Q20hLLfm9V8572Icxlq+wsiXAuLWJ50r5Ok= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.204.113.203 with SMTP id b11mr5730306bkq.116.1240258996757; Mon, 20 Apr 2009 13:23:16 -0700 (PDT) In-Reply-To: <20090420194154.E72DC185B38@kilo.networkresonance.com> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> Date: Mon, 20 Apr 2009 22:23:16 +0200 X-Google-Sender-Auth: ac33c9b22de03b0e Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=00163662e5e4ee68260468024c11 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 20:22:03 -0000 --00163662e5e4ee68260468024c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla wrote: > > Has anyone from the Web community expressed interest in this feature? > Eric, honestly I don't see why all these questions. The document is posted since only 7 hours, and I didn't contact offline any persons "off-line" for their comments. Best regards, Badra --00163662e5e4ee68260468024c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@networkresonance.com> wrote:

Has anyone from the Web comm= unity expressed interest in this feature?
=A0
=A0
Eric, honestly I don't see why all these questions.=A0The document= is posted since=A0only 7 hours, and I didn't=A0contact offline=A0any p= ersons=A0"off-line" for their comments.
=A0
Best regards,
Badra
--00163662e5e4ee68260468024c11-- From simon@josefsson.org Mon Apr 20 13:37:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFA53A6D1F for ; Mon, 20 Apr 2009 13:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoaEkPOqEK1S for ; Mon, 20 Apr 2009 13:37:07 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id BCC203A6DDF for ; Mon, 20 Apr 2009 13:36:10 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Lw0F0-00045s-Ah; Mon, 20 Apr 2009 22:37:23 +0200 From: Simon Josefsson To: Badra References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420185503.GS1500@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090420:tls@ietf.org::qZD3EzEDTpde42/u:1e1d X-Hashcash: 1:22:090420:nicolas.williams@sun.com::lYqKBUS6vDzGso2s:1XTv X-Hashcash: 1:22:090420:badra@isima.fr::G5/SdSQgAJIetTxd:UuQE Date: Mon, 20 Apr 2009 22:37:20 +0200 In-Reply-To: (badra@isima.fr's message of "Mon, 20 Apr 2009 21:27:12 +0200") Message-ID: <8763gzxdrz.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org, Nicolas Williams Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 20:37:08 -0000 Badra writes: > On Mon, Apr 20, 2009 at 8:55 PM, Nicolas Williams > wrote: > >> On Mon, Apr 20, 2009 at 08:51:06PM +0200, Badra wrote: >> > I think the transport folks could be interested. They have concerns with >> bad >> > congestion control properties of the massive parallel connection practice >> in >> > contemporary web browsers. >> >> So this is about HTTP? Or do you have other applications in mind as >> well. >> > > > No, I just gave an example. It is about any application (over TLS) that > doesn't provide connection mutiplexing. When I read the draft, I was thinking that it would be a useful technique for VPN implementations that just want to set up one TLS channel to the VPN server and then multiplex other channels through that primary channel. There is OpenVPN which is based on TLS, but it uses a rather ad-hoc protocol [1] to implement a VPN. A more standards-aligned way would be to implement a VPN using TLS (or even DTLS?) together with multiplexing. /Simon [1] http://openvpn.org/index.php/documentation/security-overview.html From Nicolas.Williams@sun.com Mon Apr 20 14:08:51 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FCB3A6DE9 for ; Mon, 20 Apr 2009 14:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.871 X-Spam-Level: X-Spam-Status: No, score=-5.871 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nipxWyQ12Ivb for ; Mon, 20 Apr 2009 14:08:50 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 2B96D3A68C4 for ; Mon, 20 Apr 2009 14:08:50 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KLA6GP000040 for ; Mon, 20 Apr 2009 21:10:06 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3KLA5ur012295 for ; Mon, 20 Apr 2009 15:10:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3KL0ZRc014876; Mon, 20 Apr 2009 16:00:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3KL0XO6014875; Mon, 20 Apr 2009 16:00:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 20 Apr 2009 16:00:33 -0500 From: Nicolas Williams To: Badra Message-ID: <20090420210033.GC1500@Sun.COM> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 21:08:51 -0000 On Mon, Apr 20, 2009 at 10:23:16PM +0200, Badra wrote: > On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla wrote: > > Has anyone from the Web community expressed interest in this feature? > > Eric, honestly I don't see why all these questions. The document is posted > since only 7 hours, and I didn't contact offline any persons "off-line" for > their comments. I do. Eric is quite right to point out that retrofitting existing apps to use this facility may be difficult to the point that it won't happen. If it won't happen then why do it? Also, Eric's interest in whether there is IETF interest in this for use in Internet protocols is important to determining how much interest TLS WG (and other) participants may have. I also agree that this should be a separate layer, but negotiation of it in TLS handshakes is useful as a way to start that layer sooner rather than having to have an application-layer round-trip to negotiate its use. Nico -- From Michael.Tuexen@lurchi.franken.de Mon Apr 20 14:56:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94CD3A6964 for ; Mon, 20 Apr 2009 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jw8U0vtw-B7 for ; Mon, 20 Apr 2009 14:56:33 -0700 (PDT) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id B33753A695C for ; Mon, 20 Apr 2009 14:56:33 -0700 (PDT) Received: from [192.168.1.194] (p508FFA33.dip.t-dialin.net [80.143.250.51]) by mail-n.franken.de (Postfix) with ESMTP id 916A41C0B4627; Mon, 20 Apr 2009 23:57:17 +0200 (CEST) Message-Id: <87BF040D-B9D2-4FFE-9D84-1B311174778E@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Peter Saint-Andre In-Reply-To: <49ECB072.8070908@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Mon, 20 Apr 2009 23:57:16 +0200 References: <49ECA89D.9010404@gnutls.org> <49ECB072.8070908@stpeter.im> X-Mailer: Apple Mail (2.930.4) Cc: Joe Hildebrand , tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 21:56:35 -0000 Dear all, you can use SCTP as a transport protocol and use DTLS/SCTP. This provides you with multiple streams (message order in each stream is preserved) but the head of line blocking between the streams is minimized. Best regards Michael On Apr 20, 2009, at 7:27 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/20/09 10:53 AM, Nikos Mavrogiannopoulos wrote: >> Badra wrote: >>> Hi all, >>> >>> We have posted a document that describes "multi-threaded >>> application" >>> multiplexing over a single TLS session. >> >> Hello, >> Is TLS the appropriate level to do this protocol? Couldn't it be over >> TLS, or over any protocol that is being used at the moment? It >> looks it >> has a broader applicability than just TLS. > > In the XMPP community we are interested in something similar: the > ability to multiplex multiple domain-to-domain streams over a single > encrypted connection. Joe Hildebrand and I plan to write up at least a > requirements I-D about that soon. It's not yet clear to me if our use > case is in scope for draft-badra-tls-multiplexing. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknssHIACgkQNL8k5A2w/vxkKACgjym7ECIL4ntl/45SBbRQEo05 > 1+EAn2IsB/kkkYd/bEmL5gDqwku6VTck > =f4Xx > -----END PGP SIGNATURE----- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ekr@networkresonance.com Mon Apr 20 15:02:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C8D3A695C for ; Mon, 20 Apr 2009 15:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qblQEaQ3rf+P for ; Mon, 20 Apr 2009 15:02:25 -0700 (PDT) Received: from kilo.networkresonance.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 93F063A6DA2 for ; Mon, 20 Apr 2009 15:02:25 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 19412185FDD; Mon, 20 Apr 2009 15:05:50 -0700 (PDT) Date: Mon, 20 Apr 2009 15:05:50 -0700 From: Eric Rescorla To: Badra In-Reply-To: References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090420220550.19412185FDD@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 22:02:26 -0000 At Mon, 20 Apr 2009 22:23:16 +0200, Badra wrote: > > [1 ] > On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla wrote: > > > > > Has anyone from the Web community expressed interest in this feature? > > > > > Eric, honestly I don't see why all these questions. Uh, because I'm trying to figure out whether this is something worth doing and the high order question for that determination is whether anyone wants it? -Ekr From mbadra@gmail.com Mon Apr 20 15:17:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00053A6B7B for ; Mon, 20 Apr 2009 15:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkmW58do60j9 for ; Mon, 20 Apr 2009 15:17:22 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id EA1A83A6AF1 for ; Mon, 20 Apr 2009 15:17:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so251599fge.18 for ; Mon, 20 Apr 2009 15:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=FuJo4Um+T/G7KgnC9k0Ipc6OIhMrfBaWFgMKqhE4ui0=; b=Vsdln90WSeF1RMrmTS1EakwzHWKgZy7zoQViG6l/fO3aM9SMg8/32BJiEMtGgJ0kd9 /pMkY34As8RbffEBwQkM0puEeCzlQ5ugrnlzrkfT+ftrnnpYhBZC5KEnOX23/w+LPyGW 6JJdVA8u5vQrciHu0XlEmR4WSNLM8MSPqN1qw= 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; b=nZqXn4yNrmb2UlKsvcLwzSGekeZBlMmj75dHtW+AnXoqeAfG3FqwNIbl/1V57GWoRq 3o3X8D6xBYxWEYm+6Tz4jja+uzCNOH8Bd6DzaHLPmr5yWMOiuDjXnK4LylwZMJ3WbA5r +4Gh1IaBmTmKtaXx8gxfMXv7BnDLsZXanu1JM= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.82.6 with SMTP id f6mr4164065fgb.69.1240265917250; Mon, 20 Apr 2009 15:18:37 -0700 (PDT) In-Reply-To: <20090420220550.19412185FDD@kilo.networkresonance.com> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> <20090420220550.19412185FDD@kilo.networkresonance.com> Date: Tue, 21 Apr 2009 00:18:37 +0200 X-Google-Sender-Auth: 05203b897b2a4803 Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=000e0cd298446cbcd7046803e98d Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 22:17:23 -0000 --000e0cd298446cbcd7046803e98d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Apr 21, 2009 at 12:05 AM, Eric Rescorla wrote: > At Mon, 20 Apr 2009 22:23:16 +0200, > Badra wrote: > > > > [1 ] > > On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla >wrote: > > > > > > > > Has anyone from the Web community expressed interest in this feature? > > > > > > > > > Eric, honestly I don't see why all these questions. > > Uh, because I'm trying to figure out whether this is something > worth doing and the high order question for that determination > is whether anyone wants it? > > -Ekr > > > > No problem. Best regards, Badra --000e0cd298446cbcd7046803e98d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 21, 2009 at 12:05 AM, Eric Rescorla = <ekr@netwo= rkresonance.com> wrote:
At Mon, 20 Apr 2009 22:23:16 +02= 00,
Badra wrote:
>
> [1 =A0<text/plain; ISO-8859-1 (7bit)= >]
> On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla <<= a href=3D"mailto:ekr@networkresonance.com">ekr@networkresonance.com>= wrote:
>
> >
> > Has anyone from the Web community = expressed interest in this feature?
> >
>
>
> Eric, honestly I don't see why all th= ese questions.

Uh, because I'm trying to figure out whethe= r this is something
worth doing and the high order question for that det= ermination
is whether anyone wants it?

-Ekr



=A0
=A0
No problem.
Best regards,
Badra
--000e0cd298446cbcd7046803e98d-- From Michael.G.Williams@nokia.com Mon Apr 20 15:19:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6966F3A6F6F for ; Mon, 20 Apr 2009 15:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDRhMgDoC+WO for ; Mon, 20 Apr 2009 15:19:04 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4AAFB28C180 for ; Mon, 20 Apr 2009 15:19:04 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3KMJncu014884; Tue, 21 Apr 2009 01:20:00 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 01:19:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 01:19:42 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 21 Apr 2009 00:19:42 +0200 From: To: , Date: Tue, 21 Apr 2009 00:19:39 +0200 Thread-Topic: [TLS] Multi-Threaded Applications over TLS Thread-Index: AcnB2J0V309NkjPwTu+v19XiCSREpQALQDJw Message-ID: References: <49ECA89D.9010404@gnutls.org> In-Reply-To: <49ECA89D.9010404@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2009 22:19:42.0210 (UTC) FILETIME=[1A35DE20:01C9C206] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2009 22:19:05 -0000 Nikos, Badra, As an aside, the mobile DTLS also provides multiplexing, but that feature w= as considered a separate topic so will be brought forward later. Mapping threads into sessions might prove applicable for mobi-d as well. Kind Regards, Michael =20 -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext N= ikos Mavrogiannopoulos Sent: 20 April, 2009 09:54 To: Badra Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS Badra wrote: > Hi all, >=20 > We have posted a document that describes "multi-threaded application" > multiplexing over a single TLS session. Hello, Is TLS the appropriate level to do this protocol? Couldn't it be over TLS,= or over any protocol that is being used at the moment? It looks it has a b= roader applicability than just TLS. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From uri@ll.mit.edu Mon Apr 20 17:48:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA143A6B19 for ; Mon, 20 Apr 2009 17:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmy9bL18UV2L for ; Mon, 20 Apr 2009 17:48:06 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9095D3A6AF0 for ; Mon, 20 Apr 2009 17:48:06 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3L0n5m5001551 for ; Mon, 20 Apr 2009 20:49:05 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAxDaqKc; Mon Apr 20 20:48:20 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 20 Apr 2009 20:48:20 -0400 From: "Blumenthal, Uri" To: "tls@ietf.org" Date: Mon, 20 Apr 2009 20:48:17 -0400 Thread-Topic: [TLS] Multi-Threaded Applications over TLS Thread-Index: AcnB2Liv7B6BTuCwSp+hzNsjq+v11AAQiMm8 Message-ID: In-Reply-To: <49ECA89D.9010404@gnutls.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C612901140D5urillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 00:48:10 -0000 --_000_C612901140D5urillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (After reading the whole exchange) I think that Nikos is right - it seems a= useful thing, but it does not belong to TLS protocol. Should be done at th= e higher layer (and if it costs one more round-trip - I'd say it's a fair p= rice for design sanity). On 4/20/09 12:53 , "Nikos Mavrogiannopoulos" wrote: Badra wrote: > Hi all, > > We have posted a document that describes "multi-threaded application" > multiplexing over a single TLS session. Hello, Is TLS the appropriate level to do this protocol? Couldn't it be over TLS, or over any protocol that is being used at the moment? It looks it has a broader applicability than just TLS. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Regards, Uri --_000_C612901140D5urillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Multi-Threaded Applications over TLS (After reading the whole exchange) I think that Nikos is right –= ; it seems a useful thing, but it does not belong to TLS protocol. Should b= e done at the higher layer (and if it costs one more round-trip – I&#= 8217;d say it’s a fair price for design sanity).


On 4/20/09  12:53 , "Nikos Mavrogiannopoulos" <nmav@gnutls.org> wrote:

Badra wrote:
> Hi all,
>
> We have posted a document that describes "multi-threaded applicat= ion"
> multiplexing over a single TLS session.

Hello,
 Is TLS the appropriate level to do this protocol? Couldn't it be over=
TLS, or over any protocol that is being used at the moment? It looks it
has a broader applicability than just TLS.

regards,
Nikos




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

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 07:49:53 -0000 Hi Badra, I see that you also have a patent application related to multiplexing several data streams inside one TLS connection: http://v3.espacenet.com/publicationDetails/biblio?adjacent=3Dtrue&KC=3DA1&d= ate=3D20071121&NR=3D1858224A1&DB=3DEPODOC&locale=3Den_EP&CC=3DEP&FT=3DD Is this related to draft-badra-hajjeh-mtls and/or draft-badra-tls- multiplexing? (That is, should we expect an IPR disclosure soon?) Best regards, Pasi > -----Original Message----- > From: Badra > Sent: 20 April, 2009 15:53 > To: tls@ietf.org > Subject: [TLS] Multi-Threaded Applications over TLS >=20 > Hi all, =A0=20 > > We have posted a document that describes "multi-threaded > application" multiplexing over=A0a single TLS session. > >=A0 Comments are welcome. Best regards, Badra =A0 The Transport Layer >Security (TLS) is the most widely deployed protocol for securing >network traffic. =A0It provides mutual authentication, data >confidentiality and integrity, key generation and distribution, and >security parameters negotiation. =A0However, missing from the protocol >is a way to multiplex single-application multiple-stream applications >that commonly use parallel connections to the same logical and/or >physical server application data. >=20 > This document describes a mechanism to multiplex single-application > multiple-stream over TLS. =A0It extends TLS to multiplex parallel > connections of a given application over a single TLS session, > avoiding additional delay related to the TLS/TCP session/connection > setup. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt From Pasi.Eronen@nokia.com Tue Apr 21 00:56:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8FB3A6A0C for ; Tue, 21 Apr 2009 00:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7pfmUaIG-no for ; Tue, 21 Apr 2009 00:56:06 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C33663A6D1F for ; Tue, 21 Apr 2009 00:55:54 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3L7uYAd000922; Tue, 21 Apr 2009 02:57:12 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 10:57:04 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 10:56:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 10:56:49 +0300 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 21 Apr 2009 09:56:46 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Tue, 21 Apr 2009 09:56:46 +0200 From: To: Date: Tue, 21 Apr 2009 09:56:45 +0200 Thread-Topic: [TLS] Multi-Threaded Applications over TLS Thread-Index: AcnB/GeFP3IAV3xpRiiJCwg4LqlIxAAWeD8g Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F23C8867@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> <20090420210033.GC1500@Sun.COM> In-Reply-To: <20090420210033.GC1500@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2009 07:56:49.0481 (UTC) FILETIME=[B9AC1B90:01C9C256] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 07:56:07 -0000 Nicolas Williams wrote: > I also agree that this should be a separate layer, but negotiation > of it in TLS handshakes is useful as a way to start that layer > sooner rather than having to have an application-layer round-trip to > negotiate its use. BTW, such separate layer already exists: the SSH Connection Protocol in RFC 4254 (although the document has "SSH" in the title, the connection protocol is really quite separate from the rest of the SSH, and you could run it over any reliable transport -- including TLS). Best regards, Pasi From carlyoung@keycomm.co.uk Tue Apr 21 01:33:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F5E3A6BAC for ; Tue, 21 Apr 2009 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDIOHWucPuHS for ; Tue, 21 Apr 2009 01:33:15 -0700 (PDT) Received: from smtp-out-57.livemail.co.uk (smtp-out-60.livemail.co.uk [213.171.216.60]) by core3.amsl.com (Postfix) with ESMTP id 029C43A6A0C for ; Tue, 21 Apr 2009 01:33:14 -0700 (PDT) Received: from localhost (mail213-171-216-231.livemail.co.uk [213.171.216.231]) by smtp-out-57.livemail.co.uk (Postfix) with ESMTP id 2B04D5FB89E for ; Tue, 21 Apr 2009 09:34:30 +0100 (BST) MIME-Version: 1.0 X-Mailer: AtMail PHP 5.4 Message-ID: <64356.1240302870@keycomm.co.uk> To: Content-Type: text/plain; charset="utf-8" X-Origin: 93.96.210.102 X-Atmail-Account: carlyoung@keycomm.co.uk Date: Tue, 21 Apr 2009 09:34:30 +0100 From: carlyoung@keycomm.co.uk Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlyoung@keycomm.co.uk List-Id: "This is the mailing list 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, 21 Apr 2009 08:33:16 -0000 >On Mon 20/04/09 7:02 PM , Nicolas Williams Nicolas.Williams@sun.com sent: >On Mon, Apr 20, 2009 at 07:21:46PM +0200, Badra wrote: >> I agree, the document provides some of the RFC4254 services, but honestl= y I >> am not aware of SSHv2 problems. Any link, help or suggestion to avoid th= ese >> issues are appreciated. >A comparison of your proposal to RFC4254 would be useful: what are you >doing differently from SSHv2 and why. >Here's one link regarding SSHv2 and high performance networking: >http://www.psc.edu/networking/projects/hpn-ssh/ >I'm not sure that there's anything wrong with the actual protocol >though. There's no way to reduce a channel's window other than by not >adjusting it for received data, but I'm not sure that that's a problem. >Of course, I'm not sure anyone is actually trying to mix interactive, >small packet traffic with bulk data transfers in an high performance >networking environment... Peter Gutmann did a reasonable analysis of SSH and TLS performance characte= ristics, showing some issues with SSHv2: http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf From pgut001@cs.auckland.ac.nz Tue Apr 21 02:03:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C003A67DA for ; Tue, 21 Apr 2009 02:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1cyumbKyZJH for ; Tue, 21 Apr 2009 02:03:17 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 916073A6826 for ; Tue, 21 Apr 2009 02:03:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 210D79FDE4; Tue, 21 Apr 2009 21:04:33 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj32+gKFX4Zp; Tue, 21 Apr 2009 21:04:33 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 81ACC9FDDB; Tue, 21 Apr 2009 21:04:30 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2A4AB1DE4001; Tue, 21 Apr 2009 21:04:27 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LwBty-00048q-Vv; Tue, 21 Apr 2009 21:04:27 +1200 From: Peter Gutmann To: badra@isima.fr, Nicolas.Williams@sun.com In-Reply-To: <20090420164002.GI1500@Sun.COM> Message-Id: Sender: pgut001 Date: Tue, 21 Apr 2009 21:04:26 +1200 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 09:03:19 -0000 Nicolas Williams writes: >Seems very similar in scope to SSHv2's multiplexing. Ugh, which should serve as a horrible warning to others, not something to be emulated. See the (now somewhat dated) "Performance Characteristics of Application-level Security Protocols", http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf, specifically section 6.2, "The SSHv2 and SFTP Performance Handbrake", for details. Peter. From pgut001@cs.auckland.ac.nz Tue Apr 21 02:22:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00F73A6967 for ; Tue, 21 Apr 2009 02:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRvpde1qXRmu for ; Tue, 21 Apr 2009 02:22:41 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id EC2503A69B9 for ; Tue, 21 Apr 2009 02:22:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9818C1AFB4; Tue, 21 Apr 2009 21:23:56 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z-5u1AobicD; Tue, 21 Apr 2009 21:23:56 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2975A1AFAE; Tue, 21 Apr 2009 21:23:54 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AB67721E4013; Tue, 21 Apr 2009 21:23:53 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LwCCn-0005G7-IQ; Tue, 21 Apr 2009 21:23:53 +1200 From: Peter Gutmann To: badra@isima.fr, ekr@networkresonance.com In-Reply-To: <20090420194154.E72DC185B38@kilo.networkresonance.com> Message-Id: Sender: pgut001 Date: Tue, 21 Apr 2009 21:23:53 +1200 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 09:22:41 -0000 Eric Rescorla writes: >At Mon, 20 Apr 2009 20:51:06 +0200, >> I think the transport folks could be interested. They have concerns with bad >> congestion control properties of the massive parallel connection practice in >> contemporary web browsers. > >I have a fair amount of skepticism about the relevance of this application: There's a fourth reason: 4. HTTP 1.1 pipelining has been around for nearly a decade, and if browser vendors really cared about this issue all they'd need to do is turn pipelining on (Firefox has it disabled by default, MSIE and Opera AFAIK have it enabled). There was a paper published some years ago (sorry, no idea what the title was any more) which showed that it wasn't necessarily faster over a high-speed connection (some of the earlier experiments were run with dialup and other slow, high-latency connections where setup and teardown were expensive). So, for the case of HTTP use, it seems entirely unnecessary, the mechanism to deal with this is already present in pretty much every browser, and even then there's no sign that browser vendors will actually use it even though it's available. Peter. From mbadra@gmail.com Tue Apr 21 02:33:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02B63A6AD3 for ; Tue, 21 Apr 2009 02:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dJWpF2ry7dx for ; Tue, 21 Apr 2009 02:33:38 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id BFD383A6AA9 for ; Tue, 21 Apr 2009 02:33:37 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so302406fge.18 for ; Tue, 21 Apr 2009 02:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Y2d827Xo3O1O4kOWx8kkj18xeSTDJ52OKnheS+e2yLw=; b=T7CuWfdm2RyIBg7CbAf2l7xz2mNIDEi1d9qKZOOCPCzWm75tOc2dV9kbKOalLdwOt1 0P4gq2sdWSP/kVk66E8LgVUge40zGL8TnScPR9XBCCh1di/4SpVGAHtgOYyq278GTLks HzLYE2MxR7GHSbfqF6i+bC/7R9CWYNncvTCDI= 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; b=szWXxNJdIX4Ct+VS9q9mRo0d0T6+ztzy5Cvd0OGs1cZyoO/vF4S6mHWAgNmx7RmQDa 0MVziG3KAS/bUBVDFDw/QyLATMc4oH9rUQkxQ5O0WD+sOhL6r6w+rZcPyJz+/S260f0w SK+/2FtUorlFB5C1Yj8mzd6KdnyIAeVyv29mA= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.79.12 with SMTP id c12mr4424326fgb.64.1240306493476; Tue, 21 Apr 2009 02:34:53 -0700 (PDT) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F23C884B@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F23C884B@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 21 Apr 2009 11:34:53 +0200 X-Google-Sender-Auth: 2eeb56dc9fbd1c82 Message-ID: From: Badra To: Pasi.Eronen@nokia.com Content-Type: multipart/alternative; boundary=000e0cd2978cf4d27b04680d5b97 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 09:33:38 -0000 --000e0cd2978cf4d27b04680d5b97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Apr 21, 2009 at 9:50 AM, wrote: > Hi Badra, > > I see that you also have a patent application related to multiplexing > several data streams inside one TLS connection: > > > http://v3.espacenet.com/publicationDetails/biblio?adjacent=true&KC=A1&date=20071121&NR=1858224A1&DB=EPODOC&locale=en_EP&CC=EP&FT=D > > Is this related to draft-badra-hajjeh-mtls and/or draft-badra-tls- > multiplexing? (That is, should we expect an IPR disclosure soon?) > Hi Pasi, I submitted the IPR disclosure. Best regards, Badra --000e0cd2978cf4d27b04680d5b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 21, 2009 at 9:50 AM, <Pasi.Eronen@nokia.com> wrote:
Hi Badra,

I see that you = also have a patent application related to multiplexing
several data stre= ams inside one TLS connection:

http://v3.espa= cenet.com/publicationDetails/biblio?adjacent=3Dtrue&KC=3DA1&date=3D= 20071121&NR=3D1858224A1&DB=3DEPODOC&locale=3Den_EP&CC=3DEP&= amp;FT=3DD

Is this related to draft-badra-hajjeh-mtls and/or draft-badra-tls-
m= ultiplexing? (That is, should we expect an IPR disclosure soon?)
=A0
=A0
Hi Pasi,
=A0
I submitted the IPR disclosure.
Best re= gards,
Badra
--000e0cd2978cf4d27b04680d5b97-- From mbadra@gmail.com Tue Apr 21 06:32:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6AB3A697E for ; Tue, 21 Apr 2009 06:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWYdxQAC-SIM for ; Tue, 21 Apr 2009 06:32:26 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 02B5F28C22A for ; Tue, 21 Apr 2009 06:32:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so335615fge.18 for ; Tue, 21 Apr 2009 06:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=h3Nur/JB6VlfqFqueV3WtkDdhQjTjKaFZNgE7y0s98s=; b=dcF9WdSBjR6PKu1P+gsNFBG+AJdraHia9IQoWbo2XCs2+fvlmkw92Z77jKYsFhXpYF N4yGEFiK6XumnEZN/koqKOFdWrkXBlt0BPe3b/pHP1NjH9woCEkkrUOT3JoRbgIMNLZs YJ8LusBx0YDnQw0Wf8haEHClkLDxg90sq1meU= 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; b=EW1d55THtDjQZpuChWnudLtIpL2lsMMk+KYW/WnE2VjIfUtYf+cm3af4OTbxx9fhKW VAi5rzeUjNfpDx5EgtXNZ2QaBGqHrBBUvmEeMB4UkRoKDBh4SZ2FVB0ngCyzJ41D1N6F +prwf1WkzS1kqMkcu/j5o8pYc8q11rTTjlJQY= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.33.10 with SMTP id g10mr379754fgg.21.1240320816660; Tue, 21 Apr 2009 06:33:36 -0700 (PDT) In-Reply-To: References: <49ECA89D.9010404@gnutls.org> Date: Tue, 21 Apr 2009 15:33:36 +0200 X-Google-Sender-Auth: f4470bf2607fbd4a Message-ID: From: Badra To: "Blumenthal, Uri" Content-Type: multipart/alternative; boundary=000e0cd24746af451e046810b1db Cc: "tls@ietf.org" Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 13:32:26 -0000 --000e0cd24746af451e046810b1db Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 21, 2009 at 2:48 AM, Blumenthal, Uri wrote: > (After reading the whole exchange) I think that Nikos is right =96 it see= ms a > useful thing, but it does not belong to TLS protocol. Should be done at t= he > higher layer (and if it costs one more round-trip =96 I=92d say it=92s a = fair > price for design sanity). > > Nicolas Williams: > >> I also agree that this should be a separate layer, but negotiation of i= t >> in TLS handshakes is useful as a way to start that layer sooner rather >> than having to have an application-layer round-trip to negotiate its >> use. >> > Well, the first option is defined in the document, whereas the second is described through draft-badra-hajjeh-mtls-05. Best regards, BHadra --000e0cd24746af451e046810b1db Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 21, 2009 at 2:48 AM, Blumenthal, Uri= <uri@ll.mit.edu= > wrote:
(After reading the whole exchange) I think that Nikos is right = =96 it seems a useful thing, but it does not belong to TLS protocol. Should= be done at the higher layer (and if it costs one more round-trip =96 I=92d= say it=92s a fair price for design sanity).
=A0
Nicolas Williams:
I also agree that this should be a separate layer, but negotiation of = it
in TLS handshakes is useful as a way to start that layer sooner rathe= r
than having to have an application-layer round-trip to negotiate its use.
=A0
=A0
Well, the first option is defined in the document, whereas the second = is described through draft-badra-hajjeh-mtls-05.

Best regards,
BHadra
--000e0cd24746af451e046810b1db-- From mbadra@gmail.com Tue Apr 21 06:39:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB71F28C282 for ; Tue, 21 Apr 2009 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR7eWr95c9yU for ; Tue, 21 Apr 2009 06:39:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id BEBDC28C264 for ; Tue, 21 Apr 2009 06:39:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so354616fgb.18 for ; Tue, 21 Apr 2009 06:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=BU/nSXcs/aNC9PD+8LIILknOtOQls1b4aOteNJ6Ci7o=; b=Yg3x8CnSerhLyPfaa9FKHphoAuj8aHlA8/8/3gJQIZNdm7KW53jGa/6q/VFjZJ0nzH KdrUFq9oRu8ANiUejGRpFoxmB4tP5mivko3kHUuws9dGh5b9SbKZGDgofLIdKwVsMTIc kR4Yo4SQs+URCU2q+8jOJ9FVUpiWkERl295DA= 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; b=PuV0sjHRqqBobROVPGSDKKo4iiDQ8sZ3zPNFko/bn1RxIg1ItxnKl58ooHcxZNOJva Q0U5qfzXshOG2LW04oed1oos0lWLtGmZjaFI4EKhU5TXjUfEXkYVx2KvJNsrAC8XvBEy beT2pADV9lGVhdO9vMKf7B+sAfHX3w50iO+Ic= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.94.11 with SMTP id r11mr4629332fgb.11.1240321231687; Tue, 21 Apr 2009 06:40:31 -0700 (PDT) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F23C8867@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> <20090420210033.GC1500@Sun.COM> <808FD6E27AD4884E94820BC333B2DB7727F23C8867@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 21 Apr 2009 15:40:31 +0200 X-Google-Sender-Auth: 679b0473d3bf89cc Message-ID: From: Badra To: Pasi.Eronen@nokia.com Content-Type: multipart/alternative; boundary=000e0cd286906c0fbe046810ca28 Cc: tls@ietf.org, Nicolas.Williams@sun.com Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 13:39:17 -0000 --000e0cd286906c0fbe046810ca28 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Apr 21, 2009 at 9:56 AM, wrote: > Nicolas Williams wrote: > > > I also agree that this should be a separate layer, but negotiation > > of it in TLS handshakes is useful as a way to start that layer > > sooner rather than having to have an application-layer round-trip to > > negotiate its use. > > BTW, such separate layer already exists: the SSH Connection Protocol > in RFC 4254 (although the document has "SSH" in the title, the > connection protocol is really quite separate from the rest of the SSH, > and you could run it over any reliable transport -- including TLS). RFC 4254: - cannot operate over unreliable transport such as UDP. - couldn't be used as it is, you should assign a TCP port to run it over TLS. Best regards, Badra --000e0cd286906c0fbe046810ca28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 21, 2009 at 9:56 AM, <Pasi.Eronen@nokia.com&g= t; wrote:
Nicolas Williams wrote:

> I also agree that thi= s should be a separate layer, but negotiation
> of it in TLS handshak= es is useful as a way to start that layer
> sooner rather than having= to have an application-layer round-trip to
> negotiate its use.

BTW, such separate layer already exist= s: the SSH Connection Protocol
in RFC 4254 (although the document has &q= uot;SSH" in the title, the
connection protocol is really quite sepa= rate from the rest of the SSH,
and you could run it over any reliable transport -- including TLS).
=A0
=A0
RFC 4254:
-=A0 cannot operate over unreliable transport such as UDP.
-=A0 couldn't be used as it is, you should assign a TCP port to ru= n it over TLS.=A0
=A0
Best regards,
Badra
--000e0cd286906c0fbe046810ca28-- From dean@av8.com Tue Apr 21 07:12:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57EF33A6A24 for ; Tue, 21 Apr 2009 07:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DfA9BbpFSS0 for ; Tue, 21 Apr 2009 07:12:42 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 362B23A67DB for ; Tue, 21 Apr 2009 07:12:42 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n3LEDuvh025896 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 21 Apr 2009 10:13:57 -0400 Date: Tue, 21 Apr 2009 10:13:56 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Badra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 14:12:43 -0000 What is the IPR disclosure number. Searching doesn't produce anything. Search result on draft-badra-tls-multiplexing, "Multiplexing Single-Application Multiple-Connection over TLS" No IPR disclosures related to draft-badra-tls-multiplexing have been submitted Thanks, --Dean On Tue, 21 Apr 2009, Badra wrote: > On Tue, Apr 21, 2009 at 9:50 AM, wrote: > > > Hi Badra, > > > > I see that you also have a patent application related to multiplexing > > several data streams inside one TLS connection: > > > > > > http://v3.espacenet.com/publicationDetails/biblio?adjacent=true&KC=A1&date=20071121&NR=1858224A1&DB=EPODOC&locale=en_EP&CC=EP&FT=D > > > > Is this related to draft-badra-hajjeh-mtls and/or draft-badra-tls- > > multiplexing? (That is, should we expect an IPR disclosure soon?) > > > > > Hi Pasi, > > I submitted the IPR disclosure. > Best regards, > Badra > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From carlyoung@keycomm.co.uk Tue Apr 21 08:31:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF0A3A67E1 for ; Tue, 21 Apr 2009 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.062 X-Spam-Level: ** X-Spam-Status: No, score=2.062 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHuA4X3klDHv for ; Tue, 21 Apr 2009 08:31:44 -0700 (PDT) Received: from mail.o2.co.uk (sidious.london.02.net [82.132.130.152]) by core3.amsl.com (Postfix) with ESMTP id 6AB183A6980 for ; Tue, 21 Apr 2009 08:31:43 -0700 (PDT) Received: from YOUCA04DEATH (93.96.210.102) by mail.o2.co.uk (8.0.013.3) (authenticated as cyoung651@o2.co.uk) id 49ECA07E00435153 for tls@ietf.org; Tue, 21 Apr 2009 16:32:58 +0100 Message-ID: From: "Carl Young" To: "TLS" Date: Tue, 21 Apr 2009 16:32:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 15:31:45 -0000 Hi, Can anyone point me to any documentation or information detailing the relevant strengths of cipher suites within TLS 1.x. I was wondering as the NIST publishes relevant key strengths - where a 1024 bit RSA key is assumed to provide an equivalence of 80 bits of security [SP800-57, part 1]; 3TDEA is 112 bits. So, for TLS_RSA_WITH_3DES_EDE_CBC_SHA, assuming an RSA 1024 bit key-pair, would the effective strength of the connection be 80 bits or am I looking to compare apples and oranges? If I want to negotiate AES-256, should I really be using a 15360 bit RSA key or, again, am I looking at this in the wrong way? Thanks for any guidance. Regards, Carl From mbadra@gmail.com Tue Apr 21 08:34:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02053A6A20 for ; Tue, 21 Apr 2009 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWBnsd9Fa1rt for ; Tue, 21 Apr 2009 08:34:38 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 8EAA33A69F1 for ; Tue, 21 Apr 2009 08:34:37 -0700 (PDT) Received: by fxm2 with SMTP id 2so2589694fxm.37 for ; Tue, 21 Apr 2009 08:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=M9QBLHJiVhllQWUb9Lz9N3hxYPi1KdIU/SbHShAQJec=; b=wji2vr2Mf+esqKhbIF0wgdAqfGjLL/1tRg1iuJPsfpyUwIUwwnMVd7iufdD2Mcp2sh j7oq5GhHW+sQHPlnuSQ4ST8RO+Of9JHnTBnLxtrkWk8j606BCHw2K/p8w9friY/O/CC6 KqLVzZJuAgOwBxMpT1HJHiyxGlahnsnHZU5DE= 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; b=XFXq9L47eEJhE7jLx1+GXPrrObxNi9EaWyfRm4Z033qysPva5W8QIdjCZ1En2kN5V2 gZRG24e/XW0FvEtxnHLEqJxEm3rKrzYWB7Wa3EZxNLK1BYYLOE0MxdtItGf+lNPz3/ZF jRZizIM6gIx7PJdKsRWkNH3GzWXAx1J+7oJdI= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.204.121.131 with SMTP id h3mr6620451bkr.66.1240328153134; Tue, 21 Apr 2009 08:35:53 -0700 (PDT) In-Reply-To: References: <49ECA89D.9010404@gnutls.org> Date: Tue, 21 Apr 2009 17:35:53 +0200 X-Google-Sender-Auth: 0bc6d4f55cd72288 Message-ID: From: Badra To: Michael.G.Williams@nokia.com Content-Type: multipart/alternative; boundary=001636c5a4aff8f5e104681266ad Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 15:34:38 -0000 --001636c5a4aff8f5e104681266ad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Michael, > As an aside, the mobile DTLS also provides multiplexing, but that feature > was considered a separate topic so will be brought forward later. > I can't see how mobi-d can multiplex applications' channels. > Mapping threads into sessions might prove applicable for mobi-d as well. > Well, but I don't need mobi-d to do so. Best regards, Badra --001636c5a4aff8f5e104681266ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

=A0
As an aside, the mobile DTLS als= o provides multiplexing, but that feature was considered a separate topic s= o will be brought forward later.
=A0
=A0
I can't see how mobi-d can multiplex applications' channels.
=A0
=A0
Mapping threads into sessions mi= ght prove applicable for mobi-d as well.
=A0
=A0
Well, but I don't need mobi-d to do so.
=A0
Best regards,
Badra
--001636c5a4aff8f5e104681266ad-- From mbadra@gmail.com Tue Apr 21 08:35:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64383A683D for ; Tue, 21 Apr 2009 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FvVbq5jQpAs for ; Tue, 21 Apr 2009 08:35:24 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 84D2E3A6C07 for ; Tue, 21 Apr 2009 08:35:23 -0700 (PDT) Received: by fxm2 with SMTP id 2so2590082fxm.37 for ; Tue, 21 Apr 2009 08:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=iPkMe9Lmnsn9ME/wKUE/8QJvx/HDH3ONz/rXstL29Tc=; b=N1iBjJdZzvAaSGOaqtzahA7PvdwnTx8f6AIzbBXum+/cIgQ/uJT4YYihddfdWVWszO ouLblq3XBEO5fJumI0VPzaqX/zbcy+V9Ki3/OVTICLACxOwA8Qh0RvJh+1F4HFwmn1W4 bTeuwMrpP+6DNAHtv7Atgp+owjO7Y3LoHXPUk= 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; b=tE+f8JIgWWNXBCqMzQxo5PG2uhfoqcuZIofye7FjU5LAtCsfnldS84Uf+opIlcXX67 8C4jiC7vW6Qc/0H961fRGWnrliuTUoRU6rC9On2+IqauTdzdaLtQV1Y3y6Z/QrR/BpgW z8Oav0rLb2dvsPVbn4Vo/9yvjrbUEVEoCGYt0= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.204.31.75 with SMTP id x11mr6636850bkc.0.1240328199034; Tue, 21 Apr 2009 08:36:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Apr 2009 17:36:38 +0200 X-Google-Sender-Auth: 67cbcf39675da9b7 Message-ID: From: Badra To: Dean Anderson Content-Type: multipart/alternative; boundary=001485f7786cb5583504681269e9 Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 15:35:25 -0000 --001485f7786cb5583504681269e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dean, It take one business day (I submitted it this morning) Best regards Badra On Tue, Apr 21, 2009 at 4:13 PM, Dean Anderson wrote: > What is the IPR disclosure number. Searching doesn't produce anything. > > Search result on draft-badra-tls-multiplexing, "Multiplexing > Single-Application Multiple-Connection over TLS" > No IPR disclosures related to draft-badra-tls-multiplexing have > been submitted > > Thanks, > > --Dean > > > > On Tue, 21 Apr 2009, Badra wrote: > > > On Tue, Apr 21, 2009 at 9:50 AM, wrote: > > > > > Hi Badra, > > > > > > I see that you also have a patent application related to multiplexing > > > several data streams inside one TLS connection: > > > > > > > > > > http://v3.espacenet.com/publicationDetails/biblio?adjacent=true&KC=A1&date=20071121&NR=1858224A1&DB=EPODOC&locale=en_EP&CC=EP&FT=D > > > > > > Is this related to draft-badra-hajjeh-mtls and/or draft-badra-tls- > > > multiplexing? (That is, should we expect an IPR disclosure soon?) > > > > > > > > > Hi Pasi, > > > > I submitted the IPR disclosure. > > Best regards, > > Badra > > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > --001485f7786cb5583504681269e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dean,
=A0
It take one business day (I submitted it this morning)
Best regards
Badra

On Tue, Apr 21, 2009 at 4:13 PM, Dean Anderson <= span dir=3D"ltr"><dean@av8.com> wrote:
What is the IPR disclosure numbe= r. Searching doesn't produce anything.

Search result on draft-ba= dra-tls-multiplexing, "Multiplexing
Single-Application Multiple-Connection over TLS"
=A0 =A0 =A0 =A0No = IPR disclosures related to draft-badra-tls-multiplexing have
been submit= ted

Thanks,

=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0--Dean



On Tue, 21 Apr 2009, Badra wrote:

>= On Tue, Apr 21, 2009 at 9:50 AM, <Pasi.Eronen@nokia.com> wrote:
>
> > Hi Badra,
> >
> > I see that you also have a patent application relate= d to multiplexing
> > several data streams inside one TLS connecti= on:
> >
> >
> > http://v3.espacenet.com/publicationDetails/biblio?a= djacent=3Dtrue&KC=3DA1&date=3D20071121&NR=3D1858224A1&DB=3D= EPODOC&locale=3Den_EP&CC=3DEP&FT=3DD
> >
> > Is this related to draft-badra-hajjeh-mtls and/or dr= aft-badra-tls-
> > multiplexing? (That is, should we expect an IPR= disclosure soon?)
> >
>
>
> Hi Pasi,
> > I submitted the IPR disclosure.
> Best regards,
> Badra>

--
Av8 Internet =A0 Prepared to pay a premium for bett= er service?
www.av8.ne= t =A0 =A0 =A0 =A0 faster, more reliable, better service
617 344 9000=



--001485f7786cb5583504681269e9-- From ekr@networkresonance.com Tue Apr 21 08:51:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AEDE3A69FC for ; Tue, 21 Apr 2009 08:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmxJHvqVUNDe for ; Tue, 21 Apr 2009 08:51:33 -0700 (PDT) Received: from kilo.networkresonance.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D78943A681C for ; Tue, 21 Apr 2009 08:51:32 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 96F07187141; Tue, 21 Apr 2009 08:55:01 -0700 (PDT) Date: Tue, 21 Apr 2009 08:55:01 -0700 From: Eric Rescorla To: "Carl Young" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090421155501.96F07187141@kilo.networkresonance.com> Cc: TLS Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 15:51:34 -0000 At Tue, 21 Apr 2009 16:32:54 +0100, Carl Young wrote: > > Hi, > > Can anyone point me to any documentation or information detailing the > relevant strengths of cipher suites within TLS 1.x. I was wondering as the > NIST publishes relevant key strengths - where a 1024 bit RSA key is assumed > to provide an equivalence of 80 bits of security [SP800-57, part 1]; 3TDEA > is 112 bits. > > So, for TLS_RSA_WITH_3DES_EDE_CBC_SHA, assuming an RSA 1024 bit key-pair, > would the effective strength of the connection be 80 bits or am I looking to > compare apples and oranges? > > If I want to negotiate AES-256, should I really be using a 15360 bit RSA key > or, again, am I looking at this in the wrong way? Well, I think that this last bit is certainly looking at it the wrong way. We don't know of any conditions under which AES-256 would be breakable and AES-128 would not be, so talking about "key strength" just doesn't make much sense at that level. -Ekr From Nicolas.Williams@sun.com Tue Apr 21 08:58:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768733A6C45 for ; Tue, 21 Apr 2009 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH8sA6p5lw3r for ; Tue, 21 Apr 2009 08:58:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 102C33A6B01 for ; Tue, 21 Apr 2009 08:58:28 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LFxiVP027639 for ; Tue, 21 Apr 2009 15:59:44 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3LFxiM4016359 for ; Tue, 21 Apr 2009 09:59:44 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LFoBk4015099; Tue, 21 Apr 2009 10:50:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LFoBQR015098; Tue, 21 Apr 2009 10:50:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Apr 2009 10:50:11 -0500 From: Nicolas Williams To: Badra Message-ID: <20090421155010.GF1500@Sun.COM> References: <20090420183341.81FB6185AE0@kilo.networkresonance.com> <20090420194154.E72DC185B38@kilo.networkresonance.com> <20090420210033.GC1500@Sun.COM> <808FD6E27AD4884E94820BC333B2DB7727F23C8867@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 15:58:29 -0000 On Tue, Apr 21, 2009 at 03:40:31PM +0200, Badra wrote: > On Tue, Apr 21, 2009 at 9:56 AM, wrote: > > BTW, such separate layer already exists: the SSH Connection Protocol > > in RFC 4254 (although the document has "SSH" in the title, the > > connection protocol is really quite separate from the rest of the SSH, > > and you could run it over any reliable transport -- including TLS). > > RFC 4254: > - cannot operate over unreliable transport such as UDP. First let's establish that we need that. SCTP comes to mind (and has been mentioned already). > - couldn't be used as it is, you should assign a TCP port to run it over > TLS. Negotiation is a problem no matter what. With TLS you happen to get a place to do the negotiation early on (i.e., in the handshakes). But as has been pointed out, the one example you gave of a protocol that could use this (HTTP) often runs without TLS, in which case you're back to having to specify how this layer gets negotiated. Nico -- From carlyoung@keycomm.co.uk Tue Apr 21 09:01:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58913A7021 for ; Tue, 21 Apr 2009 09:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAMrqzJzroY8 for ; Tue, 21 Apr 2009 09:01:50 -0700 (PDT) Received: from smtp-out-58.livemail.co.uk (smtp-out-68.livemail.co.uk [213.171.216.68]) by core3.amsl.com (Postfix) with ESMTP id EB08A3A6B8E for ; Tue, 21 Apr 2009 09:01:46 -0700 (PDT) Received: from localhost (mail213-171-216-231.livemail.co.uk [213.171.216.231]) by smtp-out-58.livemail.co.uk (Postfix) with ESMTP id 2364C410094 for ; Tue, 21 Apr 2009 17:03:02 +0100 (BST) MIME-Version: 1.0 X-Mailer: AtMail PHP 5.4 Message-ID: <50078.1240329782@keycomm.co.uk> To: "TLS" Content-Type: text/plain; charset="utf-8" X-Origin: 93.96.210.102 X-Atmail-Account: carlyoung@keycomm.co.uk Date: Tue, 21 Apr 2009 17:03:02 +0100 From: carlyoung@keycomm.co.uk Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlyoung@keycomm.co.uk List-Id: "This is the mailing list 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, 21 Apr 2009 16:01:50 -0000 >On Tue 21/04/09 4:55 PM , Eric Rescorla ekr@networkresonance.com sent: >>At Tue, 21 Apr 2009 16:32:54 +0100, Carl Young wrote: >>=20 >> So, for TLS_RSA_WITH_3DES_EDE_CBC_SHA, assuming an RSA 1024 bit key-pair= ,=20 >> would the effective strength of the connection be 80 bits or am I lookin= g to=20 >> compare apples and oranges? >> >> If I want to negotiate AES-256, should I really be using a 15360 bit RSA= key=20 >> or, again, am I looking at this in the wrong way? > >Well, I think that this last bit is certainly looking at it the wrong >way. We don't know of any conditions under which AES-256 would be >breakable and AES-128 would not be, so talking about "key strength" >just doesn't make much sense at that level. The "key strength" would be limited by the weakest link in the suite though= wouldn't it, which, in this case, is the RSA keys? Or are you saying that = the additional security of the PRF, key derivation mechanisms, and the entr= opy in the random data overcomes this? I suppose what I'm trying to establish is that [hypothetically] if the tech= nology existed to brute-force attack a 1024 bit RSA key pair in a short tim= e-frame (say 1-2 days), would the attacker be able to recover the AES-256 k= eys used in the TLS session and decode the complete session, or is it more = involved in that? Thanks, Carl From Nicolas.Williams@sun.com Tue Apr 21 09:07:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39EF3A6BFC for ; Tue, 21 Apr 2009 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.873 X-Spam-Level: X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHb+p5J7tNXX for ; Tue, 21 Apr 2009 09:07:56 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id F3C6B3A6A67 for ; Tue, 21 Apr 2009 09:07:55 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LG9CEP003855 for ; Tue, 21 Apr 2009 16:09:12 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3LG9CWs025622 for ; Tue, 21 Apr 2009 10:09:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LFxiMf015160; Tue, 21 Apr 2009 10:59:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LFxhCm015159; Tue, 21 Apr 2009 10:59:43 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Apr 2009 10:59:43 -0500 From: Nicolas Williams To: "Blumenthal, Uri" Message-ID: <20090421155943.GH1500@Sun.COM> References: <49ECA89D.9010404@gnutls.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 16:07:56 -0000 On Mon, Apr 20, 2009 at 08:48:17PM -0400, Blumenthal, Uri wrote: > (After reading the whole exchange) I think that Nikos is right - it > seems a useful thing, but it does not belong to TLS protocol. Should > be done at the higher layer (and if it costs one more round-trip - I'd > say it's a fair price for design sanity). Uri, I agree, but I don't see why it should cost one more round-trip. Piggybacking application-layer negotiations on client Hello/handshake messages seems to me like quite a reasonable thing to do. Nico -- From Nicolas.Williams@sun.com Tue Apr 21 09:13:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635173A6933 for ; Tue, 21 Apr 2009 09:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.873 X-Spam-Level: X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO8CxeLwaPyb for ; Tue, 21 Apr 2009 09:13:48 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D3E863A6A0D for ; Tue, 21 Apr 2009 09:13:47 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LGF4dR006930 for ; Tue, 21 Apr 2009 16:15:04 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3LGF47M030868 for ; Tue, 21 Apr 2009 10:15:04 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LFw5K1015153; Tue, 21 Apr 2009 10:58:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LFw03h015152; Tue, 21 Apr 2009 10:58:00 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Apr 2009 10:58:00 -0500 From: Nicolas Williams To: Peter Gutmann Message-ID: <20090421155800.GG1500@Sun.COM> References: <20090420164002.GI1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: [TLS] SSH channel handbrake (Re: Multi-Threaded Applications over TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 16:13:49 -0000 On Tue, Apr 21, 2009 at 09:04:26PM +1200, Peter Gutmann wrote: > Nicolas Williams writes: > > >Seems very similar in scope to SSHv2's multiplexing. > > Ugh, which should serve as a horrible warning to others, not something to be > emulated. See the (now somewhat dated) "Performance Characteristics of > Application-level Security Protocols", > http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf, specifically section > 6.2, "The SSHv2 and SFTP Performance Handbrake", for details. I don't believe that handbrake exists other than as an implementation artifact. It's perfectly reasonable to have large channel windows, and even to grow the channel windows so as to avoid having to ever wait for an ACK. The key is to grow the channel window to a point where the sender never waits for an ACK before sending the next packet. The problem is that the receiver doesn't know if the sender is ever waiting -- except by heuristics involving a) detecting bulk (multiple max sized packets), and b) timing of incoming packets before and after growing the window to see if growing the window helps bandwidth, all of which is a pain. We could probably fix this by having a channel request by which the sender can advise the receiver that the sender is often waiting for window adjustments (ACKs). The HPN OpenSSH patches don't make the window that dynamic, IIRC, but they do make it dynamic and get better performance, thus proving the point. From uri@ll.mit.edu Tue Apr 21 09:26:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3E93A6DF8 for ; Tue, 21 Apr 2009 09:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcGaMt1LSoRe for ; Tue, 21 Apr 2009 09:26:08 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 6B47F3A703E for ; Tue, 21 Apr 2009 09:25:56 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3LGR9ap028934 for ; Tue, 21 Apr 2009 12:27:09 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAkIaqoO; Tue Apr 21 12:19:26 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Tue, 21 Apr 2009 12:19:26 -0400 From: "Blumenthal, Uri" CC: "'tls@ietf.org'" Date: Tue, 21 Apr 2009 12:19:26 -0400 Thread-Topic: [TLS] Multi-Threaded Applications over TLS Thread-Index: AcnCnKa+ahIbW+vDSIOXD8LZ3gorUgAAEnM2 Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F312@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 16:26:09 -0000 V2VsbCBpdCBkb2Vzbid0IEhBVkUgdG8gY29zdCBhbiBleHRyYSByb3VuZC10cmlwLCBidXQgSSBz YWlkIHRoYXQgRVZFTiBpZiBpdCBkaWQgaXQgd291bGQgYmUgYWNjZXB0YWJsZS4gSWYgaXQgZG9l c24ndCBjb3N0IHRoYXQgLSBzbyBtdWNoIHRoZSBiZXR0ZXIhDQoNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KRnJvbTogTmljb2xhcyBXaWxsaWFtcyA8Tmljb2xhcy5XaWxsaWFtc0Bz dW4uY29tPg0KVG86IEJsdW1lbnRoYWwsIFVyaQ0KQ2M6IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYu b3JnPg0KU2VudDogVHVlIEFwciAyMSAxMTo1OTo0MyAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBN dWx0aS1UaHJlYWRlZCBBcHBsaWNhdGlvbnMgb3ZlciBUTFMNCg0KT24gTW9uLCBBcHIgMjAsIDIw MDkgYXQgMDg6NDg6MTdQTSAtMDQwMCwgQmx1bWVudGhhbCwgVXJpIHdyb3RlOg0KPiAoQWZ0ZXIg cmVhZGluZyB0aGUgd2hvbGUgZXhjaGFuZ2UpIEkgdGhpbmsgdGhhdCBOaWtvcyBpcyByaWdodCAt IGl0DQo+IHNlZW1zIGEgdXNlZnVsIHRoaW5nLCBidXQgaXQgZG9lcyBub3QgYmVsb25nIHRvIFRM UyBwcm90b2NvbC4gU2hvdWxkDQo+IGJlIGRvbmUgYXQgdGhlIGhpZ2hlciBsYXllciAoYW5kIGlm IGl0IGNvc3RzIG9uZSBtb3JlIHJvdW5kLXRyaXAgLSBJJ2QNCj4gc2F5IGl0J3MgYSBmYWlyIHBy aWNlIGZvciBkZXNpZ24gc2FuaXR5KS4NCg0KVXJpLA0KDQpJIGFncmVlLCBidXQgSSBkb24ndCBz ZWUgd2h5IGl0IHNob3VsZCBjb3N0IG9uZSBtb3JlIHJvdW5kLXRyaXAuDQpQaWdneWJhY2tpbmcg YXBwbGljYXRpb24tbGF5ZXIgbmVnb3RpYXRpb25zIG9uIGNsaWVudCBIZWxsby9oYW5kc2hha2UN Cm1lc3NhZ2VzIHNlZW1zIHRvIG1lIGxpa2UgcXVpdGUgYSByZWFzb25hYmxlIHRoaW5nIHRvIGRv Lg0KDQpOaWNvDQotLSANCg== From ekr@networkresonance.com Tue Apr 21 09:37:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB5F3A7052 for ; Tue, 21 Apr 2009 09:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOOQJODR5UaU for ; Tue, 21 Apr 2009 09:37:02 -0700 (PDT) Received: from kilo.networkresonance.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 8033428C2C9 for ; Tue, 21 Apr 2009 09:37:01 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 625EC1871D4; Tue, 21 Apr 2009 09:40:30 -0700 (PDT) Date: Tue, 21 Apr 2009 09:40:30 -0700 From: Eric Rescorla To: carlyoung@keycomm.co.uk In-Reply-To: <50078.1240329782@keycomm.co.uk> References: <50078.1240329782@keycomm.co.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090421164030.625EC1871D4@kilo.networkresonance.com> Cc: TLS Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 16:37:03 -0000 At Tue, 21 Apr 2009 17:03:02 +0100, carlyoung@keycomm.co.uk wrote: > > > > >On Tue 21/04/09 4:55 PM , Eric Rescorla ekr@networkresonance.com sent: > >>At Tue, 21 Apr 2009 16:32:54 +0100, Carl Young wrote: > >> > >> So, for TLS_RSA_WITH_3DES_EDE_CBC_SHA, assuming an RSA 1024 bit key-pair, > >> would the effective strength of the connection be 80 bits or am I looking to > >> compare apples and oranges? > >> > >> If I want to negotiate AES-256, should I really be using a 15360 bit RSA key > >> or, again, am I looking at this in the wrong way? > > > >Well, I think that this last bit is certainly looking at it the wrong > >way. We don't know of any conditions under which AES-256 would be > >breakable and AES-128 would not be, so talking about "key strength" > >just doesn't make much sense at that level. > > The "key strength" would be limited by the weakest link in the suite > though wouldn't it, which, in this case, is the RSA keys? Or are you > saying that the additional security of the PRF, key derivation > mechanisms, and the entropy in the random data overcomes this? No, I'm saying that talking about trying to match anything to AES-256 doesn't make sense. We don't know of any situation in which even AES-128 can be attacked. > I suppose what I'm trying to establish is that [hypothetically] if > the technology existed to brute-force attack a 1024 bit RSA key pair > in a short time-frame (say 1-2 days), would the attacker be able to > recover the AES-256 keys used in the TLS session and decode the > complete session, or is it more involved in that? If you're using static RSA (i.e., not DHE), then recovery of the RSA private key suffices to recover the traffic keys. -Ekr From root@core3.amsl.com Tue Apr 21 13:30:01 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F5C128C2FD; Tue, 21 Apr 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090421203001.8F5C128C2FD@core3.amsl.com> Date: Tue, 21 Apr 2009 13:30:01 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4366-bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2009 20:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Extensions: Extension Definitions Author(s) : D. Eastlake 3rd Filename : draft-ietf-tls-rfc4366-bis-04.txt Pages : 28 Date : 2009-4-20 This document provides specifications for existing TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-rfc4366-bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-21132058.I-D@ietf.org> --NextPart-- From simon@josefsson.org Wed Apr 22 03:34:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46843A6D0B for ; Wed, 22 Apr 2009 03:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnUT0JatC4jS for ; Wed, 22 Apr 2009 03:34:28 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D492D3A6CE5 for ; Wed, 22 Apr 2009 03:34:27 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LwZnp-0005ZE-Ur; Wed, 22 Apr 2009 12:35:42 +0200 From: Simon Josefsson To: Eric Rescorla References: <50078.1240329782@keycomm.co.uk> <20090421164030.625EC1871D4@kilo.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090422:ekr@networkresonance.com::otHVV6noYEEmZMmQ:CHxn X-Hashcash: 1:22:090422:carlyoung@keycomm.co.uk::be/IuXYuNGKVzhiF:cYUo X-Hashcash: 1:22:090422:tls@ietf.org::aPuXzVFy03bJZ78+:0FkA9 Date: Wed, 22 Apr 2009 12:35:37 +0200 In-Reply-To: <20090421164030.625EC1871D4@kilo.networkresonance.com> (Eric Rescorla's message of "Tue, 21 Apr 2009 09:40:30 -0700") Message-ID: <87vdoxt1qe.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 10:34:28 -0000 Eric Rescorla writes: > At Tue, 21 Apr 2009 17:03:02 +0100, > carlyoung@keycomm.co.uk wrote: >> >> >> >> >On Tue 21/04/09 4:55 PM , Eric Rescorla ekr@networkresonance.com sent: >> >>At Tue, 21 Apr 2009 16:32:54 +0100, Carl Young wrote: >> >> >> >> So, for TLS_RSA_WITH_3DES_EDE_CBC_SHA, assuming an RSA 1024 bit key-pair, >> >> would the effective strength of the connection be 80 bits or am I looking to >> >> compare apples and oranges? >> >> >> >> If I want to negotiate AES-256, should I really be using a 15360 bit RSA key >> >> or, again, am I looking at this in the wrong way? >> > >> >Well, I think that this last bit is certainly looking at it the wrong >> >way. We don't know of any conditions under which AES-256 would be >> >breakable and AES-128 would not be, so talking about "key strength" >> >just doesn't make much sense at that level. >> >> The "key strength" would be limited by the weakest link in the suite >> though wouldn't it, which, in this case, is the RSA keys? Or are you >> saying that the additional security of the PRF, key derivation >> mechanisms, and the entropy in the random data overcomes this? > > No, I'm saying that talking about trying to match anything to > AES-256 doesn't make sense. We don't know of any situation in > which even AES-128 can be attacked. What we can always do, though, is to compare the amount of work needed to break AES-256 with the amount of work needed to break RSA-y using state-of-the-art attacks. It's possible that this imply y=15360. However, I agree that this is looking at things the wrong way. The exercise should not have any practical consequences on what key sizes you use. One should focus on selecting appropriate security level for each algorithm. Today AES-128 and RSA-2048 will probably make implementation bugs the weakest link for the majority of users. /Simon From carlyoung@keycomm.co.uk Wed Apr 22 04:15:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF5A28C416 for ; Wed, 22 Apr 2009 04:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hx5in9eAoOo for ; Wed, 22 Apr 2009 04:15:18 -0700 (PDT) Received: from smtp-out-56.livemail.co.uk (smtp-out-50.livemail.co.uk [213.171.216.50]) by core3.amsl.com (Postfix) with ESMTP id 7EA1D28C476 for ; Wed, 22 Apr 2009 04:15:17 -0700 (PDT) Received: from localhost (mail213-171-216-231.livemail.co.uk [213.171.216.231]) by smtp-out-56.livemail.co.uk (Postfix) with ESMTP id 73F2248C9CA; Wed, 22 Apr 2009 12:16:32 +0100 (BST) MIME-Version: 1.0 X-Mailer: AtMail PHP 5.4 Message-ID: <51912.1240398992@keycomm.co.uk> To: "TLS" Content-Type: text/plain; charset="utf-8" X-Origin: 93.96.210.102 X-Atmail-Account: carlyoung@keycomm.co.uk Date: Wed, 22 Apr 2009 12:16:32 +0100 From: carlyoung@keycomm.co.uk Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlyoung@keycomm.co.uk List-Id: "This is the mailing list 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, 22 Apr 2009 11:15:19 -0000 >>On Wed 22/04/09 11:35 AM , Simon Josefsson simon@josefsson.org sent: >>> The "key strength" would be limited by the weakest link in the suite >>> though wouldn't it, which, in this case, is the RSA keys? Or are you >>> saying that the additional security of the PRF, key derivation >>> mechanisms, and the entropy in the random data overcomes this? >> >> No, I'm saying that talking about trying to match anything to=20 >> AES-256 doesn't make sense. We don't know of any situation in >> which even AES-128 can be attacked. > >What we can always do, though, is to compare the amount of work needed >to break AES-256 with the amount of work needed to break RSA-y using >state-of-the-art attacks. It's possible that this imply y=3D15360. > >However, I agree that this is looking at things the wrong way. The >exercise should not have any practical consequences on what key sizes >you use. One should focus on selecting appropriate security level for >each algorithm. Today AES-128 and RSA-2048 will probably make >implementation bugs the weakest link for the majority of users. Thanks for all the responses. I think the following text is a better way of= describing what I meant and why I was asking: We have a customer that mandated that we utilize AES-256 for the symmetric = encryption keys used on our TLS sessions, so we have complied, and this wor= ks fine. Looking at implementation details from the customer, I found that = they are using static X.509v3 certificates (CA issued), where the public ke= y size is only 1024 bits. Therefore, in my mind, they are getting a false sense of security from usin= g AES-256 as the underlying strength of the whole TLS session is determined= by the weakest point - in this case the 1024 bit RSA keys, which NIST stat= e to be equivalent to "80-bits" [when compared to a symmetric cipher I gues= s]. So, I would want to recommend to the customer that if they want a more secu= re TLS session, then they need to increase the RSA key sizes to "match" the= symmetric key strength, as the overall security 'strength' of their TLS se= ssions comes down to their RSA key size [as it's lower comparably to AES-25= 6]. Does this seem reasonable and make more sense than my original question? Regards, Carl From smb@cs.columbia.edu Wed Apr 22 04:37:02 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCAF3A6D13 for ; Wed, 22 Apr 2009 04:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DmRTfo3c+tu for ; Wed, 22 Apr 2009 04:37:01 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 30B093A6926 for ; Wed, 22 Apr 2009 04:37:01 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 0BE083286B1; Wed, 22 Apr 2009 11:38:16 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41BCA3286AD; Wed, 22 Apr 2009 11:38:14 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id D3713298403; Wed, 22 Apr 2009 07:38:10 -0400 (EDT) Date: Wed, 22 Apr 2009 07:38:10 -0400 From: "Steven M. Bellovin" To: carlyoung@keycomm.co.uk Message-ID: <20090422073810.5ab7248e@cs.columbia.edu> In-Reply-To: <51912.1240398992@keycomm.co.uk> References: <51912.1240398992@keycomm.co.uk> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: TLS Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 11:37:02 -0000 On Wed, 22 Apr 2009 12:16:32 +0100 carlyoung@keycomm.co.uk wrote: > > >>On Wed 22/04/09 11:35 AM , Simon Josefsson simon@josefsson.org sent: > >>> The "key strength" would be limited by the weakest link in the > >>> suite though wouldn't it, which, in this case, is the RSA keys? > >>> Or are you saying that the additional security of the PRF, key > >>> derivation mechanisms, and the entropy in the random data > >>> overcomes this? > >> > >> No, I'm saying that talking about trying to match anything to > >> AES-256 doesn't make sense. We don't know of any situation in > >> which even AES-128 can be attacked. > > > >What we can always do, though, is to compare the amount of work > >needed to break AES-256 with the amount of work needed to break > >RSA-y using state-of-the-art attacks. It's possible that this imply > >y=15360. > > > >However, I agree that this is looking at things the wrong way. The > >exercise should not have any practical consequences on what key sizes > >you use. One should focus on selecting appropriate security level for > >each algorithm. Today AES-128 and RSA-2048 will probably make > >implementation bugs the weakest link for the majority of users. > > Thanks for all the responses. I think the following text is a better > way of describing what I meant and why I was asking: > > We have a customer that mandated that we utilize AES-256 for the > symmetric encryption keys used on our TLS sessions, so we have > complied, and this works fine. Looking at implementation details from > the customer, I found that they are using static X.509v3 certificates > (CA issued), where the public key size is only 1024 bits. > > Therefore, in my mind, they are getting a false sense of security > from using AES-256 as the underlying strength of the whole TLS > session is determined by the weakest point - in this case the 1024 > bit RSA keys, which NIST state to be equivalent to "80-bits" [when > compared to a symmetric cipher I guess]. > > So, I would want to recommend to the customer that if they want a > more secure TLS session, then they need to increase the RSA key sizes > to "match" the symmetric key strength, as the overall security > 'strength' of their TLS sessions comes down to their RSA key size [as > it's lower comparably to AES-256]. > > Does this seem reasonable and make more sense than my original > question? > Yes -- see RFC 3766. NIST also has some recommendations, but I don't happen to know the publication number offhand. --Steve Bellovin, http://www.cs.columbia.edu/~smb From uri@ll.mit.edu Wed Apr 22 05:16:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ACEE28C3E0 for ; Wed, 22 Apr 2009 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrmdlTGDIsRv for ; Wed, 22 Apr 2009 05:16:19 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2A99E3A6CF3 for ; Wed, 22 Apr 2009 05:15:47 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MCGu8H029377; Wed, 22 Apr 2009 08:16:56 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAllaOCT; Wed Apr 22 08:10:23 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 08:10:23 -0400 From: "Blumenthal, Uri" To: "'carlyoung@keycomm.co.uk'" , "'tls@ietf.org'" Date: Wed, 22 Apr 2009 08:10:22 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDO+xatMKjGfzKSj6rOFK4ebAM7AAB2NgX Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31A@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 12:16:20 -0000 Q2FybCwNCg0KWW91IGFyZSBjb3JyZWN0IGluIHlvdXIgYXBwcm9hY2guIEl0IG1ha2VzIHNlbnNl IHRvIHN1Z2dlc3QgbG9uZ2VyIFJTQSBrZXlzIHRvIHRoYXQgY3VzdG9tZXIgb2YgeW91cnMsIGJh c2VkIG9uIHRoZSBOSVNUIHNwZWNzICh0aGUgZXhhY3QgcmVmZXJlbmNlIGVsdWRlcyBtZSBhdCB0 aGUgdGltZSkuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJv dW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFRMUyA8dGxzQGlldGYu b3JnPg0KU2VudDogV2VkIEFwciAyMiAwNzoxNjozMiAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBD b21wYXJhdGl2ZSBjaXBoZXIgc3VpdGUgc3RyZW5ndGhzDQoNCg0KPj5PbiBXZWQgMjIvMDQvMDkg MTE6MzUgQU0gLCBTaW1vbiBKb3NlZnNzb24gc2ltb25Aam9zZWZzc29uLm9yZyBzZW50Og0KPj4+ IFRoZSAia2V5IHN0cmVuZ3RoIiB3b3VsZCBiZSBsaW1pdGVkIGJ5IHRoZSB3ZWFrZXN0IGxpbmsg aW4gdGhlIHN1aXRlDQo+Pj4gdGhvdWdoIHdvdWxkbid0IGl0LCB3aGljaCwgaW4gdGhpcyBjYXNl LCBpcyB0aGUgUlNBIGtleXM/IE9yIGFyZSB5b3UNCj4+PiBzYXlpbmcgdGhhdCB0aGUgYWRkaXRp b25hbCBzZWN1cml0eSBvZiB0aGUgUFJGLCBrZXkgZGVyaXZhdGlvbg0KPj4+IG1lY2hhbmlzbXMs IGFuZCB0aGUgZW50cm9weSBpbiB0aGUgcmFuZG9tIGRhdGEgb3ZlcmNvbWVzIHRoaXM/DQo+Pg0K Pj4gTm8sIEknbSBzYXlpbmcgdGhhdCB0YWxraW5nIGFib3V0IHRyeWluZyB0byBtYXRjaCBhbnl0 aGluZyB0byANCj4+IEFFUy0yNTYgZG9lc24ndCBtYWtlIHNlbnNlLiBXZSBkb24ndCBrbm93IG9m IGFueSBzaXR1YXRpb24gaW4NCj4+IHdoaWNoIGV2ZW4gQUVTLTEyOCBjYW4gYmUgYXR0YWNrZWQu DQo+DQo+V2hhdCB3ZSBjYW4gYWx3YXlzIGRvLCB0aG91Z2gsIGlzIHRvIGNvbXBhcmUgdGhlIGFt b3VudCBvZiB3b3JrIG5lZWRlZA0KPnRvIGJyZWFrIEFFUy0yNTYgd2l0aCB0aGUgYW1vdW50IG9m IHdvcmsgbmVlZGVkIHRvIGJyZWFrIFJTQS15IHVzaW5nDQo+c3RhdGUtb2YtdGhlLWFydCBhdHRh Y2tzLiBJdCdzIHBvc3NpYmxlIHRoYXQgdGhpcyBpbXBseSB5PTE1MzYwLg0KPg0KPkhvd2V2ZXIs IEkgYWdyZWUgdGhhdCB0aGlzIGlzIGxvb2tpbmcgYXQgdGhpbmdzIHRoZSB3cm9uZyB3YXkuIFRo ZQ0KPmV4ZXJjaXNlIHNob3VsZCBub3QgaGF2ZSBhbnkgcHJhY3RpY2FsIGNvbnNlcXVlbmNlcyBv biB3aGF0IGtleSBzaXplcw0KPnlvdSB1c2UuIE9uZSBzaG91bGQgZm9jdXMgb24gc2VsZWN0aW5n IGFwcHJvcHJpYXRlIHNlY3VyaXR5IGxldmVsIGZvcg0KPmVhY2ggYWxnb3JpdGhtLiBUb2RheSBB RVMtMTI4IGFuZCBSU0EtMjA0OCB3aWxsIHByb2JhYmx5IG1ha2UNCj5pbXBsZW1lbnRhdGlvbiBi dWdzIHRoZSB3ZWFrZXN0IGxpbmsgZm9yIHRoZSBtYWpvcml0eSBvZiB1c2Vycy4NCg0KVGhhbmtz IGZvciBhbGwgdGhlIHJlc3BvbnNlcy4gSSB0aGluayB0aGUgZm9sbG93aW5nIHRleHQgaXMgYSBi ZXR0ZXIgd2F5IG9mIGRlc2NyaWJpbmcgd2hhdCBJIG1lYW50IGFuZCB3aHkgSSB3YXMgYXNraW5n Og0KDQpXZSBoYXZlIGEgY3VzdG9tZXIgdGhhdCBtYW5kYXRlZCB0aGF0IHdlIHV0aWxpemUgQUVT LTI1NiBmb3IgdGhlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGtleXMgdXNlZCBvbiBvdXIgVExTIHNl c3Npb25zLCBzbyB3ZSBoYXZlIGNvbXBsaWVkLCBhbmQgdGhpcyB3b3JrcyBmaW5lLiBMb29raW5n IGF0IGltcGxlbWVudGF0aW9uIGRldGFpbHMgZnJvbSB0aGUgY3VzdG9tZXIsIEkgZm91bmQgdGhh dCB0aGV5IGFyZSB1c2luZyBzdGF0aWMgWC41MDl2MyBjZXJ0aWZpY2F0ZXMgKENBIGlzc3VlZCks IHdoZXJlIHRoZSBwdWJsaWMga2V5IHNpemUgaXMgb25seSAxMDI0IGJpdHMuDQoNClRoZXJlZm9y ZSwgaW4gbXkgbWluZCwgdGhleSBhcmUgZ2V0dGluZyBhIGZhbHNlIHNlbnNlIG9mIHNlY3VyaXR5 IGZyb20gdXNpbmcgQUVTLTI1NiBhcyB0aGUgdW5kZXJseWluZyBzdHJlbmd0aCBvZiB0aGUgd2hv bGUgVExTIHNlc3Npb24gaXMgZGV0ZXJtaW5lZCBieSB0aGUgd2Vha2VzdCBwb2ludCAtIGluIHRo aXMgY2FzZSB0aGUgMTAyNCBiaXQgUlNBIGtleXMsIHdoaWNoIE5JU1Qgc3RhdGUgdG8gYmUgZXF1 aXZhbGVudCB0byAiODAtYml0cyIgW3doZW4gY29tcGFyZWQgdG8gYSBzeW1tZXRyaWMgY2lwaGVy IEkgZ3Vlc3NdLg0KDQpTbywgSSB3b3VsZCB3YW50IHRvIHJlY29tbWVuZCB0byB0aGUgY3VzdG9t ZXIgdGhhdCBpZiB0aGV5IHdhbnQgYSBtb3JlIHNlY3VyZSBUTFMgc2Vzc2lvbiwgdGhlbiB0aGV5 IG5lZWQgdG8gaW5jcmVhc2UgdGhlIFJTQSBrZXkgc2l6ZXMgdG8gIm1hdGNoIiB0aGUgc3ltbWV0 cmljIGtleSBzdHJlbmd0aCwgYXMgdGhlIG92ZXJhbGwgc2VjdXJpdHkgJ3N0cmVuZ3RoJyBvZiB0 aGVpciBUTFMgc2Vzc2lvbnMgY29tZXMgZG93biB0byB0aGVpciBSU0Ega2V5IHNpemUgW2FzIGl0 J3MgbG93ZXIgY29tcGFyYWJseSB0byBBRVMtMjU2XS4NCg0KRG9lcyB0aGlzIHNlZW0gcmVhc29u YWJsZSBhbmQgbWFrZSBtb3JlIHNlbnNlIHRoYW4gbXkgb3JpZ2luYWwgcXVlc3Rpb24/DQoNClJl Z2FyZHMsDQoNCkNhcmwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From uri@ll.mit.edu Wed Apr 22 05:17:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB0E3A6A95 for ; Wed, 22 Apr 2009 05:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBDWa+AhhCI0 for ; Wed, 22 Apr 2009 05:17:36 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 390233A693C for ; Wed, 22 Apr 2009 05:17:36 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MCInqn000900; Wed, 22 Apr 2009 08:18:49 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAllaOCT; Wed Apr 22 08:10:23 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 08:10:23 -0400 From: "Blumenthal, Uri" To: "'carlyoung@keycomm.co.uk'" , "'tls@ietf.org'" Date: Wed, 22 Apr 2009 08:10:22 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDO+xatMKjGfzKSj6rOFK4ebAM7AAB2NgX Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31A@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 12:17:36 -0000 Q2FybCwNCg0KWW91IGFyZSBjb3JyZWN0IGluIHlvdXIgYXBwcm9hY2guIEl0IG1ha2VzIHNlbnNl IHRvIHN1Z2dlc3QgbG9uZ2VyIFJTQSBrZXlzIHRvIHRoYXQgY3VzdG9tZXIgb2YgeW91cnMsIGJh c2VkIG9uIHRoZSBOSVNUIHNwZWNzICh0aGUgZXhhY3QgcmVmZXJlbmNlIGVsdWRlcyBtZSBhdCB0 aGUgdGltZSkuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJv dW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFRMUyA8dGxzQGlldGYu b3JnPg0KU2VudDogV2VkIEFwciAyMiAwNzoxNjozMiAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBD b21wYXJhdGl2ZSBjaXBoZXIgc3VpdGUgc3RyZW5ndGhzDQoNCg0KPj5PbiBXZWQgMjIvMDQvMDkg MTE6MzUgQU0gLCBTaW1vbiBKb3NlZnNzb24gc2ltb25Aam9zZWZzc29uLm9yZyBzZW50Og0KPj4+ IFRoZSAia2V5IHN0cmVuZ3RoIiB3b3VsZCBiZSBsaW1pdGVkIGJ5IHRoZSB3ZWFrZXN0IGxpbmsg aW4gdGhlIHN1aXRlDQo+Pj4gdGhvdWdoIHdvdWxkbid0IGl0LCB3aGljaCwgaW4gdGhpcyBjYXNl LCBpcyB0aGUgUlNBIGtleXM/IE9yIGFyZSB5b3UNCj4+PiBzYXlpbmcgdGhhdCB0aGUgYWRkaXRp b25hbCBzZWN1cml0eSBvZiB0aGUgUFJGLCBrZXkgZGVyaXZhdGlvbg0KPj4+IG1lY2hhbmlzbXMs IGFuZCB0aGUgZW50cm9weSBpbiB0aGUgcmFuZG9tIGRhdGEgb3ZlcmNvbWVzIHRoaXM/DQo+Pg0K Pj4gTm8sIEknbSBzYXlpbmcgdGhhdCB0YWxraW5nIGFib3V0IHRyeWluZyB0byBtYXRjaCBhbnl0 aGluZyB0byANCj4+IEFFUy0yNTYgZG9lc24ndCBtYWtlIHNlbnNlLiBXZSBkb24ndCBrbm93IG9m IGFueSBzaXR1YXRpb24gaW4NCj4+IHdoaWNoIGV2ZW4gQUVTLTEyOCBjYW4gYmUgYXR0YWNrZWQu DQo+DQo+V2hhdCB3ZSBjYW4gYWx3YXlzIGRvLCB0aG91Z2gsIGlzIHRvIGNvbXBhcmUgdGhlIGFt b3VudCBvZiB3b3JrIG5lZWRlZA0KPnRvIGJyZWFrIEFFUy0yNTYgd2l0aCB0aGUgYW1vdW50IG9m IHdvcmsgbmVlZGVkIHRvIGJyZWFrIFJTQS15IHVzaW5nDQo+c3RhdGUtb2YtdGhlLWFydCBhdHRh Y2tzLiBJdCdzIHBvc3NpYmxlIHRoYXQgdGhpcyBpbXBseSB5PTE1MzYwLg0KPg0KPkhvd2V2ZXIs IEkgYWdyZWUgdGhhdCB0aGlzIGlzIGxvb2tpbmcgYXQgdGhpbmdzIHRoZSB3cm9uZyB3YXkuIFRo ZQ0KPmV4ZXJjaXNlIHNob3VsZCBub3QgaGF2ZSBhbnkgcHJhY3RpY2FsIGNvbnNlcXVlbmNlcyBv biB3aGF0IGtleSBzaXplcw0KPnlvdSB1c2UuIE9uZSBzaG91bGQgZm9jdXMgb24gc2VsZWN0aW5n IGFwcHJvcHJpYXRlIHNlY3VyaXR5IGxldmVsIGZvcg0KPmVhY2ggYWxnb3JpdGhtLiBUb2RheSBB RVMtMTI4IGFuZCBSU0EtMjA0OCB3aWxsIHByb2JhYmx5IG1ha2UNCj5pbXBsZW1lbnRhdGlvbiBi dWdzIHRoZSB3ZWFrZXN0IGxpbmsgZm9yIHRoZSBtYWpvcml0eSBvZiB1c2Vycy4NCg0KVGhhbmtz IGZvciBhbGwgdGhlIHJlc3BvbnNlcy4gSSB0aGluayB0aGUgZm9sbG93aW5nIHRleHQgaXMgYSBi ZXR0ZXIgd2F5IG9mIGRlc2NyaWJpbmcgd2hhdCBJIG1lYW50IGFuZCB3aHkgSSB3YXMgYXNraW5n Og0KDQpXZSBoYXZlIGEgY3VzdG9tZXIgdGhhdCBtYW5kYXRlZCB0aGF0IHdlIHV0aWxpemUgQUVT LTI1NiBmb3IgdGhlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIGtleXMgdXNlZCBvbiBvdXIgVExTIHNl c3Npb25zLCBzbyB3ZSBoYXZlIGNvbXBsaWVkLCBhbmQgdGhpcyB3b3JrcyBmaW5lLiBMb29raW5n IGF0IGltcGxlbWVudGF0aW9uIGRldGFpbHMgZnJvbSB0aGUgY3VzdG9tZXIsIEkgZm91bmQgdGhh dCB0aGV5IGFyZSB1c2luZyBzdGF0aWMgWC41MDl2MyBjZXJ0aWZpY2F0ZXMgKENBIGlzc3VlZCks IHdoZXJlIHRoZSBwdWJsaWMga2V5IHNpemUgaXMgb25seSAxMDI0IGJpdHMuDQoNClRoZXJlZm9y ZSwgaW4gbXkgbWluZCwgdGhleSBhcmUgZ2V0dGluZyBhIGZhbHNlIHNlbnNlIG9mIHNlY3VyaXR5 IGZyb20gdXNpbmcgQUVTLTI1NiBhcyB0aGUgdW5kZXJseWluZyBzdHJlbmd0aCBvZiB0aGUgd2hv bGUgVExTIHNlc3Npb24gaXMgZGV0ZXJtaW5lZCBieSB0aGUgd2Vha2VzdCBwb2ludCAtIGluIHRo aXMgY2FzZSB0aGUgMTAyNCBiaXQgUlNBIGtleXMsIHdoaWNoIE5JU1Qgc3RhdGUgdG8gYmUgZXF1 aXZhbGVudCB0byAiODAtYml0cyIgW3doZW4gY29tcGFyZWQgdG8gYSBzeW1tZXRyaWMgY2lwaGVy IEkgZ3Vlc3NdLg0KDQpTbywgSSB3b3VsZCB3YW50IHRvIHJlY29tbWVuZCB0byB0aGUgY3VzdG9t ZXIgdGhhdCBpZiB0aGV5IHdhbnQgYSBtb3JlIHNlY3VyZSBUTFMgc2Vzc2lvbiwgdGhlbiB0aGV5 IG5lZWQgdG8gaW5jcmVhc2UgdGhlIFJTQSBrZXkgc2l6ZXMgdG8gIm1hdGNoIiB0aGUgc3ltbWV0 cmljIGtleSBzdHJlbmd0aCwgYXMgdGhlIG92ZXJhbGwgc2VjdXJpdHkgJ3N0cmVuZ3RoJyBvZiB0 aGVpciBUTFMgc2Vzc2lvbnMgY29tZXMgZG93biB0byB0aGVpciBSU0Ega2V5IHNpemUgW2FzIGl0 J3MgbG93ZXIgY29tcGFyYWJseSB0byBBRVMtMjU2XS4NCg0KRG9lcyB0aGlzIHNlZW0gcmVhc29u YWJsZSBhbmQgbWFrZSBtb3JlIHNlbnNlIHRoYW4gbXkgb3JpZ2luYWwgcXVlc3Rpb24/DQoNClJl Z2FyZHMsDQoNCkNhcmwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From ekr@networkresonance.com Wed Apr 22 05:38:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6633A6BF2 for ; Wed, 22 Apr 2009 05:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEZ25VI7dDxx for ; Wed, 22 Apr 2009 05:38:42 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9FC673A6BCA for ; Wed, 22 Apr 2009 05:38:42 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 127AC18842B; Wed, 22 Apr 2009 05:42:16 -0700 (PDT) Date: Wed, 22 Apr 2009 05:42:15 -0700 From: Eric Rescorla To: carlyoung@keycomm.co.uk In-Reply-To: <51912.1240398992@keycomm.co.uk> References: <51912.1240398992@keycomm.co.uk> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090422124216.127AC18842B@kilo.networkresonance.com> Cc: TLS Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 12:38:43 -0000 At Wed, 22 Apr 2009 12:16:32 +0100, carlyoung@keycomm.co.uk wrote: > > > >>On Wed 22/04/09 11:35 AM , Simon Josefsson simon@josefsson.org sent: > >>> The "key strength" would be limited by the weakest link in the suite > >>> though wouldn't it, which, in this case, is the RSA keys? Or are you > >>> saying that the additional security of the PRF, key derivation > >>> mechanisms, and the entropy in the random data overcomes this? > >> > >> No, I'm saying that talking about trying to match anything to > >> AES-256 doesn't make sense. We don't know of any situation in > >> which even AES-128 can be attacked. > > > >What we can always do, though, is to compare the amount of work needed > >to break AES-256 with the amount of work needed to break RSA-y using > >state-of-the-art attacks. It's possible that this imply y=15360. > > > >However, I agree that this is looking at things the wrong way. The > >exercise should not have any practical consequences on what key sizes > >you use. One should focus on selecting appropriate security level for > >each algorithm. Today AES-128 and RSA-2048 will probably make > >implementation bugs the weakest link for the majority of users. > > Thanks for all the responses. I think the following text is a better way of describing what I meant and why I was asking: > > We have a customer that mandated that we utilize AES-256 for the > symmetric encryption keys used on our TLS sessions, so we have > complied, and this works fine. Looking at implementation details > from the customer, I found that they are using static X.509v3 > certificates (CA issued), where the public key size is only 1024 > bits. > > Therefore, in my mind, they are getting a false sense of security > from using AES-256 as the underlying strength of the whole TLS > session is determined by the weakest point - in this case the 1024 > bit RSA keys, which NIST state to be equivalent to "80-bits" [when > compared to a symmetric cipher I guess]. Sure, but they're getting a false sense of security from AES-256 as well. Let's say for the sake of argument that you had a system that used static, randomly generated 256-bit AES keys. Do you really think that's 2^{128} times more secure than one that uses 128-bit AES? > So, I would want to recommend to the customer that if they want a > more secure TLS session, then they need to increase the RSA key > sizes to "match" the symmetric key strength, as the overall security > 'strength' of their TLS sessions comes down to their RSA key size > [as it's lower comparably to AES-256]. > > Does this seem reasonable and make more sense than my original question? It makes more sense to say you need a bigger RSA key, but IMO the "match" thing is the wrong way to look at it. Rather, you should decide on your minimum security level and choose algorithms that support that. I don't think having them match is particularly interesting once we're at the point where there is no plausible non-analytic attack on the algorithm. -Ekr From uri@ll.mit.edu Wed Apr 22 06:31:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF0728C505 for ; Wed, 22 Apr 2009 06:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07jH6k0cwBeH for ; Wed, 22 Apr 2009 06:31:18 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id A4CAB28C4F5 for ; Wed, 22 Apr 2009 06:31:14 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MDWQZj003084 for ; Wed, 22 Apr 2009 09:32:26 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAWbayHN; Wed Apr 22 09:24:27 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 09:24:27 -0400 From: "Blumenthal, Uri" CC: "'tls@ietf.org'" Date: Wed, 22 Apr 2009 09:24:26 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDR4gHFWRtoTAoT7urITdRldnBQwABiCqh Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 13:31:20 -0000 RXJpYywNCg0KSSBkaXNhZ3JlZS4gWW91J3JlIG1peGluZyB0b2dldGhlciB0d28gb3J0aG9nb25h bCBpc3N1ZXM6IHNlY3VyaXR5IG9mIGFsZ29yaXRobXMgYW5kIHNlY3VyaXR5IG9mIGltcGxlbWVu dGF0aW9uLg0KDQpOSVNUIHJlY29tbWVuZHMgdGhhdCBhbGdvcml0aG1zIGluIGEgY2lwaGVyIHN1 aXRlIGFyZSBvZiBjb21wYXJhYmxlIHN0cmVuZ3RoLiBUaGF0IGluY2x1ZGVzIHJlbGF0aXZlIGtl eSBsZW5ndGguDQoNClRoZSBmYWN0IHRoYXQgZGVzcGl0ZSBvZiB1c2luZyBzZWN1cmUgYWxnb3Jp dGhtcyB5b3VyIGltcGxlbWVudGF0aW9uIHN0aWxsIGNhbiBoYXZlIGV4cGxvaXRhYmxlIGJ1Z3Mg KHRoYXQgbnVsbGlmeSB0aGUgYmVuZWZpdHMgb2YgY3J5cHRvZ3JhcGh5KSBpcyAxMDAlIGlycmVs ZXZhbnQgdG8gdGhlIGlzc3VlIG9mIHNlbGVjdGluZyBhbGdvcml0aG1zIGFuZCB0aGVpciBwYXJh bWV0ZXJzLg0KDQpXaHkgZGlkbid0IE5JU1Qgc2F5ICJ5b3VyIGltcGxlbWVudGF0aW9ucyB3aWxs IHN1Y2sgYW55d2F5LCB0aGVyZWZvcmUgdGhlcmUncyBubyBuZWVkIHRvIGRlZmluZSBBRVMgd2l0 aCBtb3JlIHRoYW4gMTI4LWJpdCBrZXlzIC0geW91J2xsIGJlIGF0dGFja2VkIHZpYSBjb2RlIG5v dCBBRVMgd2Vha25lc3NlcyI/DQoNCkl0IG1pZ2h0IGV2ZW4gYmUgcG9zc2libGUgdGhhdCBDYXJs J3MgY3VzdG9tZXIgaXMgYWxzbyBhd2FyZSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMgYW5kIGlz IHRha2luZyBjYXJlIG9mIHRoZW0sIGhvd2V2ZXIgdW5saWtlbHkgaXQgbWF5IHNvdW5kLg0KDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5v cmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IGNhcmx5b3VuZ0BrZXljb21tLmNvLnVrIDxj YXJseW91bmdAa2V5Y29tbS5jby51az4NCkNjOiBUTFMgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFdl ZCBBcHIgMjIgMDg6NDI6MTUgMjAwOQpTdWJqZWN0OiBSZTogW1RMU10gQ29tcGFyYXRpdmUgY2lw aGVyIHN1aXRlIHN0cmVuZ3Rocw0KDQpBdCBXZWQsIDIyIEFwciAyMDA5IDEyOjE2OjMyICswMTAw LA0KY2FybHlvdW5nQGtleWNvbW0uY28udWsgd3JvdGU6DQo+IA0KPiANCj4gPj5PbiBXZWQgMjIv MDQvMDkgMTE6MzUgQU0gLCBTaW1vbiBKb3NlZnNzb24gc2ltb25Aam9zZWZzc29uLm9yZyBzZW50 Og0KPiA+Pj4gVGhlICJrZXkgc3RyZW5ndGgiIHdvdWxkIGJlIGxpbWl0ZWQgYnkgdGhlIHdlYWtl c3QgbGluayBpbiB0aGUgc3VpdGUNCj4gPj4+IHRob3VnaCB3b3VsZG4ndCBpdCwgd2hpY2gsIGlu IHRoaXMgY2FzZSwgaXMgdGhlIFJTQSBrZXlzPyBPciBhcmUgeW91DQo+ID4+PiBzYXlpbmcgdGhh dCB0aGUgYWRkaXRpb25hbCBzZWN1cml0eSBvZiB0aGUgUFJGLCBrZXkgZGVyaXZhdGlvbg0KPiA+ Pj4gbWVjaGFuaXNtcywgYW5kIHRoZSBlbnRyb3B5IGluIHRoZSByYW5kb20gZGF0YSBvdmVyY29t ZXMgdGhpcz8NCj4gPj4NCj4gPj4gTm8sIEknbSBzYXlpbmcgdGhhdCB0YWxraW5nIGFib3V0IHRy eWluZyB0byBtYXRjaCBhbnl0aGluZyB0byANCj4gPj4gQUVTLTI1NiBkb2Vzbid0IG1ha2Ugc2Vu c2UuIFdlIGRvbid0IGtub3cgb2YgYW55IHNpdHVhdGlvbiBpbg0KPiA+PiB3aGljaCBldmVuIEFF Uy0xMjggY2FuIGJlIGF0dGFja2VkLg0KPiA+DQo+ID5XaGF0IHdlIGNhbiBhbHdheXMgZG8sIHRo b3VnaCwgaXMgdG8gY29tcGFyZSB0aGUgYW1vdW50IG9mIHdvcmsgbmVlZGVkDQo+ID50byBicmVh ayBBRVMtMjU2IHdpdGggdGhlIGFtb3VudCBvZiB3b3JrIG5lZWRlZCB0byBicmVhayBSU0EteSB1 c2luZw0KPiA+c3RhdGUtb2YtdGhlLWFydCBhdHRhY2tzLiBJdCdzIHBvc3NpYmxlIHRoYXQgdGhp cyBpbXBseSB5PTE1MzYwLg0KPiA+DQo+ID5Ib3dldmVyLCBJIGFncmVlIHRoYXQgdGhpcyBpcyBs b29raW5nIGF0IHRoaW5ncyB0aGUgd3Jvbmcgd2F5LiBUaGUNCj4gPmV4ZXJjaXNlIHNob3VsZCBu b3QgaGF2ZSBhbnkgcHJhY3RpY2FsIGNvbnNlcXVlbmNlcyBvbiB3aGF0IGtleSBzaXplcw0KPiA+ eW91IHVzZS4gT25lIHNob3VsZCBmb2N1cyBvbiBzZWxlY3RpbmcgYXBwcm9wcmlhdGUgc2VjdXJp dHkgbGV2ZWwgZm9yDQo+ID5lYWNoIGFsZ29yaXRobS4gVG9kYXkgQUVTLTEyOCBhbmQgUlNBLTIw NDggd2lsbCBwcm9iYWJseSBtYWtlDQo+ID5pbXBsZW1lbnRhdGlvbiBidWdzIHRoZSB3ZWFrZXN0 IGxpbmsgZm9yIHRoZSBtYWpvcml0eSBvZiB1c2Vycy4NCj4gDQo+IFRoYW5rcyBmb3IgYWxsIHRo ZSByZXNwb25zZXMuIEkgdGhpbmsgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIGEgYmV0dGVyIHdheSBv ZiBkZXNjcmliaW5nIHdoYXQgSSBtZWFudCBhbmQgd2h5IEkgd2FzIGFza2luZzoNCj4gDQo+IFdl IGhhdmUgYSBjdXN0b21lciB0aGF0IG1hbmRhdGVkIHRoYXQgd2UgdXRpbGl6ZSBBRVMtMjU2IGZv ciB0aGUNCj4gc3ltbWV0cmljIGVuY3J5cHRpb24ga2V5cyB1c2VkIG9uIG91ciBUTFMgc2Vzc2lv bnMsIHNvIHdlIGhhdmUNCj4gY29tcGxpZWQsIGFuZCB0aGlzIHdvcmtzIGZpbmUuIExvb2tpbmcg YXQgaW1wbGVtZW50YXRpb24gZGV0YWlscw0KPiBmcm9tIHRoZSBjdXN0b21lciwgSSBmb3VuZCB0 aGF0IHRoZXkgYXJlIHVzaW5nIHN0YXRpYyBYLjUwOXYzDQo+IGNlcnRpZmljYXRlcyAoQ0EgaXNz dWVkKSwgd2hlcmUgdGhlIHB1YmxpYyBrZXkgc2l6ZSBpcyBvbmx5IDEwMjQNCj4gYml0cy4NCj4g DQo+IFRoZXJlZm9yZSwgaW4gbXkgbWluZCwgdGhleSBhcmUgZ2V0dGluZyBhIGZhbHNlIHNlbnNl IG9mIHNlY3VyaXR5DQo+IGZyb20gdXNpbmcgQUVTLTI1NiBhcyB0aGUgdW5kZXJseWluZyBzdHJl bmd0aCBvZiB0aGUgd2hvbGUgVExTDQo+IHNlc3Npb24gaXMgZGV0ZXJtaW5lZCBieSB0aGUgd2Vh a2VzdCBwb2ludCAtIGluIHRoaXMgY2FzZSB0aGUgMTAyNA0KPiBiaXQgUlNBIGtleXMsIHdoaWNo IE5JU1Qgc3RhdGUgdG8gYmUgZXF1aXZhbGVudCB0byAiODAtYml0cyIgW3doZW4NCj4gY29tcGFy ZWQgdG8gYSBzeW1tZXRyaWMgY2lwaGVyIEkgZ3Vlc3NdLg0KDQpTdXJlLCBidXQgdGhleSdyZSBn ZXR0aW5nIGEgZmFsc2Ugc2Vuc2Ugb2Ygc2VjdXJpdHkgZnJvbSBBRVMtMjU2DQphcyB3ZWxsLiBM ZXQncyBzYXkgZm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50IHRoYXQgeW91IGhhZA0KYSBzeXN0ZW0g dGhhdCB1c2VkIHN0YXRpYywgcmFuZG9tbHkgZ2VuZXJhdGVkIDI1Ni1iaXQgQUVTDQprZXlzLiBE byB5b3UgcmVhbGx5IHRoaW5rIHRoYXQncyAyXnsxMjh9IHRpbWVzIG1vcmUgc2VjdXJlDQp0aGFu IG9uZSB0aGF0IHVzZXMgMTI4LWJpdCBBRVM/DQoNCg0KPiBTbywgSSB3b3VsZCB3YW50IHRvIHJl Y29tbWVuZCB0byB0aGUgY3VzdG9tZXIgdGhhdCBpZiB0aGV5IHdhbnQgYQ0KPiBtb3JlIHNlY3Vy ZSBUTFMgc2Vzc2lvbiwgdGhlbiB0aGV5IG5lZWQgdG8gaW5jcmVhc2UgdGhlIFJTQSBrZXkNCj4g c2l6ZXMgdG8gIm1hdGNoIiB0aGUgc3ltbWV0cmljIGtleSBzdHJlbmd0aCwgYXMgdGhlIG92ZXJh bGwgc2VjdXJpdHkNCj4gJ3N0cmVuZ3RoJyBvZiB0aGVpciBUTFMgc2Vzc2lvbnMgY29tZXMgZG93 biB0byB0aGVpciBSU0Ega2V5IHNpemUNCj4gW2FzIGl0J3MgbG93ZXIgY29tcGFyYWJseSB0byBB RVMtMjU2XS4NCj4gDQo+IERvZXMgdGhpcyBzZWVtIHJlYXNvbmFibGUgYW5kIG1ha2UgbW9yZSBz ZW5zZSB0aGFuIG15IG9yaWdpbmFsIHF1ZXN0aW9uPw0KDQpJdCBtYWtlcyBtb3JlIHNlbnNlIHRv IHNheSB5b3UgbmVlZCBhIGJpZ2dlciBSU0Ega2V5LCBidXQgSU1PDQp0aGUgIm1hdGNoIiB0aGlu ZyBpcyB0aGUgd3Jvbmcgd2F5IHRvIGxvb2sgYXQgaXQuIFJhdGhlciwgeW91DQpzaG91bGQgZGVj aWRlIG9uIHlvdXIgbWluaW11bSBzZWN1cml0eSBsZXZlbCBhbmQgY2hvb3NlIGFsZ29yaXRobXMN CnRoYXQgc3VwcG9ydCB0aGF0LiBJIGRvbid0IHRoaW5rIGhhdmluZyB0aGVtIG1hdGNoIGlzIHBh cnRpY3VsYXJseQ0KaW50ZXJlc3Rpbmcgb25jZSB3ZSdyZSBhdCB0aGUgcG9pbnQgd2hlcmUgdGhl cmUgaXMgbm8gcGxhdXNpYmxlDQpub24tYW5hbHl0aWMgYXR0YWNrIG9uIHRoZSBhbGdvcml0aG0u DQoNCi1Fa3INCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQo= From uri@ll.mit.edu Wed Apr 22 06:35:44 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67CB28C50C for ; Wed, 22 Apr 2009 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWQLgbvcpc4C for ; Wed, 22 Apr 2009 06:35:44 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 4F69928C50E for ; Wed, 22 Apr 2009 06:35:37 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MDaquQ011304 for ; Wed, 22 Apr 2009 09:36:52 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAWbayHN; Wed Apr 22 09:24:27 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 09:24:27 -0400 From: "Blumenthal, Uri" CC: "'tls@ietf.org'" Date: Wed, 22 Apr 2009 09:24:26 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDR4gHFWRtoTAoT7urITdRldnBQwABiCqh Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 13:35:44 -0000 RXJpYywNCg0KSSBkaXNhZ3JlZS4gWW91J3JlIG1peGluZyB0b2dldGhlciB0d28gb3J0aG9nb25h bCBpc3N1ZXM6IHNlY3VyaXR5IG9mIGFsZ29yaXRobXMgYW5kIHNlY3VyaXR5IG9mIGltcGxlbWVu dGF0aW9uLg0KDQpOSVNUIHJlY29tbWVuZHMgdGhhdCBhbGdvcml0aG1zIGluIGEgY2lwaGVyIHN1 aXRlIGFyZSBvZiBjb21wYXJhYmxlIHN0cmVuZ3RoLiBUaGF0IGluY2x1ZGVzIHJlbGF0aXZlIGtl eSBsZW5ndGguDQoNClRoZSBmYWN0IHRoYXQgZGVzcGl0ZSBvZiB1c2luZyBzZWN1cmUgYWxnb3Jp dGhtcyB5b3VyIGltcGxlbWVudGF0aW9uIHN0aWxsIGNhbiBoYXZlIGV4cGxvaXRhYmxlIGJ1Z3Mg KHRoYXQgbnVsbGlmeSB0aGUgYmVuZWZpdHMgb2YgY3J5cHRvZ3JhcGh5KSBpcyAxMDAlIGlycmVs ZXZhbnQgdG8gdGhlIGlzc3VlIG9mIHNlbGVjdGluZyBhbGdvcml0aG1zIGFuZCB0aGVpciBwYXJh bWV0ZXJzLg0KDQpXaHkgZGlkbid0IE5JU1Qgc2F5ICJ5b3VyIGltcGxlbWVudGF0aW9ucyB3aWxs IHN1Y2sgYW55d2F5LCB0aGVyZWZvcmUgdGhlcmUncyBubyBuZWVkIHRvIGRlZmluZSBBRVMgd2l0 aCBtb3JlIHRoYW4gMTI4LWJpdCBrZXlzIC0geW91J2xsIGJlIGF0dGFja2VkIHZpYSBjb2RlIG5v dCBBRVMgd2Vha25lc3NlcyI/DQoNCkl0IG1pZ2h0IGV2ZW4gYmUgcG9zc2libGUgdGhhdCBDYXJs J3MgY3VzdG9tZXIgaXMgYWxzbyBhd2FyZSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMgYW5kIGlz IHRha2luZyBjYXJlIG9mIHRoZW0sIGhvd2V2ZXIgdW5saWtlbHkgaXQgbWF5IHNvdW5kLg0KDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5v cmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IGNhcmx5b3VuZ0BrZXljb21tLmNvLnVrIDxj YXJseW91bmdAa2V5Y29tbS5jby51az4NCkNjOiBUTFMgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFdl ZCBBcHIgMjIgMDg6NDI6MTUgMjAwOQpTdWJqZWN0OiBSZTogW1RMU10gQ29tcGFyYXRpdmUgY2lw aGVyIHN1aXRlIHN0cmVuZ3Rocw0KDQpBdCBXZWQsIDIyIEFwciAyMDA5IDEyOjE2OjMyICswMTAw LA0KY2FybHlvdW5nQGtleWNvbW0uY28udWsgd3JvdGU6DQo+IA0KPiANCj4gPj5PbiBXZWQgMjIv MDQvMDkgMTE6MzUgQU0gLCBTaW1vbiBKb3NlZnNzb24gc2ltb25Aam9zZWZzc29uLm9yZyBzZW50 Og0KPiA+Pj4gVGhlICJrZXkgc3RyZW5ndGgiIHdvdWxkIGJlIGxpbWl0ZWQgYnkgdGhlIHdlYWtl c3QgbGluayBpbiB0aGUgc3VpdGUNCj4gPj4+IHRob3VnaCB3b3VsZG4ndCBpdCwgd2hpY2gsIGlu IHRoaXMgY2FzZSwgaXMgdGhlIFJTQSBrZXlzPyBPciBhcmUgeW91DQo+ID4+PiBzYXlpbmcgdGhh dCB0aGUgYWRkaXRpb25hbCBzZWN1cml0eSBvZiB0aGUgUFJGLCBrZXkgZGVyaXZhdGlvbg0KPiA+ Pj4gbWVjaGFuaXNtcywgYW5kIHRoZSBlbnRyb3B5IGluIHRoZSByYW5kb20gZGF0YSBvdmVyY29t ZXMgdGhpcz8NCj4gPj4NCj4gPj4gTm8sIEknbSBzYXlpbmcgdGhhdCB0YWxraW5nIGFib3V0IHRy eWluZyB0byBtYXRjaCBhbnl0aGluZyB0byANCj4gPj4gQUVTLTI1NiBkb2Vzbid0IG1ha2Ugc2Vu c2UuIFdlIGRvbid0IGtub3cgb2YgYW55IHNpdHVhdGlvbiBpbg0KPiA+PiB3aGljaCBldmVuIEFF Uy0xMjggY2FuIGJlIGF0dGFja2VkLg0KPiA+DQo+ID5XaGF0IHdlIGNhbiBhbHdheXMgZG8sIHRo b3VnaCwgaXMgdG8gY29tcGFyZSB0aGUgYW1vdW50IG9mIHdvcmsgbmVlZGVkDQo+ID50byBicmVh ayBBRVMtMjU2IHdpdGggdGhlIGFtb3VudCBvZiB3b3JrIG5lZWRlZCB0byBicmVhayBSU0EteSB1 c2luZw0KPiA+c3RhdGUtb2YtdGhlLWFydCBhdHRhY2tzLiBJdCdzIHBvc3NpYmxlIHRoYXQgdGhp cyBpbXBseSB5PTE1MzYwLg0KPiA+DQo+ID5Ib3dldmVyLCBJIGFncmVlIHRoYXQgdGhpcyBpcyBs b29raW5nIGF0IHRoaW5ncyB0aGUgd3Jvbmcgd2F5LiBUaGUNCj4gPmV4ZXJjaXNlIHNob3VsZCBu b3QgaGF2ZSBhbnkgcHJhY3RpY2FsIGNvbnNlcXVlbmNlcyBvbiB3aGF0IGtleSBzaXplcw0KPiA+ eW91IHVzZS4gT25lIHNob3VsZCBmb2N1cyBvbiBzZWxlY3RpbmcgYXBwcm9wcmlhdGUgc2VjdXJp dHkgbGV2ZWwgZm9yDQo+ID5lYWNoIGFsZ29yaXRobS4gVG9kYXkgQUVTLTEyOCBhbmQgUlNBLTIw NDggd2lsbCBwcm9iYWJseSBtYWtlDQo+ID5pbXBsZW1lbnRhdGlvbiBidWdzIHRoZSB3ZWFrZXN0 IGxpbmsgZm9yIHRoZSBtYWpvcml0eSBvZiB1c2Vycy4NCj4gDQo+IFRoYW5rcyBmb3IgYWxsIHRo ZSByZXNwb25zZXMuIEkgdGhpbmsgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIGEgYmV0dGVyIHdheSBv ZiBkZXNjcmliaW5nIHdoYXQgSSBtZWFudCBhbmQgd2h5IEkgd2FzIGFza2luZzoNCj4gDQo+IFdl IGhhdmUgYSBjdXN0b21lciB0aGF0IG1hbmRhdGVkIHRoYXQgd2UgdXRpbGl6ZSBBRVMtMjU2IGZv ciB0aGUNCj4gc3ltbWV0cmljIGVuY3J5cHRpb24ga2V5cyB1c2VkIG9uIG91ciBUTFMgc2Vzc2lv bnMsIHNvIHdlIGhhdmUNCj4gY29tcGxpZWQsIGFuZCB0aGlzIHdvcmtzIGZpbmUuIExvb2tpbmcg YXQgaW1wbGVtZW50YXRpb24gZGV0YWlscw0KPiBmcm9tIHRoZSBjdXN0b21lciwgSSBmb3VuZCB0 aGF0IHRoZXkgYXJlIHVzaW5nIHN0YXRpYyBYLjUwOXYzDQo+IGNlcnRpZmljYXRlcyAoQ0EgaXNz dWVkKSwgd2hlcmUgdGhlIHB1YmxpYyBrZXkgc2l6ZSBpcyBvbmx5IDEwMjQNCj4gYml0cy4NCj4g DQo+IFRoZXJlZm9yZSwgaW4gbXkgbWluZCwgdGhleSBhcmUgZ2V0dGluZyBhIGZhbHNlIHNlbnNl IG9mIHNlY3VyaXR5DQo+IGZyb20gdXNpbmcgQUVTLTI1NiBhcyB0aGUgdW5kZXJseWluZyBzdHJl bmd0aCBvZiB0aGUgd2hvbGUgVExTDQo+IHNlc3Npb24gaXMgZGV0ZXJtaW5lZCBieSB0aGUgd2Vh a2VzdCBwb2ludCAtIGluIHRoaXMgY2FzZSB0aGUgMTAyNA0KPiBiaXQgUlNBIGtleXMsIHdoaWNo IE5JU1Qgc3RhdGUgdG8gYmUgZXF1aXZhbGVudCB0byAiODAtYml0cyIgW3doZW4NCj4gY29tcGFy ZWQgdG8gYSBzeW1tZXRyaWMgY2lwaGVyIEkgZ3Vlc3NdLg0KDQpTdXJlLCBidXQgdGhleSdyZSBn ZXR0aW5nIGEgZmFsc2Ugc2Vuc2Ugb2Ygc2VjdXJpdHkgZnJvbSBBRVMtMjU2DQphcyB3ZWxsLiBM ZXQncyBzYXkgZm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50IHRoYXQgeW91IGhhZA0KYSBzeXN0ZW0g dGhhdCB1c2VkIHN0YXRpYywgcmFuZG9tbHkgZ2VuZXJhdGVkIDI1Ni1iaXQgQUVTDQprZXlzLiBE byB5b3UgcmVhbGx5IHRoaW5rIHRoYXQncyAyXnsxMjh9IHRpbWVzIG1vcmUgc2VjdXJlDQp0aGFu IG9uZSB0aGF0IHVzZXMgMTI4LWJpdCBBRVM/DQoNCg0KPiBTbywgSSB3b3VsZCB3YW50IHRvIHJl Y29tbWVuZCB0byB0aGUgY3VzdG9tZXIgdGhhdCBpZiB0aGV5IHdhbnQgYQ0KPiBtb3JlIHNlY3Vy ZSBUTFMgc2Vzc2lvbiwgdGhlbiB0aGV5IG5lZWQgdG8gaW5jcmVhc2UgdGhlIFJTQSBrZXkNCj4g c2l6ZXMgdG8gIm1hdGNoIiB0aGUgc3ltbWV0cmljIGtleSBzdHJlbmd0aCwgYXMgdGhlIG92ZXJh bGwgc2VjdXJpdHkNCj4gJ3N0cmVuZ3RoJyBvZiB0aGVpciBUTFMgc2Vzc2lvbnMgY29tZXMgZG93 biB0byB0aGVpciBSU0Ega2V5IHNpemUNCj4gW2FzIGl0J3MgbG93ZXIgY29tcGFyYWJseSB0byBB RVMtMjU2XS4NCj4gDQo+IERvZXMgdGhpcyBzZWVtIHJlYXNvbmFibGUgYW5kIG1ha2UgbW9yZSBz ZW5zZSB0aGFuIG15IG9yaWdpbmFsIHF1ZXN0aW9uPw0KDQpJdCBtYWtlcyBtb3JlIHNlbnNlIHRv IHNheSB5b3UgbmVlZCBhIGJpZ2dlciBSU0Ega2V5LCBidXQgSU1PDQp0aGUgIm1hdGNoIiB0aGlu ZyBpcyB0aGUgd3Jvbmcgd2F5IHRvIGxvb2sgYXQgaXQuIFJhdGhlciwgeW91DQpzaG91bGQgZGVj aWRlIG9uIHlvdXIgbWluaW11bSBzZWN1cml0eSBsZXZlbCBhbmQgY2hvb3NlIGFsZ29yaXRobXMN CnRoYXQgc3VwcG9ydCB0aGF0LiBJIGRvbid0IHRoaW5rIGhhdmluZyB0aGVtIG1hdGNoIGlzIHBh cnRpY3VsYXJseQ0KaW50ZXJlc3Rpbmcgb25jZSB3ZSdyZSBhdCB0aGUgcG9pbnQgd2hlcmUgdGhl cmUgaXMgbm8gcGxhdXNpYmxlDQpub24tYW5hbHl0aWMgYXR0YWNrIG9uIHRoZSBhbGdvcml0aG0u DQoNCi1Fa3INCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQo= From ekr@networkresonance.com Wed Apr 22 06:42:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB643A6CF1 for ; Wed, 22 Apr 2009 06:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNvbChk8Q0k6 for ; Wed, 22 Apr 2009 06:42:54 -0700 (PDT) Received: from kilo.networkresonance.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 21F4328C172 for ; Wed, 22 Apr 2009 06:42:54 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C58A718852A; Wed, 22 Apr 2009 06:46:27 -0700 (PDT) Date: Wed, 22 Apr 2009 06:46:27 -0700 From: Eric Rescorla To: "Blumenthal, Uri" In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090422134627.C58A718852A@kilo.networkresonance.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 13:42:55 -0000 At Wed, 22 Apr 2009 09:24:26 -0400, Blumenthal, Uri wrote: > > Eric, > > I disagree. You're mixing together two orthogonal issues: security > of algorithms and security of implementation. > > NIST recommends that algorithms in a cipher suite are of comparable > strength. That includes relative key length. I appreciate that NIST recommends this. I think it's silly. It doesn't get any less silly because it's typeset in cool FIPS formatting. > The fact that despite of using secure algorithms your implementation > still can have exploitable bugs (that nullify the benefits of > cryptography) is 100% irrelevant to the issue of selecting > algorithms and their parameters. I don't agree that that's true, but in any case it's not what I'm saying. The amount of computational power required to break a 128-bit AES key with current is so outlandishly large that there is plausible scenario that such a key will be broken by brute force. The only plausible situations in which 128-bit AES keys are breakable, then, are non-brute-force attacks such as attacks on the implementation or an analytic attack. In neither case does 2^{128} represent an accurate estimate of the security of the algorithm, nor is there any reason to believe that AES-256 is 2^{128} times more secure under such attacks. Thus, the inference that one ought to use an RSA key that is 2^{128} times stronger with AES-256 than AES-128 also does not follow. -Ekr From dean@av8.com Wed Apr 22 06:48:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090043A6C20 for ; Wed, 22 Apr 2009 06:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzkMqoy6XMnV for ; Wed, 22 Apr 2009 06:48:45 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id D908B3A6803 for ; Wed, 22 Apr 2009 06:48:44 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n3MDo0Hr029060 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 22 Apr 2009 09:50:01 -0400 Date: Wed, 22 Apr 2009 09:50:00 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: tls@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Subject: Re: [TLS] [Ietf-honest] Multi-Threaded Applications over TLS (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 13:48:46 -0000 FYI, ---------- Forwarded message ---------- Date: Wed, 22 Apr 2009 09:47:44 -0400 (EDT) From: Dean Anderson To: Alessandro Vesely Cc: ietf-honest@lists.iadl.org Subject: Re: [Ietf-honest] [TLS] Multi-Threaded Applications over TLS (fwd) This was announced on TLS, too. I am greatly disappointed. There is a IPR Disclosure 1136 https://datatracker.ietf.org/ipr/1136/ that is related. The license terms aren't mutually defensive, and so I have to withdraw my support and oppose this draft. This is really too bad, since the notion of multiplexing is already defined, as someone pointed out, in RFC1692 TMux protocol. So it seems to me the patent shouldn't survive the prior art. --Dean On Wed, 22 Apr 2009, Alessandro Vesely wrote: > Dean Anderson wrote: > > This is a wonderful proposal for multiplexing that I think would be > > useful for HTTP and perhaps other protocols. Its a very neat little > > channel protocol. I don't think we should miss it. > > http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt > > [...] > > Is there somewhere else this could be used? If anyone has suggestions on > > how to utilize Badra's idea, I think it would be appreciated. Some have > > suggested that VPNs might also be able to take advantage of this > > proposal. > > I'm not sure what's the advantage, since the "Method of setting up > virtual private networks and remote access control" is patent > encumbered, according to > http://v3.espacenet.com/publicationDetails/biblio?CC=EP&NR=1858224 > > According to https://datatracker.ietf.org/ipr/1137/ that applies to > badra-tls-multiplexing, and according to the previous record /1136/, > "Ineovation is willing to negotiate licenses with interested parties > to such patent rights." It is not clear if each interested party > should start a separate negotiation or if that could be done "à > travers une seule session sécurisée établie entre un client et un > serveur". That is to say, if the IETF or other ISOC body would acquire > a grant so that people who develop and use (free) software that is > deemed useful for the Internet can employ patent encumbered protocols > promoted by the IETF under any open source license they choose. That > would be useful multiplexing! > > > _______________________________________________ > Ietf-honest mailing list > Ietf-honest@lists.iadl.org > http://lists.iadl.org/mailman/listinfo/ietf-honest > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From smb@cs.columbia.edu Wed Apr 22 07:00:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C42B28C514 for ; Wed, 22 Apr 2009 07:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95-jj-g399M7 for ; Wed, 22 Apr 2009 07:00:12 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 6C77428C511 for ; Wed, 22 Apr 2009 07:00:12 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id EBAFB328725; Wed, 22 Apr 2009 14:01:26 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4785E328723; Wed, 22 Apr 2009 14:01:25 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 90BAD2982E4; Wed, 22 Apr 2009 10:01:23 -0400 (EDT) Date: Wed, 22 Apr 2009 10:01:23 -0400 From: "Steven M. Bellovin" To: Eric Rescorla Message-ID: <20090422100123.4bc39978@cs.columbia.edu> In-Reply-To: <20090422134627.C58A718852A@kilo.networkresonance.com> References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 14:00:13 -0000 On Wed, 22 Apr 2009 06:46:27 -0700 Eric Rescorla wrote: > The amount of computational power required to break a 128-bit AES > key with current is so outlandishly large that there is plausible > scenario that such a key will be broken by brute force. The > only plausible situations in which 128-bit AES keys are breakable, > then, are non-brute-force attacks such as attacks on the > implementation or an analytic attack. In neither case does 2^{128} > represent an accurate estimate of the security of the algorithm, nor > is there any reason to believe that AES-256 is 2^{128} times more > secure under such attacks. Thus, the inference that one ought to > use an RSA key that is 2^{128} times stronger with AES-256 than > AES-128 also does not follow. > Two points... First, it may be a question of future-proofing: will someone find a new cryptanalytic attack on AES-128 in the next, say, 20 years? (You have, I assume, arranged for remote deletion of all of the surreptitious copies of your DES-protected conversations from 20 years ago, right?) Second, 1024-bit RSA is a much weaker link than 128-bit AES *today* -- they should switch to 2048- or 3072-bit RSA even if they stick with 128-bit AES. --Steve Bellovin, http://www.cs.columbia.edu/~smb From ekr@networkresonance.com Wed Apr 22 07:10:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4CD3A6803 for ; Wed, 22 Apr 2009 07:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1tv0abqtiOE for ; Wed, 22 Apr 2009 07:10:46 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8CB3828C52C for ; Wed, 22 Apr 2009 07:10:37 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 4E310188553; Wed, 22 Apr 2009 07:14:11 -0700 (PDT) Date: Wed, 22 Apr 2009 07:14:11 -0700 From: Eric Rescorla To: "Steven M. Bellovin" In-Reply-To: <20090422100123.4bc39978@cs.columbia.edu> References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090422100123.4bc39978@cs.columbia.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090422141411.4E310188553@kilo.networkresonance.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 14:10:47 -0000 At Wed, 22 Apr 2009 10:01:23 -0400, Steven M. Bellovin wrote: > > On Wed, 22 Apr 2009 06:46:27 -0700 > Eric Rescorla wrote: > > > The amount of computational power required to break a 128-bit AES > > key with current is so outlandishly large that there is plausible > > scenario that such a key will be broken by brute force. The > > only plausible situations in which 128-bit AES keys are breakable, > > then, are non-brute-force attacks such as attacks on the > > implementation or an analytic attack. In neither case does 2^{128} > > represent an accurate estimate of the security of the algorithm, nor > > is there any reason to believe that AES-256 is 2^{128} times more > > secure under such attacks. Thus, the inference that one ought to > > use an RSA key that is 2^{128} times stronger with AES-256 than > > AES-128 also does not follow. > > > Two points... First, it may be a question of future-proofing: will > someone find a new cryptanalytic attack on AES-128 in the next, say, 20 > years? (You have, I assume, arranged for remote deletion of all of the > surreptitious copies of your DES-protected conversations from 20 years > ago, right?) I agree with this claim. But I don't think it supports the "matching" argument particularly well. I.e., we don't really have any idea of how relatively strong AES-256 and ECC-512 (for instance) will be under some new analytic method. > Second, 1024-bit RSA is a much weaker link than 128-bit AES *today* -- > they should switch to 2048- or 3072-bit RSA even if they stick with > 128-bit AES. This I only sort of agree with: symmetric algorithms come in relatively rough granularity. If I was happy with 80 bits of security (which is apparently what NIST claims for RSA-1024, though I've also heard 72), then there's no good reason to make my PK much slower just b/c NIST has declined to give me an 80-bit algorithm. -Ekr From smb@cs.columbia.edu Wed Apr 22 07:21:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACB63A6D39 for ; Wed, 22 Apr 2009 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyO9SxxrD1nW for ; Wed, 22 Apr 2009 07:21:39 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id CD8FD28C511 for ; Wed, 22 Apr 2009 07:21:19 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 85C7C328C1E; Wed, 22 Apr 2009 14:22:34 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3021B3286ED; Wed, 22 Apr 2009 14:22:33 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id ED73529841D; Wed, 22 Apr 2009 10:22:30 -0400 (EDT) Date: Wed, 22 Apr 2009 10:22:30 -0400 From: "Steven M. Bellovin" To: Eric Rescorla Message-ID: <20090422102230.0f29cf54@cs.columbia.edu> In-Reply-To: <20090422141411.4E310188553@kilo.networkresonance.com> References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090422100123.4bc39978@cs.columbia.edu> <20090422141411.4E310188553@kilo.networkresonance.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 14:21:40 -0000 On Wed, 22 Apr 2009 07:14:11 -0700 Eric Rescorla wrote: > > Second, 1024-bit RSA is a much weaker link than 128-bit AES *today* > > -- they should switch to 2048- or 3072-bit RSA even if they stick > > with 128-bit AES. > > This I only sort of agree with: symmetric algorithms come in > relatively rough granularity. If I was happy with 80 bits of > security (which is apparently what NIST claims for RSA-1024, > though I've also heard 72), then there's no good reason > to make my PK much slower just b/c NIST has declined to > give me an 80-bit algorithm. > Assuming, of course, that people realized how weak 1024-bit RSA is, you're right. Did people realize that? *Do* people realize it? When I look at the number of CA certs in my browser that use 1024-bit keys, I worry... --Steve Bellovin, http://www.cs.columbia.edu/~smb From Michael.G.Williams@nokia.com Wed Apr 22 07:43:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39B83A6D6A for ; Wed, 22 Apr 2009 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvR-SbchDIF7 for ; Wed, 22 Apr 2009 07:43:23 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 688303A6F14 for ; Wed, 22 Apr 2009 07:43:23 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3MEiJp0001829; Wed, 22 Apr 2009 17:44:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 17:44:28 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 17:44:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 17:44:22 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 22 Apr 2009 16:44:22 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Wed, 22 Apr 2009 16:44:11 +0200 From: To: , Date: Wed, 22 Apr 2009 16:44:06 +0200 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDVeLJNiWn+iPoT0mVmdmAF92AUwAAk+Ig Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090422100123.4bc39978@cs.columbia.edu> <20090422141411.4E310188553@kilo.networkresonance.com> <20090422102230.0f29cf54@cs.columbia.edu> In-Reply-To: <20090422102230.0f29cf54@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2009 14:44:22.0843 (UTC) FILETIME=[D36CC8B0:01C9C358] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 14:43:24 -0000 Just FYI, in IEEE 802 there was a lengthy discussion to try and reach a sho= rthand way of expressing the relative strength of each suite as expressed i= n the NIST lists. The shorthand was to be used in a network information IE,= and in mobile device policy when evaluating which networks to attach to. N= o conclusion on how to do it was reached, so that approach was abandoned. Kind Regards, Michael -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext S= teven M. Bellovin Sent: 22 April, 2009 07:23 To: Eric Rescorla Cc: 'tls@ietf.org' Subject: Re: [TLS] Comparative cipher suite strengths On Wed, 22 Apr 2009 07:14:11 -0700 Eric Rescorla wrote: > > Second, 1024-bit RSA is a much weaker link than 128-bit AES *today* > > -- they should switch to 2048- or 3072-bit RSA even if they stick=20 > > with 128-bit AES. >=20 > This I only sort of agree with: symmetric algorithms come in=20 > relatively rough granularity. If I was happy with 80 bits of security=20 > (which is apparently what NIST claims for RSA-1024, though I've also=20 > heard 72), then there's no good reason to make my PK much slower just=20 > b/c NIST has declined to give me an 80-bit algorithm. >=20 Assuming, of course, that people realized how weak 1024-bit RSA is, you're = right. Did people realize that? *Do* people realize it? When I look at t= he number of CA certs in my browser that use 1024-bit keys, I worry... --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________= ________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From uri@ll.mit.edu Wed Apr 22 08:12:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1073A67BD for ; Wed, 22 Apr 2009 08:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIaEZ+CZHUkn for ; Wed, 22 Apr 2009 08:12:19 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id B69EE3A6921 for ; Wed, 22 Apr 2009 08:12:19 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MFDZAJ026435 for ; Wed, 22 Apr 2009 11:13:35 -0400 (EDT) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdBAAPJay0f; Wed Apr 22 10:58:20 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 10:58:14 -0400 From: "Blumenthal, Uri" To: "tls@ietf.org" Date: Wed, 22 Apr 2009 10:58:07 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDUHdFJ2LSLZX5Scqa3uDCJK5DYQACkdlB Message-ID: In-Reply-To: <20090422134627.C58A718852A@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C614A8BF418Aurillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 15:12:26 -0000 --_000_C614A8BF418Aurillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> I disagree. You're mixing together two orthogonal issues: security >> of algorithms and security of implementation. >> >> NIST recommends that algorithms in a cipher suite are of comparable >> strength. That includes relative key length. > > I appreciate that NIST recommends this. I think it's silly. > It doesn't get any less silly because it's typeset in cool > FIPS formatting. And I think it makes a perfect sense. It lowers the likelihood of people b= uilding tents with steel doors. We both are entitled to our opinions - but the way cryptographers in all th= e places (academy, industry, etc) go suggests more weight on my side of the= argument. (I know you're going to say that in my analogy the implementatio= n quality is that tent - so see below.) >> The fact that despite of using secure algorithms your implementation >> still can have exploitable bugs (that nullify the benefits of >> cryptography) is 100% irrelevant to the issue of selecting >> algorithms and their parameters. > > I don't agree that that's true, but in any case it's not what I'm saying. >From cryptography point of view it is true to a very large extent. The fact= that there are attacks directed against implementations (DFA, etc) does no= t reduce the importance of "pure math" algorithm study. But see below. > The amount of computational power required to break a 128-bit AES > key with current is so outlandishly large that there is no plausible > scenario that such a key will be broken by brute force. The > only plausible situations in which 128-bit AES keys are breakable, > then, are non-brute-force attacks such as attacks on the implementation > or an analytic attack. Yes, so? Until we learned about differential cryptanalysis we assumed that = DES was 2^56 strong. Once we learned of that attack, we dropped our estimat= ed strength to 2^47, then to 2^42... And then 2^56 became breakable by brut= e force. So...? For now AES-128 is 2^128 strong - feel free to prove otherw= ise. > In neither case does 2^{128} represent > an accurate estimate of the security of the algorithm, nor is > there any reason to believe that AES-256 is 2^{128} times more > secure under such attacks. Thus, the inference that one ought to > use an RSA key that is 2^{128} times stronger with AES-256 than > AES-128 also does not follow. The above is cryptographically incorrect. True, we can't know for sure that= AES-128 has 2^128 strength against analytical attack, though at this time = it appears so (as implementation attacks are out of scope for this discussi= on). We don't know for sure that AES-256 is 2^128 stronger than AES-128 eit= her. It is simply impossible to prove (given the current state of the scien= ce), as you well know. (Needless to say you can't prove at this time that i= t is less strong either.) But until there are tangible reasons to assume otherwise - we go by the exi= sting evidence that suggests 2^128 strength for AES-128, and 2^256 for AES-= 256 correspondingly. So the inference follows directly that we use equivale= nt (ballpark!) key strength for RSA and ECC. The practical question becomes - what peer algorithms to choose for the sui= te based on AES-256. I say use NIST guidelines - and at the very least you = won't get sued for negligence (in that area :-). Also, keep in mind that there is no exact matching of the key strength - on= ly the ballpark. -- Regards, Uri --_000_C614A8BF418Aurillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Comparative cipher suite strengths
>> I disagree. You're mixing together two orthogo= nal issues: security
>> of algorithms and security of implementation.
>>
>> NIST recommends that algorithms in a cipher suite are of comparabl= e
>> strength. That includes relative key length.
>
> I appreciate that NIST recommends this. I think it's silly.
> It doesn't get any less silly because it's typeset in cool
> FIPS formatting.


>> The fact that despite of using secure algorithms your implementati= on
>> still can have exploitable bugs (that nullify the benefits of
>> cryptography) is 100% irrelevant to the issue of selecting
>> algorithms and their parameters.
>
> I don't agree that that's true, but in any case it's not what I'm sayi= ng.


> The amount of computational power required to break a 128-bit AES
> key with current is so outlandishly large that there is no plausible > scenario that such a key will be broken by brute force. The
> only plausible situations in which 128-bit AES keys are breakable,
> then, are non-brute-force attacks such as attacks on the implementatio= n
> or an analytic attack.


> In neither case does 2^{128} represent
> an accurate estimate of the security of the algorithm, nor is
> there any reason to believe that AES-256 is 2^{128} times more
> secure under such attacks. Thus, the inference that one ought to
> use an RSA key that is 2^{128} times stronger with AES-256 than
> AES-128 also does not follow.


 MIME-Version: 1.0 X-Mailer: Evolution 2.24.3 Subject: [TLS] TLS1.2 PRF test vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 15:42:28 -0000 --=-9/G4c7HE0uEcUDIl/ZOB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Greetings, I have failed to find any published test vectors for this algorithm, or any implementation to test against. Therefore I've generated some in the hope that somebody can agree with or dispute my results. I've covered all hash functions from the SHA-2 family. Thanks, -- Joseph Birr-Pixton Senior Software Engineer THALES Information Systems Security nCipher Product Line ------------------------------------------------------- E: jbp@ncipher.com W: http://www.ncipher.com/ nCipher Corporation Limited is incorporated in England and Wales with compa= ny registration number 3169278. Its registered office is located at Jupiter= House, Station Road, Cambridge, Cambs, CB1 2JD. The information contained in this e-mail is confidential. It may also be pr= ivileged. It is only intended for the stated addressee(s) and access to it = by any other person is unauthorised. If you are not an addressee or the int= ended addressee, you must not disclose, copy, circulate or in any other way= use or rely on the information contained in this e-mail. Such unauthorised= use may be unlawful. If you have received this e-mail in error please dele= te it (and all copies) from your system, please also inform us immediately = on +44 (0)1223 723600 or email sales@ncipher.com. Commercial matters detail= ed or referred to in this e-mail are subject to a written contract signed f= or and on behalf of nCipher Corporation Limited. --=-9/G4c7HE0uEcUDIl/ZOB Content-Disposition: attachment; filename="tls1.2-prf-test-vectors.txt" Content-Type: text/plain; name="tls1.2-prf-test-vectors.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit # Generating 88 bytes of pseudo-randomness using TLS1.2PRF-SHA224 Secret (16 bytes): 0000 e1 88 28 74 03 52 b5 30 ...t.R.0 0008 d6 9b 34 c6 59 7d ea 2e ..4.Y... Seed (16 bytes): 0000 f5 a3 fe 6d 34 e2 e2 85 ...m4... 0008 60 fd ca f6 82 3f 90 91 ........ Label (10 bytes): 0000 74 65 73 74 20 6c 61 62 test lab 0008 65 6c el Output (88 bytes): 0000 22 4d 8a f3 c0 45 33 93 .M...E3. 0008 a9 77 97 89 d2 1c f7 da .w...... 0010 5e e6 2a e6 b6 17 87 3d ........ 0018 48 94 28 ef c8 dd 58 d1 H.....X. 0020 56 6e 70 29 e2 ca 3a 5e Vnp..... 0028 cd 35 5d c6 4d 4d 92 7e .5..MM.. 0030 2f bd 78 c4 23 3e 86 04 ..x..... 0038 b1 47 49 a7 7a 92 a7 0f .GI.z... 0040 dd f6 14 bc 0d f6 23 d7 ........ 0048 98 60 4e 4c a5 51 27 94 ..NL.Q.. 0050 d8 02 a2 58 e8 2f 86 cf ...X.... # Generating 100 bytes of pseudo-randomness using TLS1.2PRF-SHA256 Secret (16 bytes): 0000 9b be 43 6b a9 40 f0 17 ..Ck.... 0008 b1 76 52 84 9a 71 db 35 .vR..q.5 Seed (16 bytes): 0000 a0 ba 9f 93 6c da 31 18 ....l.1. 0008 27 a6 f7 96 ff d5 19 8c ........ Label (10 bytes): 0000 74 65 73 74 20 6c 61 62 test lab 0008 65 6c el Output (100 bytes): 0000 e3 f2 29 ba 72 7b e1 7b ....r... 0008 8d 12 26 20 55 7c d4 53 ... U..S 0010 c2 aa b2 1d 07 c3 d4 95 ........ 0018 32 9b 52 d4 e6 1e db 5a 2.R....Z 0020 6b 30 17 91 e9 0d 35 c9 k0....5. 0028 c9 a4 6b 4e 14 ba f9 af ..kN.... 0030 0f a0 22 f7 07 7d ef 17 ........ 0038 ab fd 37 97 c0 56 4b ab ..7..VK. 0040 4f bc 91 66 6e 9d ef 9b O..fn... 0048 97 fc e3 4f 79 67 89 ba ...Oyg.. 0050 a4 80 82 d1 22 ee 42 c5 ......B. 0058 a7 2e 5a 51 10 ff f7 01 ..ZQ.... 0060 87 34 7b 66 .4.f # Generating 196 bytes of pseudo-randomness using TLS1.2PRF-SHA512 Secret (16 bytes): 0000 b0 32 35 23 c1 85 35 99 .25...5. 0008 58 4d 88 56 8b bb 05 eb XM.V.... Seed (16 bytes): 0000 d4 64 0e 12 e4 bc db fb .d...... 0008 43 7f 03 e6 ae 41 8e e5 C....A.. Label (10 bytes): 0000 74 65 73 74 20 6c 61 62 test lab 0008 65 6c el Output (196 bytes): 0000 12 61 f5 88 c7 98 c5 c2 .a...... 0008 01 ff 03 6e 7a 9c b5 ed ...nz... 0010 cd 7f e3 f9 4c 66 9a 12 ....Lf.. 0018 2a 46 38 d7 d5 08 b2 83 .F8..... 0020 04 2d f6 78 98 75 c7 14 ...x.u.. 0028 7e 90 6d 86 8b c7 5c 45 ..m....E 0030 e2 0e b4 0c 1c f4 a1 71 .......q 0038 3b 27 37 1f 68 43 25 92 ..7.hC.. 0040 f7 dc 8e a8 ef 22 3e 12 ........ 0048 ea 85 07 84 13 11 bf 68 .......h 0050 65 3d 0c fc 40 56 d8 11 e....V.. 0058 f0 25 c4 5d df a6 e6 fe ........ 0060 c7 02 f0 54 b4 09 d6 f2 ...T.... 0068 8d d0 a3 23 3e 49 8d a4 .....I.. 0070 1a 3e 75 c5 63 0e ed be ..u.c... 0078 22 fe 25 4e 33 a1 b0 e9 ...N3... 0080 f6 b9 82 66 75 be c7 d0 ...fu... 0088 1a 84 56 58 dc 9c 39 75 ..VX..9u 0090 45 40 1d 40 b9 f4 6c 7a E.....lz 0098 40 0e e1 b8 f8 1c a0 a6 ........ 00a0 0d 1a 39 7a 10 28 bf f5 ..9z.... 00a8 d2 ef 50 66 12 68 42 fb ..Pf.hB. 00b0 8d a4 19 76 32 bd b5 4f ...v2..O 00b8 f6 63 3f 86 bb c8 36 e6 .c....6. 00c0 40 d4 d8 98 .... # Generating 148 bytes of pseudo-randomness using TLS1.2PRF-SHA384 Secret (16 bytes): 0000 b8 0b 73 3d 6c ee fc dc ..s.l... 0008 71 56 6e a4 8e 55 67 df qVn..Ug. Seed (16 bytes): 0000 cd 66 5c f6 a8 44 7d d6 .f...D.. 0008 ff 8b 27 55 5e db 74 65 ...U..te Label (10 bytes): 0000 74 65 73 74 20 6c 61 62 test lab 0008 65 6c el Output (148 bytes): 0000 7b 0c 18 e9 ce d4 10 ed ........ 0008 18 04 f2 cf a3 4a 33 6a .....J3j 0010 1c 14 df fb 49 00 bb 5f ....I... 0018 d7 94 21 07 e8 1c 83 cd ........ 0020 e9 ca 0f aa 60 be 9f e3 ........ 0028 4f 82 b1 23 3c 91 46 a0 O.....F. 0030 e5 34 cb 40 0f ed 27 00 .4...... 0038 88 4f 9d c2 36 f8 0e dd .O..6... 0040 8b fa 96 11 44 c9 e8 d7 ....D... 0048 92 ec a7 22 a7 b3 2f c3 ........ 0050 d4 16 d4 73 eb c2 c5 fd ...s.... 0058 4a bf da d0 5d 91 84 25 J....... 0060 9b 5b f8 cd 4d 90 fa 0d ....M... 0068 31 e2 de c4 79 e4 f1 a2 1...y... 0070 60 66 f2 ee a9 a6 92 36 .f.....6 0078 a3 e5 26 55 c9 e9 ae e6 ...U.... 0080 91 c8 f3 a2 68 54 30 8d ....hT0. 0088 5e aa 3b e8 5e 09 90 70 .......p 0090 3d 73 e5 6f .s.o --=-9/G4c7HE0uEcUDIl/ZOB-- From dbrown@certicom.com Wed Apr 22 08:50:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23763A6D7A for ; Wed, 22 Apr 2009 08:50:09 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0eP4KdNmwP7 for ; Wed, 22 Apr 2009 08:50:09 -0700 (PDT) Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id D50793A6932 for ; Wed, 22 Apr 2009 08:50:08 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n3MFpC9h002526; Wed, 22 Apr 2009 11:51:18 -0400 Received: from EX41.exchserver.com ([10.7.40.62]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Wed, 22 Apr 2009 11:51:13 -0400 From: Daniel Brown To: Eric Rescorla , "Blumenthal, Uri" Date: Wed, 22 Apr 2009 11:51:10 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnDUHGRGfieZ70NTpeEFpiTCufU5AAEUAjQ Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> In-Reply-To: <20090422134627.C58A718852A@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 15:50:09 -0000 Eric, Are you saying that 2^128 computations will never be feasible, and therefor= e, that Moore's law will stop? Best regards, Dan -----Original Message----- From: Eric Rescorla Sent: Wednesday, April 22, 2009 9:46 AM To: Blumenthal, Uri Cc: 'tls@ietf.org' Subject: Re: [TLS] Comparative cipher suite strengths The amount of computational power required to break a 128-bit AES key with current is so outlandishly large that there is plausible scenario that such a key will be broken by brute force. The=20 only plausible situations in which 128-bit AES keys are breakable, then, are non-brute-force attacks such as attacks on the implementation or an analytic attack. In neither case does 2^{128} represent an accurate estimate of the security of the algorithm, nor is there any reason to believe that AES-256 is 2^{128} times more secure under such attacks. Thus, the inference that one ought to use an RSA key that is 2^{128} times stronger with AES-256 than AES-128 also does not follow. From Nicolas.Williams@sun.com Wed Apr 22 09:51:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E073A6D8A for ; Wed, 22 Apr 2009 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfJUiYPoNiaK for ; Wed, 22 Apr 2009 09:51:19 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 0988C28C267 for ; Wed, 22 Apr 2009 09:50:42 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3MGpxB8024571 for ; Wed, 22 Apr 2009 16:51:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3MGpxlK057841 for ; Wed, 22 Apr 2009 10:51:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MGgRp3016166; Wed, 22 Apr 2009 11:42:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MGgQwE016165; Wed, 22 Apr 2009 11:42:26 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 22 Apr 2009 11:42:26 -0500 From: Nicolas Williams To: carlyoung@keycomm.co.uk Message-ID: <20090422164226.GH1500@Sun.COM> References: <51912.1240398992@keycomm.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51912.1240398992@keycomm.co.uk> User-Agent: Mutt/1.5.7i Cc: TLS Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2009 16:51:20 -0000 On Wed, Apr 22, 2009 at 12:16:32PM +0100, carlyoung@keycomm.co.uk wrote: > Thanks for all the responses. I think the following text is a better > way of describing what I meant and why I was asking: > > We have a customer that mandated that we utilize AES-256 for the > symmetric encryption keys used on our TLS sessions, so we have > complied, and this works fine. Looking at implementation details from > the customer, I found that they are using static X.509v3 certificates > (CA issued), where the public key size is only 1024 bits. As you surmise the weak link in the chain then is the RSA key size. There's always going to be a weak link, but there's no sense in making the other links stronger so far out of proportion to the weakest link. Either the customer should revise their requirement that AES-256 be used or they should deploy larger RSA keys. But even so, going whole hog to 15kbit key lengths is not really practical. Therefore I'd recommend raising the RSA key size to 2048. > So, I would want to recommend to the customer that if they want a more > secure TLS session, then they need to increase the RSA key sizes to > "match" the symmetric key strength, as the overall security 'strength' > of their TLS sessions comes down to their RSA key size [as it's lower > comparably to AES-256]. > > Does this seem reasonable and make more sense than my original question? Yes, but by my experience your customer's security policy people are not likely to agree or will be averse to any change. Here's how this sort of thing goes: SECURITY: the policy is (and "it's needed for SOX compliance") INTERNAL AUDIT: you're not doing what the policy requires YOU: the policy is stupid^H^H^H^H^H^Hbroken, here's why SECURITY: If you get past that you then run into other walls. E.g., say you convince the policy ppl that they should raise the RSA key size, but then the business people complain that performance sucks, or that deploying new certs will cost too much, so they ask their regulators for a waiver -- and then you're back at square one (the policy has changed but reality hasn't). See also Dilbert. Nico -- From paul.hoffman@vpnc.org Wed Apr 22 17:06:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE723A6EC9 for ; Wed, 22 Apr 2009 17:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPi2OvKGpvSH for ; Wed, 22 Apr 2009 17:06:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F15503A6768 for ; Wed, 22 Apr 2009 17:05:45 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N070UO018996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Apr 2009 17:07:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 22 Apr 2009 17:06:58 -0700 To: tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [TLS] Multi-Threaded Applications over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 00:06:43 -0000 At 5:36 PM +0200 4/21/09, Badra wrote: >It take one business day (I submitted it this morning) --Paul Hoffman, Director --VPN Consortium From pgut001@cs.auckland.ac.nz Wed Apr 22 23:37:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1543A67AE for ; Wed, 22 Apr 2009 23:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyPY+3rEMdCh for ; Wed, 22 Apr 2009 23:37:13 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 59C7C3A6945 for ; Wed, 22 Apr 2009 23:37:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3290B170851; Thu, 23 Apr 2009 18:38:28 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shnGPS1KNHhT; Thu, 23 Apr 2009 18:38:28 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 66E75170736; Thu, 23 Apr 2009 18:38:23 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7CC60E0808A; Thu, 23 Apr 2009 18:38:17 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LwsZd-0005N8-Bi; Thu, 23 Apr 2009 18:38:17 +1200 From: Peter Gutmann To: Nicolas.Williams@sun.com, pgut001@cs.auckland.ac.nz In-Reply-To: <20090421155800.GG1500@Sun.COM> Message-Id: Sender: pgut001 Date: Thu, 23 Apr 2009 18:38:17 +1200 Cc: tls@ietf.org Subject: Re: [TLS] SSH channel handbrake (Re: Multi-Threaded Applications over TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 06:37:15 -0000 Nicolas Williams writes: >I don't believe that handbrake exists other than as an implementation >artifact. I agree, it's purely an implementation artefact. On the other hand security bugs in software don't exist other than as implemetation artefacts either, but they're not going to go away if you ignore them. The problem in this case it's that it's a design for which the straightforward implementation (and even many not-so-straightforward ones) produce very bad performance, and you need a very carefully designed and coded implementation, and preferably the same one at both ends of the link, to avoid problems. >It's perfectly reasonable to have large channel windows, and even to grow the >channel windows so as to avoid having to ever wait for an ACK. No, that doens't work either, because my implementation does it and other implementations break in various unuusal ways once the window gets too large (there's a particular error message from OpenSSH which I can't recall at the moment that you can google for to see that other implementations run into the same problem). More implementation artefacts there. >The HPN OpenSSH patches don't make the window that dynamic, IIRC, but they do >make it dynamic and get better performance, thus proving the point. OTOH simply setting a huge-size window (assuming you don't run into one of the implementations that exhibit artefacts :-) has the same effect. The real problem though is that this is a fundamentally unsound design. If you put in a considerable amount of time and effort and whatever's at the other end has done the same and if you're lucky enough, it won't be so bad, but the default leads to quite poor performance. From the SSH experience, most implementations are going down the default path... Peter. From pgut001@cs.auckland.ac.nz Thu Apr 23 00:04:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8483028C68B for ; Thu, 23 Apr 2009 00:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT35vx1lj8z4 for ; Thu, 23 Apr 2009 00:04:56 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id A63883A6D9E for ; Thu, 23 Apr 2009 00:04:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C258F1BF2E; Thu, 23 Apr 2009 19:06:13 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOXynwAU7CE7; Thu, 23 Apr 2009 19:06:13 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 70A0D1BE81; Thu, 23 Apr 2009 19:06:11 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CDF59E0808A; Thu, 23 Apr 2009 19:06:10 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lwt0c-0006jy-La; Thu, 23 Apr 2009 19:06:10 +1200 From: Peter Gutmann To: carlyoung@keycomm.co.uk In-Reply-To: <51912.1240398992@keycomm.co.uk> Message-Id: Sender: pgut001 Date: Thu, 23 Apr 2009 19:06:10 +1200 Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 07:04:57 -0000 carlyoung@keycomm.co.uk writes: >Therefore, in my mind, they are getting a false sense of security from using >AES-256 as the underlying strength of the whole TLS session is determined by >the weakest point - in this case the 1024 bit RSA keys, which NIST state to >be equivalent to "80-bits" [when compared to a symmetric cipher I guess]. They're not getting any sense of security at all. They initially wanted a cipher with 128-bit encryption, because everyone knows that you have to have 128 bits to be Good. AES encryption has the required 128 thingies, so they went with that. Then someone pointed out that there's a version of AES with 256 thingies instead of 128, and if 128 is Good then 256 must be even Gooder. So the requirement was changed to use AES with 256 thingies. If there was an AES with 397 thingies they'd go with that instead, because it's obvious that that one's ever Gooderer than the one with 256 thingies. >So, I would want to recommend to the customer that if they want a more secure >TLS session, They don't want a more secure TLS session, they want bigger numbers after their algorithm name. So the optimal approach here would be to write a draft for a new TLS cipher suite using the McEliece cryptosystem, because then you can use numbers bigger than anyone else. Peter. From uri@ll.mit.edu Thu Apr 23 05:02:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FB63A71E3 for ; Thu, 23 Apr 2009 05:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOoMmR689XmM for ; Thu, 23 Apr 2009 05:02:05 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id C84773A71F1 for ; Thu, 23 Apr 2009 05:02:04 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3NC3Dl0021196 for ; Thu, 23 Apr 2009 08:03:13 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAA0XaqmA; Thu Apr 23 07:58:01 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 23 Apr 2009 07:58:01 -0400 From: "Blumenthal, Uri" To: "tls@ietf.org" Date: Thu, 23 Apr 2009 07:57:58 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnD4hmhdd/C4p5aTS+nqbcAVdTcjgAKKTG3 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C615D00641DEurillmitedu_" MIME-Version: 1.0 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 12:02:10 -0000 --_000_C615D00641DEurillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about this: US Government (yes, the one you seem to like rather less th= an the other governments) has declared that AES-128 can be used to protect = information up to SECRET level, and for TOP SECRET one must use AES-256. Ap= parently they weren't aware of Eric's views regarding the unnecessariness o= f 256 bits when you have a perfectly good 128-bit key-space, and can't trul= y-really guarantee the algorithm strength anyway. They did not mandate (nor even define) AES-397 or 398 as of yet, obviously = because crypto scientists who work for them are not as smart or sarcastic a= s we are here. So the optimal approach here would be to find out the real need of the cust= omer - for what purpose he's trying to go to a higher-level encryption stan= dard - and address it in practical matter (i.e. 15K RSA keys, while theoret= ically matching, are hardly usable in practice - so something bigger than 1= K or 2K, but still wield-able; or follow Suite B and use ECC - in that case= you can achieve the ballpark key size match between the algorithms). Though where that customer is going to get a reasonably bug-free implementa= tion is beyond me. I concede this point. You can also point out to your customer that AES-128 is indeed considered "= good enough" for most of the "normal" applications. But if he's already set= his encryption policy, you probably won't get very far. -- Regards, Uri On 4/23/09 03:06 , "Peter Gutmann" wrote: carlyoung@keycomm.co.uk writes: >Therefore, in my mind, they are getting a false sense of security from usi= ng >AES-256 as the underlying strength of the whole TLS session is determined = by >the weakest point - in this case the 1024 bit RSA keys, which NIST state t= o >be equivalent to "80-bits" [when compared to a symmetric cipher I guess]. They're not getting any sense of security at all. They initially wanted a cipher with 128-bit encryption, because everyone knows that you have to hav= e 128 bits to be Good. AES encryption has the required 128 thingies, so they went with that. Then someone pointed out that there's a version of AES with 256 thingies instead of 128, and if 128 is Good then 256 must be even Gooder. So the requirement was changed to use AES with 256 thingies. If there was an AES with 397 thingies they'd go with that instead, because it's obvious that that one's ever Gooderer than the one with 256 thingies. >So, I would want to recommend to the customer that if they want a more sec= ure >TLS session, They don't want a more secure TLS session, they want bigger numbers after their algorithm name. So the optimal approach here would be to write a dra= ft for a new TLS cipher suite using the McEliece cryptosystem, because then yo= u can use numbers bigger than anyone else. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_C615D00641DEurillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Comparative cipher suite strengths How about this: US Government (yes, the one you seem to like rather l= ess than the other governments) has declared that AES-128 can be used to pr= otect information up to SECRET level, and for TOP SECRET one must use AES-2= 56. Apparently they weren’t aware of Eric’s views regarding the= unnecessariness of 256 bits when you have a perfectly good 128-bit key-spa= ce, and can’t truly-really guarantee the algorithm strength anyway. <= BR>
They did not mandate (nor even define) AES-397 or 398 as of yet, obviously = because crypto scientists who work for them are not as smart or sarcastic a= s we are here.

So the optimal approach here would be to find out the real need of the cust= omer – for what purpose he’s trying to go to a higher-level enc= ryption standard – and address it in practical matter (i.e. 15K RSA k= eys, while theoretically matching, are hardly usable in practice – so= something bigger than 1K or 2K, but still wield-able; or follow Suite B an= d use ECC – in that case you can achieve the ballpark key size match = between the algorithms).  

Though where that customer is going to get a reasonably bug-free implementa= tion is beyond me. I concede this point.

You can also point out to your customer that AES-128 is indeed considered &= #8220;good enough” for most of the “normal” applications.= But if he’s already set his encryption policy, you probably won̵= 7;t get very far.
--
Regards,
Uri
<Disclaimer>


On 4/23/09  03:06 , "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote:

carlyou= ng@keycomm.co.uk writes:

>Therefore, in my mind, they are getting a false sense of security from = using
>AES-256 as the underlying strength of the whole TLS session is determin= ed by
>the weakest point - in this case the 1024 bit RSA keys, which NIST stat= e to
>be equivalent to "80-bits" [when compared to a symmetric ciph= er I guess].

They're not getting any sense of security at all.  They initially want= ed a
cipher with 128-bit encryption, because everyone knows that you have to hav= e
128 bits to be Good.  AES encryption has the required 128 thingies, so= they
went with that.

Then someone pointed out that there's a version of AES with 256 thingies instead of 128, and if 128 is Good then 256 must be even Gooder.  So t= he
requirement was changed to use AES with 256 thingies.

If there was an AES with 397 thingies they'd go with that instead, because<= BR> it's obvious that that one's ever Gooderer than the one with 256 thingies.<= BR>
>So, I would want to recommend to the customer that if they want a more = secure
>TLS session,

They don't want a more secure TLS session, they want bigger numbers after their algorithm name.  So the optimal approach here would be to write = a draft
for a new TLS cipher suite using the McEliece cryptosystem, because then yo= u
can use numbers bigger than anyone else.

Peter.


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

In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090423134052.21DB1188745@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 13:37:43 -0000 At Thu, 23 Apr 2009 07:57:58 -0400, Blumenthal, Uri wrote: > > [1 ] > [1.1 ] > How about this: US Government (yes, the one you seem to like rather > less than the other governments) has declared that AES-128 can be > used to protect information up to SECRET level, and for TOP SECRET > one must use AES-256. Apparently they weren't aware of Eric's views > regarding the unnecessariness of 256 bits when you have a perfectly > good 128-bit key-space, and can't truly-really guarantee the > algorithm strength anyway. > > They did not mandate (nor even define) AES-397 or 398 as of yet, > obviously because crypto scientists who work for them are not as > smart or sarcastic as we are here. I'm finding this argument from authority really pretty unconvincing. How is it that the same government which can't seem to efficiently conduct elections or clean up after Hurricane Katrina is suddenly infallible when it comes to crypto? Is it just because the message comes from Fort Meade or what? In any case, I'm not saying that AES-256 isn't more secure than AES-128. It probably is, if only because it has more rounds in 256-bit mode. What I'm saying is that there is no practical sense in which we can conclude it's 2^{128} times stronger. Either the best attack is brute force, in which case there's simply no plausible attack on AES-128, or it's not in which case who knows what the relative strengths of the algorithms are? -Ekr From ekr@networkresonance.com Thu Apr 23 06:52:58 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D3B3A6A69 for ; Thu, 23 Apr 2009 06:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drYB-xP47Nu6 for ; Thu, 23 Apr 2009 06:52:57 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id B254C3A71CD for ; Thu, 23 Apr 2009 06:52:57 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E17DF188780; Thu, 23 Apr 2009 06:56:38 -0700 (PDT) Date: Thu, 23 Apr 2009 06:56:38 -0700 From: Eric Rescorla To: Daniel Brown In-Reply-To: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090423135638.E17DF188780@kilo.networkresonance.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 13:52:58 -0000 At Wed, 22 Apr 2009 11:51:10 -0400, Daniel Brown wrote: > > Eric, > > Are you saying that 2^128 computations will never be feasible, and > therefore, that Moore's law will stop? I wasn't aware that that was a particularly controversial observation. Current computers, with feature sizes of about 50 nm (50 * 10^{-9} m) are just about fast enough to brute force a 64-bit key. So, in order for Moore's law (which, remember, is about feature size) to get us to 128-bit keys, the feature sizes would need to shrink to 50 * 10^{-9} * 2^{-64} ~= 50 * 10^{-28}. Given that hydrogen atoms are on the order of 10^{-10} m large, I don't think it's particularly safe to do a straight line extrapolation of Moore's law through 18 more orders of magnitude. Obviously, it's possible we'll learn how to construct computers with some entirely different technology (quarks!), but it's not like it's just a matter of giving Intel more money. -Ekr From dbrown@certicom.com Thu Apr 23 10:18:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D84428C751 for ; Thu, 23 Apr 2009 10:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhuUvMy2ifNu for ; Thu, 23 Apr 2009 10:18:52 -0700 (PDT) Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id 5070D28C754 for ; Thu, 23 Apr 2009 10:12:11 -0700 (PDT) Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n3NHD13j011541; Thu, 23 Apr 2009 13:13:25 -0400 Received: from EX41.exchserver.com ([10.7.40.62]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Thu, 23 Apr 2009 13:13:16 -0400 From: Daniel Brown To: Eric Rescorla Date: Thu, 23 Apr 2009 13:13:13 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnEGxMXdbGYn/VCT12hted6osobGgAFUaFQ Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090423135638.E17DF188780@kilo.networkresonance.com> In-Reply-To: <20090423135638.E17DF188780@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 17:18:53 -0000 NIST SP 800-57, Table 2, provides a list of comparable strengths, and Table= 4, provides a list of algorithm security lifetimes, which I liberally inte= rpret as saying 2^80 computations may be feasible for a concerted adversary= , in 2010 and perhaps 2^112 operations may be feasible by 2030. =20 Note that Table 4 does not differentiate the lifetimes 128, 192, or 256 sec= urity, in loose agreement with, and perhaps for similar reasons to, Eric's = argument that searching 2^128 keys will never be feasible. Furthermore, adapting Eric's calculations below, to brute force 112-bit key= s, assuming 80-bit keys are brute forcible today (let's just say with massi= ve distributed computing for the sake of example), feature sizes would need= to shrink to 50 * 10^{-9} * 2^{-32} =3D~ 1.16 * 10^{-17}, still smaller th= an a Hydrogen atom, but perhaps NIST was accounting for the possibility of = some future technical developments leading to continued or even accelerated= increase in processing power, or perhaps NIST was also accounting for some= degradation in the security of the TDEA aglorithm below that of a generic = block cipher, or perhaps NIST is just encouraging migration to AES.=20 That all said, personally, I'm still much more reluctant to predict a decre= ase in the growth of processing power that has been going fairly steady (?)= for some time. Therefore, data needing long term protection, say medical = information, is worth encrypting at a potentially higher security level, as= suming one has the processing power and a well-established encryption algor= ithm to do so. If Moore's law (liberally applied to processing power, not = just feature size) stops soon enough, then using the larger keys was at wor= st a waste of processing power, or at best, insurance. Best regards, Dan -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Thursday, April 23, 2009 9:57 AM To: Daniel Brown Cc: Eric Rescorla; Blumenthal, Uri; 'tls@ietf.org' Subject: Re: [TLS] Comparative cipher suite strengths At Wed, 22 Apr 2009 11:51:10 -0400, Daniel Brown wrote: >=20 > Eric, >=20 > Are you saying that 2^128 computations will never be feasible, and > therefore, that Moore's law will stop? I wasn't aware that that was a particularly controversial observation. Current computers, with feature sizes of about 50 nm (50 * 10^{-9} m) are just about fast enough to brute force a 64-bit key. So, in order for Moore's law (which, remember, is about feature size) to get us to 128-bit keys, the feature sizes would need to shrink to 50 * 10^{-9} * 2^{-64} ~=3D 50 * 10^{-28}. Given that hydrogen atoms are on the order of 10^{-10} m large, I don't think it's particularly safe to do a straight line extrapolation of Moore's law through 18 more orders of magnitude. Obviously, it's possible we'll learn how to construct computers with some entirely different technology (quarks!), but it's not like it's just a matter of giving Intel more money. -Ekr From paul.hoffman@vpnc.org Thu Apr 23 10:59:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A510A3A7002 for ; Thu, 23 Apr 2009 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMABBNIt67Y2 for ; Thu, 23 Apr 2009 10:59:22 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5183E3A7281 for ; Thu, 23 Apr 2009 10:59:08 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NI0Mj3091957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 11:00:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090423135638.E17DF188780@kilo.networkresonance.com> Date: Thu, 23 Apr 2009 11:00:20 -0700 To: Daniel Brown , Eric Rescorla From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 17:59:22 -0000 At 1:13 PM -0400 4/23/09, Daniel Brown wrote: >Table 4, provides a list of algorithm security lifetimes, That's your interpretation. NIST labels the table "Recommended algorithms and minimum key sizes", and precedes it with "Table 4 provides recommendations that may be used to select an appropriate suite of algorithms and key sizes for Federal Government unclassified applications." If you want to ignore that and call it "a list of algorithm security lifetimes", that's fine, but maybe don't attribute that interpretation to NIST without further backup. > >which I liberally interpret as saying 2^80 computations may be feasible for a concerted adversary, in 2010 and perhaps 2^112 operations may be feasible by 2030. See above. >... but perhaps NIST was ... or perhaps NIST was ... or perhaps NIST is ... Another possibility is to take NIST's words as what they intended to say. --Paul Hoffman, Director --VPN Consortium From dbrown@certicom.com Thu Apr 23 11:38:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9572428C133 for ; Thu, 23 Apr 2009 11:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7lh-uI-yn7S for ; Thu, 23 Apr 2009 11:38:02 -0700 (PDT) Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id A4C193A6E09 for ; Thu, 23 Apr 2009 11:38:02 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n3NIdCvg022496; Thu, 23 Apr 2009 14:39:13 -0400 Received: from EX41.exchserver.com ([10.7.40.62]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Thu, 23 Apr 2009 14:39:14 -0400 From: Daniel Brown To: Paul Hoffman , Eric Rescorla Date: Thu, 23 Apr 2009 14:39:12 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnEPYq8CgV3egfmTtSZ3bUkOZPxrQAAGb/g Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090423135638.E17DF188780@kilo.networkresonance.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: dbrown@certicom.com Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 18:38:03 -0000 Paul, Yes, I certainly ignored many parts of SP 800-57. I'm sorry about that. But I don't want to also ignore other parts of SP 800-57 (Revision, March 2= 007) such as Table 4 column heading: "Algorithm security lifetime", which a= lso appears in the Glossary defined as "The estimated time period during wh= ich data protected by a specific algorithm remains secure". Further on, SP= 800-57 makes requirements based on Table 4, "Algorithms or key sizes not i= ndicated for a given range of years shall not be used to protect informatio= n during that time period." (My personal interpretation of this is that 20= 48-bit FFC is not to be used for data needing protection beyond 2030 under = SP 800-56 compliance, but I could be completely wrong, and I have not found= a more direct quote to support this.) SP 800-57 does not provide rationale for this requirement, does it? Is it = unreasonable to speculate NIST's rationale, if only as a less dry way to di= scuss purely objective arguments, such as Eric's, about recommendations suc= h as Table 4, and their wider applicability to TLS users and people not bou= nd by SP 800-57 but who might appreciate following its guidance, especially= given the question about incomparable algorithm security levels over which= this thread began? Best regards, Dan -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Thursday, April 23, 2009 2:00 PM To: Daniel Brown; Eric Rescorla Cc: 'tls@ietf.org' Subject: Re: [TLS] Comparative cipher suite strengths At 1:13 PM -0400 4/23/09, Daniel Brown wrote: >Table 4, provides a list of algorithm security lifetimes, That's your interpretation. NIST labels the table "Recommended algorithms a= nd minimum key sizes", and precedes it with "Table 4 provides recommendatio= ns that may be used to select an appropriate suite of algorithms and key si= zes for Federal Government unclassified applications." If you want to ignor= e that and call it "a list of algorithm security lifetimes", that's fine, b= ut maybe don't attribute that interpretation to NIST without further backup= . > >which I liberally interpret as saying 2^80 computations may be feasible fo= r a concerted adversary, in 2010 and perhaps 2^112 operations may be feasib= le by 2030. See above. >... but perhaps NIST was ... or perhaps NIST was ... or perhaps NIST is ..= . Another possibility is to take NIST's words as what they intended to say. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Apr 23 12:04:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5390A28C72E for ; Thu, 23 Apr 2009 12:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpQI4LuYBXtO for ; Thu, 23 Apr 2009 12:04:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DB7FE28C2D4 for ; Thu, 23 Apr 2009 12:04:06 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NJ5JSJ096342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 12:05:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090423135638.E17DF188780@kilo.networkresonance.com> Date: Thu, 23 Apr 2009 12:05:18 -0700 To: Daniel Brown , Eric Rescorla From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 19:04:26 -0000 At 2:39 PM -0400 4/23/09, Daniel Brown wrote: >SP 800-57 does not provide rationale for this requirement, does it? Correct: it does not. It dances around the rationale in a few places, but does not give a specific rationale. >Is it unreasonable to speculate NIST's rationale, if only as a less dry way to discuss purely objective arguments, such as Eric's, about recommendations such as Table 4, and their wider applicability to TLS users and people not bound by SP 800-57 but who might appreciate following its guidance, especially given the question about incomparable algorithm security levels over which this thread began? I believe it is unreasonable, yes. NIST is a government bureaucracy with thousands of employees and an ever-changing management above them (and I say that in both the positive and negative senses). Attributing meaning to what they do beyond what they say their own stated reasoning means that you understand the bureaucracy and requirements they work under better than they do. --Paul Hoffman, Director --VPN Consortium From smb@cs.columbia.edu Thu Apr 23 12:04:29 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04F828C71F for ; Thu, 23 Apr 2009 12:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFW8TVWdz+HX for ; Thu, 23 Apr 2009 12:04:28 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 795433A68FB for ; Thu, 23 Apr 2009 12:04:09 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id E124232923E; Thu, 23 Apr 2009 19:05:17 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7A49D32923C; Thu, 23 Apr 2009 19:05:16 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 7455429830F; Thu, 23 Apr 2009 15:05:15 -0400 (EDT) Date: Thu, 23 Apr 2009 15:05:15 -0400 From: "Steven M. Bellovin" To: Eric Rescorla Message-ID: <20090423150515.1b202723@cs.columbia.edu> In-Reply-To: <20090423134052.21DB1188745@kilo.networkresonance.com> References: <20090423134052.21DB1188745@kilo.networkresonance.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 19:04:29 -0000 On Thu, 23 Apr 2009 06:40:51 -0700 Eric Rescorla wrote: > How is it that the same government which can't seem to efficiently > conduct elections or clean up after Hurricane Katrina is suddenly > infallible when it comes to crypto? Is it just because the message > comes from Fort Meade or what? Infallible? No, of course not. And no government has ever fielded a system that they knew the enemy could break -- and of course many governments have been wrong. That may include the NSA -- Heath's master's thesis concludes that the Soviets likely broke NSA's KW-7 encryptor circa 1970. (She also concluded that the Navy's key-handling practices were awful.) Recently declassified documents say that NSA started having great cryptanalytic success of its own against the Soviets in the late 1970s. But -- remember Biham, Biryukov, and Shamir's 2^78 impossible differential attack on 31-round Skipjack? 2^78 isn't an impressive result against an 80-bit cipher, and the attack could not be extended to the full 32 rounds in any case. But it was interesting that there was this slight improvement over brute force, so I brought it up in conversation with a friend who knows a fair amount about the subject. His comment? "A 2^78 attack against an 80-bit cipher? That's not an attack, that's good engineering." Maybe NSA really does understand this stuff that well... One more point: NSA may or may not be able to speak ex cathedra on strength; we'll never know. They have said publicly that they trust 256-bit AES a lot, and a lot more than they trust 128-bit AES. That statement is *completely* unprecedented. The really interesting question is this: what will NSA ever do, if they ever figure out how to crack AES-256? Officially decertify it for TS use, thereby telling the world they think it's no longer that strong? Let government agencies continue to use it, when they know it's breakable? That would be a great discussion to listen to.... > > In any case, I'm not saying that AES-256 isn't more secure than > AES-128. It probably is, if only because it has more rounds in > 256-bit mode. What I'm saying is that there is no practical sense in > which we can conclude it's 2^{128} times stronger. Either the best > attack is brute force, in which case there's simply no plausible > attack on AES-128, or it's not in which case who knows what the > relative strengths of the algorithms are? > Key length certainly isn't everything. A monoalphabetic substitution on all 256 byte values has a key length of 256!, or about 1684 bits, but it is of course trivially crackable. That said, there's always Whit Diffie's attitude: having extra key bits is cheap; why not use them if you can? Also, remember that many modern cryptanalytic techniques produce many key bits but not all, requiring a brute force search for the remainder. So -- for a situation like that, more key bits are definitely better, albeit by an imponderable amount. Final comment: the original poster was not asking if they should use AES-256; he was saying that they do use it, and should the RSA key size be increased. I think we can all agree on that. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Nicolas.Williams@sun.com Thu Apr 23 12:11:38 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C2D3A7287 for ; Thu, 23 Apr 2009 12:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8vUA6EbpOwK for ; Thu, 23 Apr 2009 12:11:37 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 97E9F3A68FB for ; Thu, 23 Apr 2009 12:11:37 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3NJCrM8019902 for ; Thu, 23 Apr 2009 19:12:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3NJCr1P042074 for ; Thu, 23 Apr 2009 13:12:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3NItpix017206; Thu, 23 Apr 2009 13:55:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3NItoef017205; Thu, 23 Apr 2009 13:55:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 23 Apr 2009 13:55:50 -0500 From: Nicolas Williams To: Daniel Brown Message-ID: <20090423185550.GW1500@Sun.COM> References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090423135638.E17DF188780@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 19:11:38 -0000 On Thu, Apr 23, 2009 at 01:13:13PM -0400, Daniel Brown wrote: > Furthermore, adapting Eric's calculations below, to brute force > 112-bit keys, assuming 80-bit keys are brute forcible today (let's 112-bit keys... Ah, you must be thinking 3DES. It's worth noting that one of the major cryptographic improvements in AES over 3DES is the block size. The block size has a major impact on things like re-keying considerations. So even assuming equal strength of 3DES and AES and that 112-bit keys are impossible to brute force now and forever, it'd still be worthwhile to switch from 3DES to to AES-128. > just say with massive distributed computing for the sake of example), > feature sizes would need to shrink to 50 * 10^{-9} * 2^{-32} =~ 1.16 * > 10^{-17}, still smaller than a Hydrogen atom, but perhaps NIST was > accounting for the possibility of some future technical developments > leading to continued or even accelerated increase in processing power, > or perhaps NIST was also accounting for some degradation in the > security of the TDEA aglorithm below that of a generic block cipher, > or perhaps NIST is just encouraging migration to AES. If that were quantum computing then all sorts of assumptions go out the window. The more likely explanation is that *some* imaginable cryptanalytic advances could reduce the effective strength of AES in such a way that longer keys remain more secure than shorter keys. Imagine an attack that reduces the effective strength of AES so that breaking it is equivalent to brute-forcing a 2^{key size - 48} key space. As EKR points out, there could be cryptanalytic advances that reduce the strength of AES regardless of the key size used. But going by past advances I think it's likely that any cryptanalysis of AES will leave AES-256 stronger than AES-192, and in turn AES-192 stronger than AES-128. Or at least it's likely that NIST and others thing that :) > That all said, personally, I'm still much more reluctant to predict a > decrease in the growth of processing power that has been going fairly Sadly it must come. We can't reduce feature size too much more than a few atoms, really (ignoring entangled electrons), and we can't have more features than we can pack into a reasonable volume. 2^128 ~= 10^38, which would be only about 10^11 times smaller than Earth. So you'd need 1/10,000th the amount of matter on Earth in order to make a machine that has 2^128 features the size of atoms. Scale that down to something reasonable (and scale up feature size a bit) and you have a rather small computer relative to 128-bit key sizes (but still big enough that distances between components get large enough to be huge headaches). Short of quantum computing and sci-fi tech such as using black holes as computers, I really doubt we'll ever brute force 128-bit keys. It's cryptanalysis or bust :) Nico -- From Martin.Rex@sap.com Thu Apr 23 13:02:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499E73A6EAD for ; Thu, 23 Apr 2009 13:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78iTbj6-86ju for ; Thu, 23 Apr 2009 13:02:08 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3B2603A7293 for ; Thu, 23 Apr 2009 13:00:51 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n3NK26k7006775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 22:02:06 +0200 (MEST) From: Martin Rex Message-Id: <200904232002.n3NK258G029940@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 23 Apr 2009 22:02:05 +0200 (MEST) In-Reply-To: <20090423185550.GW1500@Sun.COM> from "Nicolas Williams" at Apr 23, 9 01:55:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 20:02:09 -0000 Nicolas Williams wrote: > > On Thu, Apr 23, 2009 at 01:13:13PM -0400, Daniel Brown wrote: > > Furthermore, adapting Eric's calculations below, to brute force > > 112-bit keys, assuming 80-bit keys are brute forcible today (let's > > 112-bit keys... Ah, you must be thinking 3DES. It's worth noting that > one of the major cryptographic improvements in AES over 3DES is the > block size. The block size has a major impact on things like re-keying > considerations. So even assuming equal strength of 3DES and AES and > that 112-bit keys are impossible to brute force now and forever, it'd > still be worthwhile to switch from 3DES to to AES-128. A few minor comments. The bit-size is probably about "comparable symmetric cipher strength" rather than actual key length. A 3DES with 112-bit keys would be a two-key-triple-DES, and it is IMHO from the 80-bit comparable symmetric strength ballpark. In common use is 3-key-triple-DES (usually as 3DES-EDE-CBC), which means a 168-bit key (when ignoring the parity bits) and 112-bit comparable symmetric strength. AES-128 is probably much faster in Software on common 32-bit and 64-bit CPUs than 3DES (but I don't know about the modern CPUs from the UltraSparc and Power architectures that have crypto support built-in). There is also a difference in the IV size (matching the cipher blocksize) between 3DES and AES-128. With 3DES you have additonal problems creating keys compared to AES-128: none of the 3 subkeys of 3DES must have the same value, and none of the subkeys should be one of the known DES weak keys. And as long as you don't reuse the same symmetric key all the time, there probably is a difference in the "attributed algorithm strength" based on the best-known attacks and the effective protection strength of a moderately sized archived piece of encrypted data. In case the encryption key is based on a human-memorized password (aka password-based encryption) rather than a strong random session key (as in normal TLS ciphersuites), then the effective strength of the protection might be *much* smaller than what the chosen symmetric algorithm can theoretically provide. -Martin From dean@av8.com Thu Apr 23 13:23:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748E83A6FD3 for ; Thu, 23 Apr 2009 13:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UelMF8FlYql for ; Thu, 23 Apr 2009 13:23:26 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 976193A69B2 for ; Thu, 23 Apr 2009 13:23:26 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n3NKOa6R001388 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Apr 2009 16:24:37 -0400 Date: Thu, 23 Apr 2009 16:24:35 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Steven M. Bellovin" In-Reply-To: <20090423150515.1b202723@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "tls@ietf.org" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 20:23:27 -0000 On Thu, 23 Apr 2009, Steven M. Bellovin wrote: > One more point: NSA may or may not be able to speak ex cathedra on > strength; we'll never know. They have said publicly that they trust > 256-bit AES a lot, and a lot more than they trust 128-bit AES. That > statement is *completely* unprecedented. What's classified top secret is itself classified; and as I understand it, so is the storage and handling of top secret materials, so I think they shouldn't disclosed that AES256 is suitable for top secret because that fact should be a secret that should only be known to people with top secret clearance who handled top secret data. Identifying the cipher in use is part of the cryptanalysis problem, and they shouldn't make that any easier; someone wasn't thinking. > The really interesting question is this: what will NSA ever do, if > they ever figure out how to crack AES-256? Officially decertify it > for TS use, thereby telling the world they think it's no longer that > strong? Easy, they can tell the top secret world that they have a better cipher, which doesn't mean AES-256 is insecure, but only that the new cipher is stronger. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From ekr@networkresonance.com Thu Apr 23 13:37:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E1D3A72ED for ; Thu, 23 Apr 2009 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fceXS8LH8ojw for ; Thu, 23 Apr 2009 13:37:09 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [207.105.81.80]) by core3.amsl.com (Postfix) with ESMTP id C03BA28C6FF for ; Thu, 23 Apr 2009 13:36:38 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3EF45188BFE; Thu, 23 Apr 2009 13:40:20 -0700 (PDT) Date: Thu, 23 Apr 2009 13:40:19 -0700 From: Eric Rescorla To: "Steven M. Bellovin" In-Reply-To: <20090423150515.1b202723@cs.columbia.edu> References: <20090423134052.21DB1188745@kilo.networkresonance.com> <20090423150515.1b202723@cs.columbia.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090423204020.3EF45188BFE@kilo.networkresonance.com> Cc: "tls@ietf.org" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2009 20:37:10 -0000 At Thu, 23 Apr 2009 15:05:15 -0400, Steven M. Bellovin wrote: > Key length certainly isn't everything. A monoalphabetic substitution > on all 256 byte values has a key length of 256!, or about 1684 bits, > but it is of course trivially crackable. > > That said, there's always Whit Diffie's attitude: having extra key bits > is cheap; why not use them if you can? Also, remember that many modern > cryptanalytic techniques produce many key bits but not all, requiring a > brute force search for the remainder. So -- for a situation like that, > more key bits are definitely better, albeit by an imponderable amount. So, this is true for symmetric ciphers but not asymmetric ciphers. > Final comment: the original poster was not asking if they should use > AES-256; he was saying that they do use it, and should the RSA key size > be increased. I think we can all agree on that. I actually don't necessarily agree. If he's using AES-256 because he has data that needs to be kept *really secure*, then yes, he should use RSA > 1024. If he's using AES-256 because it's got a cool sounding name, then maybe not so much. -Ekr From mike-list@pobox.com Thu Apr 23 18:41:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBDC03A6DE1 for ; Thu, 23 Apr 2009 18:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOJ+koK7sXca for ; Thu, 23 Apr 2009 18:41:22 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 17E9D3A6A6B for ; Thu, 23 Apr 2009 18:41:21 -0700 (PDT) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 25AE2119F8 for ; Thu, 23 Apr 2009 21:42:38 -0400 (EDT) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id D61F0119F7 for ; Thu, 23 Apr 2009 21:42:37 -0400 (EDT) Message-ID: <49F1190A.4050205@pobox.com> Date: Thu, 23 Apr 2009 18:42:34 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: tls@ietf.org References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <20090423135638.E17DF188780@kilo.networkresonance.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 31221430-3071-11DE-BFE7-D766E3C8547C-38729857!a-sasl-quonix.pobox.com Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 01:41:22 -0000 > Furthermore, adapting Eric's calculations below, to brute > force 112-bit keys, assuming 80-bit keys are brute forcible > today (let's just say with massive distributed computing for > the sake of example), feature sizes would need to shrink to > 50 * 10^{-9} * 2^{-32} =~ 1.16 * 10^{-17}, still smaller than > a Hydrogen atom.... There is a problem with this math (and the original). Feature size is a linear measure; the number of features increases as the square of the feature size reduction. If you need 2^32 times as many features, then feature size needs to shrink by "only" 2^(-16). Mike From carlyoung@keycomm.co.uk Fri Apr 24 02:22:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCE73A71B5 for ; Fri, 24 Apr 2009 02:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5uyWspvDqq2 for ; Fri, 24 Apr 2009 02:22:40 -0700 (PDT) Received: from smtp-out-59.livemail.co.uk (smtp-out-59.livemail.co.uk [213.171.216.59]) by core3.amsl.com (Postfix) with ESMTP id C52353A6AA1 for ; Fri, 24 Apr 2009 02:22:40 -0700 (PDT) Received: from localhost (mail213-171-216-231.livemail.co.uk [213.171.216.231]) by smtp-out-59.livemail.co.uk (Postfix) with ESMTP id 8F603CF8092 for ; Fri, 24 Apr 2009 10:23:57 +0100 (BST) MIME-Version: 1.0 X-Mailer: AtMail PHP 5.4 Message-ID: <52422.1240565037@keycomm.co.uk> To: Content-Type: text/plain; charset="utf-8" X-Origin: 93.96.210.102 X-Atmail-Account: carlyoung@keycomm.co.uk Date: Fri, 24 Apr 2009 10:23:57 +0100 From: carlyoung@keycomm.co.uk Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlyoung@keycomm.co.uk List-Id: "This is the mailing list 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, 24 Apr 2009 09:22:41 -0000 >On Thu 23/04/09 9:40 PM , Eric Rescorla ekr@networkresonance.com sent: >>At Thu, 23 Apr 2009 15:05:15 -0400, >>Steven M. Bellovin wrote: >> Final comment: the original poster was not asking if they should use >> AES-256; he was saying that they do use it, and should the RSA key size >> be increased. I think we can all agree on that. > >I actually don't necessarily agree. If he's using AES-256 because >he has data that needs to be kept *really secure*, then yes, he >should use RSA > 1024. If he's using AES-256 because it's got >a cool sounding name, then maybe not so much. Firstly, I'd like to thank everyone for their comments and observations; it= has been enlightening. Eric - I really didn't choose AES-256; my customer (possibly US based and f= ederal...?) chose this. We primarily use whatever cipher suites are availab= le in TLS from OpenSSL, but do allow the customers to manually specify the = cipher list. All I want to do is to advise them, and other customers, that migrating fro= m 3DES_EDE to AES-256 - without changing their certificates from 1024 bits = - has provided no appreciable gain in security strength as the RSA keys are= the weakest link in the chain. All we are doing in this case is using more= processing power to provide the same level of security as we did previousl= y. I will try to make some generic advice available without getting evangelica= l about FIPS key-size recommendations. If they really want to use 15,360 bi= t RSA keys and AES-256, that is up to them [though I suspect the overhead i= nvolved in this would kill the product's performance dead in the water]. I will try to provide some generic advice, whilst referencing the FIPS publ= ications, and suggest that AES-128 is perfectly good enough for them, but c= ertificate key sizes should be increased to 2048 bits or possibly 3072. Many thanks, Carl From fweimer@bfk.de Fri Apr 24 02:33:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F1D3A6A13 for ; Fri, 24 Apr 2009 02:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocFj3ioolI4j for ; Fri, 24 Apr 2009 02:33:27 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 648B43A69DE for ; Fri, 24 Apr 2009 02:33:25 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LxHnb-0007SN-3G; Fri, 24 Apr 2009 11:34:24 +0200 Received: from fweimer by bfk.de with local id 1LxHnr-0002sf-SD; Fri, 24 Apr 2009 11:34:40 +0200 To: carlyoung@keycomm.co.uk References: <52422.1240565037@keycomm.co.uk> From: Florian Weimer Date: Fri, 24 Apr 2009 11:34:39 +0200 In-Reply-To: <52422.1240565037@keycomm.co.uk> (carlyoung@keycomm.co.uk's message of "Fri, 24 Apr 2009 10:23:57 +0100") Message-ID: <82fxfy5r9s.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 09:33:28 -0000 > All I want to do is to advise them, and other customers, that > migrating from 3DES_EDE to AES-256 - without changing their > certificates from 1024 bits - has provided no appreciable gain in > security strength as the RSA keys are the weakest link in the > chain. All we are doing in this case is using more processing power > to provide the same level of security as we did previously. Isn't AES-256 way faster than Triple DES? --=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 pgut001@cs.auckland.ac.nz Fri Apr 24 02:37:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2786E3A69DE for ; Fri, 24 Apr 2009 02:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK8c15CWswkL for ; Fri, 24 Apr 2009 02:37:36 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 551773A68AD for ; Fri, 24 Apr 2009 02:37:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0E52E66978B; Fri, 24 Apr 2009 21:38:53 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE8QOl8wciuh; Fri, 24 Apr 2009 21:38:52 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9F723668FCB; Fri, 24 Apr 2009 21:38:52 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2954819EC0BA; Fri, 24 Apr 2009 21:38:52 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LxHrw-0002NF-0P; Fri, 24 Apr 2009 21:38:52 +1200 From: Peter Gutmann To: carlyoung@keycomm.co.uk In-Reply-To: <52422.1240565037@keycomm.co.uk> Message-Id: Sender: pgut001 Date: Fri, 24 Apr 2009 21:38:52 +1200 Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 09:37:37 -0000 carlyoung@keycomm.co.uk writes: >All I want to do is to advise them, and other customers, that migrating from >3DES_EDE to AES-256 - without changing their certificates from 1024 bits - >has provided no appreciable gain in security strength as the RSA keys are the >weakest link in the chain. It'd be interesting to hear what they say (off-list, if it's non-public). I have the feeling it'll be, as someone else in this thread put it, "" :-). For example I've got users using 512-bit public keys with AES because anything more heavyweight in the embedded device they produce makes the handshake unworkable. Their risk assessment was that given the difference between no security (caused by connect attempts timing out, so people connect unsecured) and good-enough security, they'll opt for the good-enough security. (Incidentally, I'm always interested in real-world experiences that people have had in terms of users making tradeoffs like this, if anyone's got any interesting/illuminating stories I'd love to hear them). Peter. From uri@ll.mit.edu Fri Apr 24 05:07:21 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BF33A6B17 for ; Fri, 24 Apr 2009 05:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rCmz3lIIAmU for ; Fri, 24 Apr 2009 05:07:20 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 759863A6A05 for ; Fri, 24 Apr 2009 05:07:20 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3OC8SXc026220; Fri, 24 Apr 2009 08:08:28 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAYfaW1P; Fri Apr 24 08:03:48 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Fri, 24 Apr 2009 08:03:48 -0400 From: "Blumenthal, Uri" To: "'pgut001@cs.auckland.ac.nz'" , "'carlyoung@keycomm.co.uk'" Date: Fri, 24 Apr 2009 08:03:47 -0400 Thread-Topic: [TLS] Comparative cipher suite strengths Thread-Index: AcnEwIfNAdjdBqmOR7uYc1yW+7jDWAAFDEVx Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F347@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 12:07:21 -0000 UmVnYXJkaW5nIHRoZSByZWFsLXdvcmxkIHRyYWRlLW9mZnMgLSBpdCdzIGZhaXJseSB0cml2aWFs LiBJbiBteSBleHBlcmllbmNlIGl0IGhhcHBlbmVkIHRoYXQgSSd2ZSBoZWFyZCBiYWNrICJXZSBj YW5ub3QgY29tcHV0YXRpb25hbGx5IGFmZm9yZCBSU0EtWFhYWCwgdGhlcmVmb3JlIGl0IHdpbGwg YmUgUlNBLVlZWVkgd2l0aCB3aGF0ZXZlciBwcm90ZWN0aW9uIGxldmVsIGl0IGdpdmVzLiBBRVMt MTI4IGlzIGdvb2QsIHJlY29nbml6ZWQsIGFuZCB3ZSBjYW4gYWZmb3JkIGl0IC0gdGhlcmVmb3Jl IGl0IGdvZXMgaW4gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0J3MgYW4gb3ZlcmtpbGwgaW4gdGhl IG92ZXJhbGwgcGljdHVyZS4gV2UgYWNjZXB0IHRoYXQgdGhlIHdlYWtlc3QgY3J5cHRvZ3JhcGhp YyBsaW5rIHdpbGwgYmUgUlNBLCBieSBhIHByb2JhYmxlIGZhY3RvciBvZiBaXksuIiBUaGVuIHRo ZSBkaXNjdXNzaW9uIHdvdWxkIHVzdWFsbHkgbW92ZSB0byBpbXBsZW1lbnRhdGlvbiBkZXRhaWxz LCB3aXRoIG90aGVyIGlzc3VlcyBhbmQgd2Vha25lc3NlcyB0byBhZGRyZXNzLg0KDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IHRscy1ib3VuY2VzQGlldGYub3JnIDx0bHMt Ym91bmNlc0BpZXRmLm9yZz4NClRvOiBjYXJseW91bmdAa2V5Y29tbS5jby51ayA8Y2FybHlvdW5n QGtleWNvbW0uY28udWs+DQpDYzogdGxzQGlldGYub3JnIDx0bHNAaWV0Zi5vcmc+DQpTZW50OiBG cmkgQXByIDI0IDA1OjM4OjUyIDIwMDkKU3ViamVjdDogUmU6IFtUTFNdIENvbXBhcmF0aXZlIGNp cGhlciBzdWl0ZSBzdHJlbmd0aHMNCg0KY2FybHlvdW5nQGtleWNvbW0uY28udWsgd3JpdGVzOg0K DQo+QWxsIEkgd2FudCB0byBkbyBpcyB0byBhZHZpc2UgdGhlbSwgYW5kIG90aGVyIGN1c3RvbWVy cywgdGhhdCBtaWdyYXRpbmcgZnJvbQ0KPjNERVNfRURFIHRvIEFFUy0yNTYgLSB3aXRob3V0IGNo YW5naW5nIHRoZWlyIGNlcnRpZmljYXRlcyBmcm9tIDEwMjQgYml0cyAtDQo+aGFzIHByb3ZpZGVk IG5vIGFwcHJlY2lhYmxlIGdhaW4gaW4gc2VjdXJpdHkgc3RyZW5ndGggYXMgdGhlIFJTQSBrZXlz IGFyZSB0aGUNCj53ZWFrZXN0IGxpbmsgaW4gdGhlIGNoYWluLg0KDQpJdCdkIGJlIGludGVyZXN0 aW5nIHRvIGhlYXIgd2hhdCB0aGV5IHNheSAob2ZmLWxpc3QsIGlmIGl0J3Mgbm9uLXB1YmxpYyku ICBJDQpoYXZlIHRoZSBmZWVsaW5nIGl0J2xsIGJlLCBhcyBzb21lb25lIGVsc2UgaW4gdGhpcyB0 aHJlYWQgcHV0IGl0LCAiPGNyaWNrZXRzPiINCjotKS4gIEZvciBleGFtcGxlIEkndmUgZ290IHVz ZXJzIHVzaW5nIDUxMi1iaXQgcHVibGljIGtleXMgd2l0aCBBRVMgYmVjYXVzZQ0KYW55dGhpbmcg bW9yZSBoZWF2eXdlaWdodCBpbiB0aGUgZW1iZWRkZWQgZGV2aWNlIHRoZXkgcHJvZHVjZSBtYWtl cyB0aGUNCmhhbmRzaGFrZSB1bndvcmthYmxlLiAgVGhlaXIgcmlzayBhc3Nlc3NtZW50IHdhcyB0 aGF0IGdpdmVuIHRoZSBkaWZmZXJlbmNlDQpiZXR3ZWVuIG5vIHNlY3VyaXR5IChjYXVzZWQgYnkg Y29ubmVjdCBhdHRlbXB0cyB0aW1pbmcgb3V0LCBzbyBwZW9wbGUgY29ubmVjdA0KdW5zZWN1cmVk KSBhbmQgZ29vZC1lbm91Z2ggc2VjdXJpdHksIHRoZXknbGwgb3B0IGZvciB0aGUgZ29vZC1lbm91 Z2ggc2VjdXJpdHkuDQoNCihJbmNpZGVudGFsbHksIEknbSBhbHdheXMgaW50ZXJlc3RlZCBpbiBy ZWFsLXdvcmxkIGV4cGVyaWVuY2VzIHRoYXQgcGVvcGxlDQpoYXZlIGhhZCBpbiB0ZXJtcyBvZiB1 c2VycyBtYWtpbmcgdHJhZGVvZmZzIGxpa2UgdGhpcywgaWYgYW55b25lJ3MgZ290IGFueQ0KaW50 ZXJlc3RpbmcvaWxsdW1pbmF0aW5nIHN0b3JpZXMgSSdkIGxvdmUgdG8gaGVhciB0aGVtKS4NCg0K UGV0ZXIuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0K From Bruno.Harbulot@manchester.ac.uk Fri Apr 24 07:15:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD843A6AD9 for ; Fri, 24 Apr 2009 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCGeq4ofgTJ2 for ; Fri, 24 Apr 2009 07:15:11 -0700 (PDT) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by core3.amsl.com (Postfix) with ESMTP id 1B3233A6A8B for ; Fri, 24 Apr 2009 07:15:10 -0700 (PDT) Received: from kelvin.its.manchester.ac.uk ([130.88.25.195]) by serenity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxMCY-000Jzo-BF; Fri, 24 Apr 2009 15:16:26 +0100 Received: from mirabelle.rcs.manchester.ac.uk ([130.88.1.123]:55866 helo=mymachine) by kelvin.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LxMCY-0005Ri-6F; Fri, 24 Apr 2009 15:16:26 +0100 Message-ID: <49F1C9B7.9060504@manchester.ac.uk> Date: Fri, 24 Apr 2009 15:16:23 +0100 From: Bruno Harbulot User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> <49A7C991.5050309@gnutls.org> In-Reply-To: <49A7C991.5050309@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-Sender: Bruno Harbulot from mirabelle.rcs.manchester.ac.uk (mymachine) [130.88.1.123]:55866 X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. Cc: Henry Story , tls@ietf.org, foaf-protocols@lists.foaf-project.org Subject: Re: [TLS] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 14:15:12 -0000 Hello, Nikos Mavrogiannopoulos wrote: > Henry Story wrote: >> Dear TLS experts, >> >> We are working on a very simple protocol for distributed identity in a >> web of trust that uses TLS in a novel way. The details of this are short >> and can be found online [1]. Here I'd first just like to ask two >> questions, to get into the heart of the problem, then I'll explain why >> these came up. > > After the explanation and seeing the protocol description I still do not > understand why you need the client certificate for what you want to > achieve. Why you don't send the information you need for foaf on the > application layer (if it is http via a cookie etc)? Why send a dummy > certificate and add some extensions on it? Also the security offerings > are not clear to me. What will that protocol offer, security-wise? As an authentication mechanism, the main goal of FOAF+SSL is to bind the client to the URI (of a foaf:Agent), in the same way as the client would be bound to a Subject DN in a PKI. In short, FOAF+SSL certificates are X.509 certificates that contain a public key and foaf:Agent URI in its subject alternative name extension; more or less all the rest is ignored. (For people not familiar with FOAF, foaf:Person is a subclass of foaf:Agent that models a person, for example.) To compare FOAF+SSL and PKI: what binds the client to a Subject DN is both (a) the TLS handshake (which links the client the holder of the private key matching the public key in the client cert) and (b) the verification of the actual certificate (certification path to trust anchor, etc.) FOAF+SSL also uses the fact that the client presents both an identity claim (its foaf:Agent URI in the client certificate instead of an X.500 Subject DN) and the public key (which matches the private key the client actually has). Only the evaluation of trust in the client-certificate changes. At this stage, whether the client certificate is self-signed or signed by another party isn't particularly important, since it's not what's used to verify its content. There are two ways of verifying the certificate in FOAF+SSL, and the security offerings are significantly different: dereferencing and cryptographic web-of-trust. A. Dereferencing Dereferencing is the main method explained on Henry's blog [1][2]. (I should point out that Henry's use of "web of trust" is more about how individuals link to each other in a social network and doesn't necessarily involve signing those assertions, as in OpenPGP, which makes it somewhat different from a "cryptographic" web of trust). It works as follows: 1. The client presents a certificate (self-signed or not) that contains a URI (such as , a foaf:Agent), and a public key. 2. The server dereferences this URI (i.e. does an HTTP GET) and processes the content of the document, which will contain a public key associated to this URI. 3. If the public key in the dereferenced document for this URI and the public key in the client certificate match, then the verification is successful. The security of this verification model depends on how much the authenticating server can trust the authenticity of document that was obtained by dereferencing the URI. In particular, it must trust the server certificate of 'romeo.example' and the fact that no one tampered with the file on that server. This level of security is suitable for some applications, but probably not all. B. Cryptographic web of trust I've talked a bit more about this on my own blog [3]. It's possible to sign sub-graphs asserting the links between an ID (the URI) and a public key. This way, one could have a set of trust anchors under the form of a local/trusted FOAF file (or something else) against which to evaluate a certificate (à la OpenPGP). Similarly, a hierarchical model could be built. The level of assurance here depends on how much you trust the trust anchors and potential introducers; it's likely to be greater than with the dereferencing method. The security levels are quite flexible, and systems using FOAF+SSL for authentication and authorisation ought to be configured according to the requirements of the application (like any system, I suppose). When we say that FOAF+SSL is a secure protocol, we really ought to qualify that assertion. The advantage of the FOAF+SSL approach (putting the information in an X.509 certificate as opposed to creating another type of certificate) is that this works without modifying the implementation of SSL/TLS stacks. The only changes required are in the customisation of the evaluation of trust in a client certificate. This requires some specific configuration in the application, but no changes of the SSL-related libraries themselves if they have such hooks (JSSE and OpenSSL work, at least). In fact, for development purposes, we've accept any certificate during the handshake and do the verification at the application level. The original questions that Henry sent were related to the way the browser chooses a certificate (or asks the user to choose). Because the FOAF+SSL certificate is self-signed, the server has to be configured with an empty list of CAs in the CertificateRequest. This is the same problem as the one addressed in Section 3.4 of RFC 5081 [4]. To make the choice of certificate easier in the browser, we had thought of having an "open CA", for which we would distribute the private key openly, just for the sake of making the servers add that CA in the CertificateRequest list. I've since realised that we don't really need that, since only the name matters: we could just make the server ask for a conventional name and the self-signed client certificate would have that issuer name [5]. Of course, this wouldn't be compliant with RFC 5280 [6]. We would be interested in feedback regarding this approach, in particular whether this would break with further versions of TLS. Best wishes, Bruno. [1] http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to [2] http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf [3] http://blog.distributedmatter.net/post/2009/03/07/Signing-FOAF-files%3A-FOAF-files-as-certificates [4] http://tools.ietf.org/html/rfc5081#section-3.4 [5] http://lists.foaf-project.org/pipermail/foaf-protocols/2009-April/000450.html [6] http://tools.ietf.org/html/rfc5280 From jsalowey@cisco.com Fri Apr 24 07:47:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768933A701F for ; Fri, 24 Apr 2009 07:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMSVo4EMv2h5 for ; Fri, 24 Apr 2009 07:47:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 385333A73CF for ; Fri, 24 Apr 2009 07:46:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,241,1238976000"; d="scan'208";a="73147176" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2009 14:47:28 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3OElSVM026504 for ; Fri, 24 Apr 2009 07:47:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OElSR4014297 for ; Fri, 24 Apr 2009 14:47:28 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 07:47:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 07:47:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call for draft-ietf-tls-rfc4366-bis-04 Thread-Index: AcnE65aKNrAuthy3SxGjc6f6KpJ5ig== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 24 Apr 2009 14:47:28.0770 (UTC) FILETIME=[97127E20:01C9C4EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=369; t=1240584448; x=1241448448; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Working=20Group=20Last=20Call=20for=20draft-iet f-tls-rfc4366-bis-04 |Sender:=20; bh=hroeK3gwiHszLyisQyMe9E/TknB3rroBosmzrvtSBko=; b=hB6kCcikDIF4RbSb4ekMZM7WsZT+H8PDHEbWoJ6LSjxPO8w+mBCD9Co8I0 UqXknC70wV15tVYH49H3aVYOaN/gFOw+HnHQViIlVeSWZvHrdhw++EvyqN3j zQsgfdxMlj; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [TLS] Working Group Last Call for draft-ietf-tls-rfc4366-bis-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 14:47:25 -0000 This is a working group last call for comments on draft-ietf-tls-rfc4366-bis-04 prior to sending this document on to the IESG for publication as a proposed standard RFC. The document and revision history can be found here: http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-04 Please send any comments to the list by May 15, 2009. =20 Thanks, Joe From Vipul.Gupta@sun.com Fri Apr 24 09:22:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BEB3A6CE1 for ; Fri, 24 Apr 2009 09:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FovxYMOt11kd for ; Fri, 24 Apr 2009 09:22:09 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 9B2233A6C37 for ; Fri, 24 Apr 2009 09:22:09 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KIM005RP5J0KG10@mail-mta.sfvic.sunlabs.com> for tls@ietf.org; Fri, 24 Apr 2009 09:23:24 -0700 (PDT) Received: from [152.70.69.170] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KIM00FFC5IZX1Q0@mail.sunlabs.com> for tls@ietf.org; Fri, 24 Apr 2009 09:23:24 -0700 (PDT) Date: Fri, 24 Apr 2009 09:23:23 -0700 From: Vipul Gupta In-reply-to: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F347@LLE2K7-BE01.mitll.ad.local> To: "Blumenthal, Uri" Message-id: <5CBA9427-AA70-4128-8E63-FB5027F144BD@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F347@LLE2K7-BE01.mitll.ad.local> Cc: "'tls@ietf.org'" , Vipul Gupta Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 16:22:10 -0000 I'm curious to learn why the discussion doesn't branch out to consider ECC (e.g. RFC4492) instead of RSA? ECC is supported in OpenSSL/Firefox/ Internet Explorer. Is that because ECC certificates aren't available from the popular Certificate Authorities? This should be less of an issue in an embedded/closed environment where one could use their own CA/cert. vipul p.s. For those unfamiliar with the performance advantages of ECC public key cryptography, especially at these higher key sizes, several papers are available at http://research.sun.com/projects/crypto. On Apr 24, 2009, at 5:03 AM, Blumenthal, Uri wrote: > Regarding the real-world trade-offs - it's fairly trivial. In my > experience it happened that I've heard back "We cannot > computationally afford RSA-XXXX, therefore it will be RSA-YYYY with > whatever protection level it gives. AES-128 is good, recognized, and > we can afford it - therefore it goes in regardless of whether it's > an overkill in the overall picture. We accept that the weakest > cryptographic link will be RSA, by a probable factor of Z^K." Then > the discussion would usually move to implementation details, with > other issues and weaknesses to address. > > > ----- Original Message ----- > From: tls-bounces@ietf.org > To: carlyoung@keycomm.co.uk > Cc: tls@ietf.org > Sent: Fri Apr 24 05:38:52 2009 > Subject: Re: [TLS] Comparative cipher suite strengths > > carlyoung@keycomm.co.uk writes: > >> All I want to do is to advise them, and other customers, that >> migrating from >> 3DES_EDE to AES-256 - without changing their certificates from 1024 >> bits - >> has provided no appreciable gain in security strength as the RSA >> keys are the >> weakest link in the chain. > > It'd be interesting to hear what they say (off-list, if it's non- > public). I > have the feeling it'll be, as someone else in this thread put it, > "" > :-). For example I've got users using 512-bit public keys with AES > because > anything more heavyweight in the embedded device they produce makes > the > handshake unworkable. Their risk assessment was that given the > difference > between no security (caused by connect attempts timing out, so > people connect > unsecured) and good-enough security, they'll opt for the good-enough > security. > > (Incidentally, I'm always interested in real-world experiences that > people > have had in terms of users making tradeoffs like this, if anyone's > got any > interesting/illuminating stories I'd love to hear them). > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Fri Apr 24 10:17:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604F73A6B8F for ; Fri, 24 Apr 2009 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-ZufyIAPStb for ; Fri, 24 Apr 2009 10:17:46 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 5D77A3A67F6 for ; Fri, 24 Apr 2009 10:17:46 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3OHJ4gt023855 for ; Fri, 24 Apr 2009 17:19:04 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3OHJ4aD036627 for ; Fri, 24 Apr 2009 11:19:04 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3OH9V5n017881; Fri, 24 Apr 2009 12:09:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3OH9QBk017880; Fri, 24 Apr 2009 12:09:26 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 24 Apr 2009 12:09:26 -0500 From: Nicolas Williams To: Vipul Gupta Message-ID: <20090424170926.GU1500@Sun.COM> References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F347@LLE2K7-BE01.mitll.ad.local> <5CBA9427-AA70-4128-8E63-FB5027F144BD@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CBA9427-AA70-4128-8E63-FB5027F144BD@sun.com> User-Agent: Mutt/1.5.7i Cc: "'tls@ietf.org'" Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 17:17:47 -0000 On Fri, Apr 24, 2009 at 09:23:23AM -0700, Vipul Gupta wrote: > I'm curious to learn why the discussion doesn't branch out to consider > ECC (e.g. RFC4492) instead of RSA? ECC is supported in OpenSSL/Firefox/ > Internet Explorer. Is that because ECC certificates aren't available > from the popular Certificate Authorities? This should be less of an > issue in an embedded/closed environment where one could use their own > CA/cert. If certs are an issue and active attackers are not an issue then you could always use ECDHE_RSA with the smallish RSA keys you have already. From rrelyea@redhat.com Fri Apr 24 11:32:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6143A6A24 for ; Fri, 24 Apr 2009 11:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv----eU1H9x for ; Fri, 24 Apr 2009 11:32:24 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by core3.amsl.com (Postfix) with ESMTP id C58B63A67E7 for ; Fri, 24 Apr 2009 11:32:24 -0700 (PDT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3OIXh4a005106 for ; Fri, 24 Apr 2009 14:33:43 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3OIXg1L003990 for ; Fri, 24 Apr 2009 14:33:42 -0400 Received: from [10.14.54.218] (dhcp-218.sjc.redhat.com [10.14.54.218]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3OIXfKl003482 for ; Fri, 24 Apr 2009 14:33:41 -0400 Message-ID: <49F20606.8040606@REDHAT.COM> Date: Fri, 24 Apr 2009 11:33:42 -0700 From: Robert Relyea User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050205000807000001030107" X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 18:32:25 -0000 This is a cryptographically signed message in MIME format. --------------ms050205000807000001030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > carlyoung@keycomm.co.uk writes: > > >> Therefore, in my mind, they are getting a false sense of security from using >> AES-256 as the underlying strength of the whole TLS session is determined by >> the weakest point - in this case the 1024 bit RSA keys, which NIST state to >> be equivalent to "80-bits" [when compared to a symmetric cipher I guess]. >> > > They're not getting any sense of security at all. They initially wanted a > cipher with 128-bit encryption, because everyone knows that you have to have > 128 bits to be Good. AES encryption has the required 128 thingies, so they > went with that. > > Then someone pointed out that there's a version of AES with 256 thingies > instead of 128, and if 128 is Good then 256 must be even Gooder. So the > requirement was changed to use AES with 256 thingies. > > If there was an AES with 397 thingies they'd go with that instead, because > it's obvious that that one's ever Gooderer than the one with 256 thingies. > So there is a method behind the AES-256 bit madness, and can see it in the cipher suites that NIST specifies. As Carl has found (and most on this list is familiar with), NIST has standardized it's 'strength' specification in terms of symmetric key algorithm, which is why he matched AES-256 with a 15K bit RSA key. NIST also defines strengths for various security levels. 128 bits is the minimum for Secret, 192 is the minimum for Top Secret. These numbers are both chosen to be more than known foreign governments and agencies are likely to be able to crack (presumably including a generous safety factor). In addition to security levels, NIST also defines a set of cipher suites for these levels: Secret: AES-128, ECC-256 prime, SHA-256 Top Secret: AES-256, ECC 384 prime, SHA-384 Note that AES-256 has a bigger key than required. NIST specified AES-256 because it was already the same speed as AES-192. I don't know why they didn't specify SHA-512 over SHA-384 (which has the same characteristics). The upshot is even NIST, using top secret doesn't need 256 bits. It's just the easiest way to meet their 192 bit requirement. Also not that AES-128 is considered sufficient for the US government to encode Secret information. For practical and commercial use, it's still overkill. 80- 100 bits is still sufficient for now (though moving toward 100 bits is probably prudent). So you need to go back to your customer and find out what their real key strength need is. If your customer needs 192 bits, you probably want to move toward ECC ciphers (If you customer's AES-256 is coming from a NIST Suite-B requirement, then you'll need to move there anyway). Otherwise you are looking at a 7K bit RSA key to meet that requirement. If you aren't talking to a Suite-B customer, then the info you are getting from this list is probably correct "AES-256 sounds strong, might as well go there" ignoring the fact that even at AES-128 your weak link is RSA (unless you use a 3K key). bob --------------ms050205000807000001030107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrTCC AzEwggKaoAMCAQICEAlgxvrCJ9pdY3lsF/qpIS0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIxMjE4NDc0OFoX DTA5MTIxMjE4NDc0OFowgYYxDzANBgNVBAQTBlJlbHllYTEUMBIGA1UEKhMLUm9iZXJ0IEpv aG4xGzAZBgNVBAMTElJvYmVydCBKb2huIFJlbHllYTEdMBsGCSqGSIb3DQEJARYOYm9iQHJl bHllYS5jb20xITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVkaGF0LmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANL23hLa9Dz7qsiwIX539CurUEs61ARDvSLOOtZDN/Ld /m8WoVYwhIMWmhkjCqI0Dc938Vu0ug/Xiu/jIRxqWALBqJRB/502LV0MrfIWI5AyxZeNzMCd 0EuyI7HXerD7lwALX+8YP4+sLqxnpGxbPPfXnL1AEno+kwHMQ8++WmRXUsXhhryLNDrU8drf T11z5N3esN7il+MwrMS2fd0iEBFUTlsFBnLytgYIvR52X/gbp/Lqr6m+eMC7ac7/IRLLIqGD OYvToKyK0dA/Iw8j2MHvRd/NB148ItiDKmyEBtInQSZhFwDPi/A56ClLs970c3diWcxqE0BN l0U0QRpzRbMCAwEAAaM/MD0wLQYDVR0RBCYwJIEOYm9iQHJlbHllYS5jb22BEnJyZWx5ZWFA cmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAFUYowkBAmx2akv2 uYOpEkzUG+pmCgcFzuw5Mk3Jd2TfnSDJsJmG/pgSSHExAvtoDUksZLHs7CZr5Gxumg24kbp6 Luhj7p8zmIukhqS4lPfXvsNhDKaEtNf8/w/dIPEbcvAgGRCjscvbTBp5GzZiUerJi0xPTrNf s7FcE7ts/B1uMIIDMTCCApqgAwIBAgIQCWDG+sIn2l1jeWwX+qkhLTANBgkqhkiG9w0BAQUF ADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgx MjEyMTg0NzQ4WhcNMDkxMjEyMTg0NzQ4WjCBhjEPMA0GA1UEBBMGUmVseWVhMRQwEgYDVQQq EwtSb2JlcnQgSm9objEbMBkGA1UEAxMSUm9iZXJ0IEpvaG4gUmVseWVhMR0wGwYJKoZIhvcN AQkBFg5ib2JAcmVseWVhLmNvbTEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0vbeEtr0PPuqyLAhfnf0K6tQSzrU BEO9Is461kM38t3+bxahVjCEgxaaGSMKojQNz3fxW7S6D9eK7+MhHGpYAsGolEH/nTYtXQyt 8hYjkDLFl43MwJ3QS7Ijsdd6sPuXAAtf7xg/j6wurGekbFs899ecvUASej6TAcxDz75aZFdS xeGGvIs0OtTx2t9PXXPk3d6w3uKX4zCsxLZ93SIQEVROWwUGcvK2Bgi9HnZf+Bun8uqvqb54 wLtpzv8hEssioYM5i9OgrIrR0D8jDyPYwe9F380HXjwi2IMqbIQG0idBJmEXAM+L8DnoKUuz 3vRzd2JZzGoTQE2XRTRBGnNFswIDAQABoz8wPTAtBgNVHREEJjAkgQ5ib2JAcmVseWVhLmNv bYEScnJlbHllYUByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA VRijCQECbHZqS/a5g6kSTNQb6mYKBwXO7DkyTcl3ZN+dIMmwmYb+mBJIcTEC+2gNSSxksezs JmvkbG6aDbiRunou6GPunzOYi6SGpLiU99e+w2EMpoS01/z/D90g8Rty8CAZEKOxy9tMGnkb NmJR6smLTE9Os1+zsVwTu2z8HW4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAlg xvrCJ9pdY3lsF/qpIS0wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwNDI0MTgzMzQyWjAjBgkqhkiG9w0BCQQxFgQUniE0LGzf uSQPkPD7gffA4xFuUxwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQCWDG+sIn2l1jeWwX+qkhLTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCWDG+sIn2l1j eWwX+qkhLTANBgkqhkiG9w0BAQEFAASCAQBwiEImMVqmujvSTYlAbv6h4NK2nATSgGHCnlAU VlTdBgiUNxe2WAWfn856GUiXza3phydx/x0ot/m9IkanwKzmW8DZpfc+Es+h2C3mdk2uDnIc wW/PSrJTNVAqRwLcjdDI6z3hHalTioEULzIMA53ZIwmbCkwrSz9muzHU0pCLHuEsWftFzvsp GNcZOna8GPtnoG0aDDC5zhCDK6ILYlfkVUcWD8AhHVhBFyc3kyWGkpJPRWCXqqnQeT4Yt85b lF7F4+8HNNqdiKGP8iDMbAR+BC27D7iV3+y3TDnbNDp9ms1KWt/X3JLy3ynV5pnoPnpdDjwM xXtbF8OzjTWMfA7dAAAAAAAA --------------ms050205000807000001030107-- From simon@josefsson.org Fri Apr 24 15:45:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BA13A68DA for ; Fri, 24 Apr 2009 15:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+0HTScNyGfQ for ; Fri, 24 Apr 2009 15:45:44 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4634E3A6839 for ; Fri, 24 Apr 2009 15:45:44 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LxUAe-00015k-5I for TLS@ietf.org; Sat, 25 Apr 2009 00:47:01 +0200 From: Simon Josefsson To: References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090424:jsalowey@cisco.com::ZI45WoCSkaCNkQGu:1WNg X-Hashcash: 1:22:090424:tls@ietf.org::Mn6kQuMBcaqWRUo0:AF/i Date: Sat, 25 Apr 2009 00:46:58 +0200 In-Reply-To: (Joseph Salowey's message of "Fri, 24 Apr 2009 07:47:27 -0700") Message-ID: <87vdotis9p.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [TLS] Review of draft-ietf-tls-rfc4366-bis-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 22:45:45 -0000 "Joseph Salowey (jsalowey)" writes: > This is a working group last call for comments on > draft-ietf-tls-rfc4366-bis-04 prior to sending this document on to the > IESG for publication as a proposed standard RFC. The document and > revision history can be found here: > > http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-04 > > > Please send any comments to the list by May 15, 2009. Hi. The document looks good in general, however I have two comments: 1) RFC 4366 contains: struct { opaque url<1..2^16-1>; Boolean hash_present; select (hash_present) { case false: struct {}; case true: SHA1Hash; } hash; } URLAndOptionalHash; The draft changes the struct to: struct { opaque url<1..2^16-1>; opaque SHA1Hash[20]; } URLAndHash; An RFC 4366 implementation that receives a RFC4366bis struct will reject the encoding as corrupt, and possibly refuse the connection. Likewise, an RFC 4366bis implementations will reject a RFC4366 struct. It is possible to implement a parser that will accept both structs, but this is not discussed nor suggested by the document. I suggest that a padding byte is inserted as follows: struct { opaque url<1..2^16-1>; opaque padding<1>; opaque SHA1Hash[20]; } URLAndHash; And some text is added: The "padding" byte MUST be 0x01. It is present to make the structure backwards compatible. TLS 1.2 also changed old structs, let's not make the same mistake again. 2) There is an RFC Errata for RFC 4366: http://rfc-editor.org/errata_search.php?eid=111 The issues are all either irrelevant or fixed, except for (2). As far as I can tell, the concern is valid. The text needs to be modified to replace "the server name" with "any of the server names". The WG could also consider Alfred's suggestion that clients needs indication of which name the server accepted, but I'm not sure this is important. /Simon From ekr@networkresonance.com Fri Apr 24 15:47:46 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2039E28C0EC for ; Fri, 24 Apr 2009 15:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1NZ9FpCg10I for ; Fri, 24 Apr 2009 15:47:44 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [207.105.81.80]) by core3.amsl.com (Postfix) with ESMTP id 3ACF13A6B42 for ; Fri, 24 Apr 2009 15:47:44 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 8142218A429; Fri, 24 Apr 2009 15:51:34 -0700 (PDT) Date: Fri, 24 Apr 2009 15:51:34 -0700 From: Eric Rescorla To: Simon Josefsson In-Reply-To: <87vdotis9p.fsf@mocca.josefsson.org> References: <87vdotis9p.fsf@mocca.josefsson.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090424225134.8142218A429@kilo.networkresonance.com> Cc: TLS@ietf.org Subject: Re: [TLS] Review of draft-ietf-tls-rfc4366-bis-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2009 22:47:46 -0000 At Sat, 25 Apr 2009 00:46:58 +0200, Simon Josefsson wrote: > > "Joseph Salowey (jsalowey)" writes: > > > This is a working group last call for comments on > > draft-ietf-tls-rfc4366-bis-04 prior to sending this document on to the > > IESG for publication as a proposed standard RFC. The document and > > revision history can be found here: > > > > http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-04 > > > > > > Please send any comments to the list by May 15, 2009. > > Hi. The document looks good in general, however I have two comments: > > 1) > > RFC 4366 contains: > > struct { > opaque url<1..2^16-1>; > Boolean hash_present; > select (hash_present) { > case false: struct {}; > case true: SHA1Hash; > } hash; > } URLAndOptionalHash; > > The draft changes the struct to: > > struct { > opaque url<1..2^16-1>; > opaque SHA1Hash[20]; > } URLAndHash; > > An RFC 4366 implementation that receives a RFC4366bis struct will reject > the encoding as corrupt, and possibly refuse the connection. > > Likewise, an RFC 4366bis implementations will reject a RFC4366 struct. > > It is possible to implement a parser that will accept both structs, but > this is not discussed nor suggested by the document. > > I suggest that a padding byte is inserted as follows: > > struct { > opaque url<1..2^16-1>; > opaque padding<1>; > opaque SHA1Hash[20]; > } URLAndHash; > > And some text is added: > > The "padding" byte MUST be 0x01. It is present to make the structure > backwards compatible. > > TLS 1.2 also changed old structs, let's not make the same mistake again. Oh, good catch. I would leave it as-is in 4366 and simply say // Must be true... -Ekr From pgut001@cs.auckland.ac.nz Fri Apr 24 23:01:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD2F3A65A5 for ; Fri, 24 Apr 2009 23:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOt33ndHiDHs for ; Fri, 24 Apr 2009 23:01:38 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id E6C8C3A6782 for ; Fri, 24 Apr 2009 23:00:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F20CF66937B; Sat, 25 Apr 2009 18:02:00 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT2FIZej0kTV; Sat, 25 Apr 2009 18:02:00 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 837A9668131; Sat, 25 Apr 2009 18:02:00 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 464EFE0808D; Sat, 25 Apr 2009 18:01:59 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lxaxb-00069O-2S; Sat, 25 Apr 2009 18:01:59 +1200 From: Peter Gutmann To: uri@ll.mit.edu, Vipul.Gupta@sun.com In-Reply-To: <5CBA9427-AA70-4128-8E63-FB5027F144BD@sun.com> Message-Id: Sender: pgut001 Date: Sat, 25 Apr 2009 18:01:59 +1200 Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2009 06:01:39 -0000 Vipul Gupta writes: >p.s. For those unfamiliar with the performance advantages of ECC public key >cryptography, especially at these higher key sizes, several papers are >available at http://research.sun.com/projects/crypto. There's also Wei Dai's benchmarks at http://www.cryptopp.com/benchmarks.html, where are considerably less rosy. In particular client-side RSA runs circles around client-side ECC crypto. Peter. From ngm@google.com Tue Apr 28 17:24:05 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A85E3A6B5D for ; Tue, 28 Apr 2009 17:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO9jvQIKSGmZ for ; Tue, 28 Apr 2009 17:24:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id EE2EB3A693A for ; Tue, 28 Apr 2009 17:24:02 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id n3T0PM34025217 for ; Wed, 29 Apr 2009 01:25:23 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1240964723; bh=OrzvLTcN/9Cwxr8EoWETMlp1b/8=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=f bW/MH/ckjLivIjQ8aGerEzmZr7vnHfRJeAkxl+PrgXih5IKPlqcCKML0+WQQRRNnPz2 8D/6uCfQm8Bch0SiDA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=YBKXNWMffrQr6Ao5NFDVLN8aMRrzeF3kdCALnffLF3+YwY2oovP9QgEOiPBGDjAfH EupXEzYF1kbPAAiW/I/RA== Received: from qw-out-2122.google.com (qwe3.prod.google.com [10.241.194.3]) by wpaz24.hot.corp.google.com with ESMTP id n3T0PKFh029412 for ; Tue, 28 Apr 2009 17:25:20 -0700 Received: by qw-out-2122.google.com with SMTP id 3so670968qwe.7 for ; Tue, 28 Apr 2009 17:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.83.146 with SMTP id f18mr4335399qcl.41.1240964720499; Tue, 28 Apr 2009 17:25:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Apr 2009 17:25:20 -0700 Message-ID: <28425e380904281725g75407fcj823bf9e7d83421b3@mail.gmail.com> From: Nagendra Modadugu To: Stefan Santesson Content-Type: multipart/alternative; boundary=0016364274db581e670468a69d5b X-System-Of-Record: true Cc: TLS wg Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2009 00:37:04 -0000 --0016364274db581e670468a69d5b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm joining the discussion a little bit late. Is there still time to consider 1-RTT version of the full-handshake described in "Fast-Track" paper? (i.e. client sends the ClientKeyExchange message speculatively befor= e receiving the ServerHello). - nagendra 2009/3/4 Stefan Santesson > As a result of the discussions we had around last IETF I have now posted > a new =93Fast Track=94 inspired draft. > > The name of this draft is draft-santesson-tls-certcache-00 > It will be available in a few days from the I-D repository. Until then it > can be obtained from the staging site at: > http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.= txt > > I have chosen to do a completely new draft instead of updating the old > fast-track document as I have used a very simplified approach as starting > point. > My document is limited to one new TLS extension with the sole purpose of > including a hash of a cached cert path to allow this cert path to be omit= ted > from the server Certificate message. > > I submitted this draft to inject some energy into the discussion again bu= t > I=92m not locked on the approach if there are good reasons to expand it. > Please read and provide comments. > > I would like to request a small time slot on the TLS meeting agenda in Sa= n > Francisco to discuss this if possible. > > > *Stefan Santesson > *AAA-sec.com > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0016364274db581e670468a69d5b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'm joining the discussion a little bit late.=A0 Is there still tim= e to consider 1-RTT version of the full-handshake described in "Fast-T= rack" paper? (i.e. client sends the ClientKeyExchange message speculat= ively before receiving the ServerHello).

- nagendra

2009/3/4 Stefan Santesson = <stefans@exmsft.= com>
As a result of the discussions we had around last IETF I have now p= osted a new =93Fast Track=94 inspired draft.

The name of this draft is =A0draft-santesson-tls-c= ertcache-00
It will be available in a few days from the I-= D repository. Until then it can be obtained from the staging site at: http://www.ietf.org/proceedings/staging/draft-sa= ntesson-tls-certcache-00.txt

I have chosen to do a completely new draft instead of updating the old fast= -track document as I have used a very simplified approach as starting point= .
My document is limited to one new TLS extension with the sole purpose of in= cluding a hash of a cached cert path to allow this cert path to be omitted = from the server Certificate message.

I submitted this draft to inject some energy into the discussion again but = I=92m not locked on the approach if there are good reasons to expand it. Please read and provide comments.

I would like to request a small time slot on the TLS meeting agenda in San = Francisco to discuss this if possible.


Stefan Santesson
AAA-sec.com

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


--0016364274db581e670468a69d5b-- From Martin.Rex@sap.com Tue Apr 28 18:17:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFEB3A68EC for ; Tue, 28 Apr 2009 18:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.753 X-Spam-Level: X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtRblLhe+j7E for ; Tue, 28 Apr 2009 18:17:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0F5653A6811 for ; Tue, 28 Apr 2009 18:17:04 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n3T1EJYG011325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 03:14:19 +0200 (MEST) From: Martin Rex Message-Id: <200904290114.n3T1EI4h003479@fs4113.wdf.sap.corp> To: ngm+ietf@google.com (Nagendra Modadugu) Date: Wed, 29 Apr 2009 03:14:18 +0200 (MEST) In-Reply-To: <28425e380904281725g75407fcj823bf9e7d83421b3@mail.gmail.com> from "Nagendra Modadugu" at Apr 28, 9 05:25:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: stefans@exmsft.com, TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@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, 29 Apr 2009 01:17:06 -0000 Nagendra Modadugu wrote: > > I'm joining the discussion a little bit late. Is there still time to > consider 1-RTT version of the full-handshake described in "Fast-Track" > paper? (i.e. client sends the ClientKeyExchange message speculatively before > receiving the ServerHello). To me, this looks more like a flawed assumption rather than a "speculative action", because it is impossible to recover. The idea behind the short cuts is that the server can continue with the full handshake if the shortcut is not available for whatever reason. Sending a ClientKeyExchange based on assumptions what the contents of the ServerHello will be precludes the Server from making decisions to which it is entiteled in the original TLS protocol, and the result can easily be a fatal error, which means that the network communication channel must be closed and reopened -- a recovery at the TLS protocol level is impossible. Having the Client send (protected) application data optimistically following the Client Finished message without waiting for the Server Finished seems like an acceptable optimization if you badly need to cut down the number of round trips. Such an optimization, however, may have a significant impact on the semantics of SSL_connect for APIs like that of OpenSSL. -Martin From Pasi.Eronen@nokia.com Thu Apr 30 02:41:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AB73A68C3 for ; Thu, 30 Apr 2009 02:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyjaxy0jBr8P for ; Thu, 30 Apr 2009 02:41:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 39A3B3A6F45 for ; Thu, 30 Apr 2009 02:40:57 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3U9gBlS001437 for ; Thu, 30 Apr 2009 04:42:21 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 12:41:56 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 12:41:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 12:41:46 +0300 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Apr 2009 11:41:46 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 30 Apr 2009 11:41:46 +0200 From: To: Date: Thu, 30 Apr 2009 11:41:45 +0200 Thread-Topic: Decryption_failed alert in TLS 1.1 Thread-Index: AcnJd9/x9Jkejm7KQJi1qtPRd3WAYw== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24D50BE@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2009 09:41:46.0799 (UTC) FILETIME=[E0E253F0:01C9C977] X-Nokia-AV: Clean Subject: [TLS] Decryption_failed alert in TLS 1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 30 Apr 2009 09:41:19 -0000 Hi, I'm going through unverified errata for various SEC area RFCs, and came to errata ID 117 for RFC 4346 (TLS 1.1), available from here: http://www.rfc-editor.org/errata_search.php?rfc=3D4346 Currently, Section 7.2.2 of RFC 4346 says: bad_record_mac This alert is returned if a record is received with an incorrect MAC. This alert also MUST be returned if an alert is sent because a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values, when checked, weren't correct. This message is always fatal. and then continues: decryption_failed This alert MAY be returned if a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values, when checked, weren't correct. This message is always fatal. Note: Differentiating between bad_record_mac and decryption_failed alerts may permit certain attacks against CBC mode as used in TLS [CBCATT]. It is preferable to uniformly use the bad_record_mac alert to hide the specific type of the error. These two contradict each other; it first says "bad_record_mac MUST be sent", but then says decryption_failed "MAY be returned", and using bad_record_mac is "preferable". Does anyone recall what the intent here was? Early drafts (until -09)=20 said "bad_record_mac SHOULD be returned", but that was later changed=20 to "MUST". Should the errata fix this to something like this? decryption_failed This alert was used in TLS 1.0 if a TLSCiphertext decrypted in an invalid way. It MUST NOT be sent in TLS 1.1. (TLS 1.2 is very clear about this; decryption_failed MUST NOT be sent.) Best regards, Pasi From ekr@networkresonance.com Thu Apr 30 09:33:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BDE28C293 for ; Thu, 30 Apr 2009 09:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj0NxeG-4Qs3 for ; Thu, 30 Apr 2009 09:33:26 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 299E43A7228 for ; Thu, 30 Apr 2009 09:33:00 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 17D9A194FC4; Thu, 30 Apr 2009 09:37:27 -0700 (PDT) Date: Thu, 30 Apr 2009 09:37:26 -0700 From: Eric Rescorla To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F24D50BE@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F24D50BE@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090430163727.17D9A194FC4@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Decryption_failed alert in TLS 1.1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 30 Apr 2009 16:33:27 -0000 At Thu, 30 Apr 2009 11:41:45 +0200, wrote: > > Hi, > > I'm going through unverified errata for various SEC area RFCs, > and came to errata ID 117 for RFC 4346 (TLS 1.1), available > from here: > > http://www.rfc-editor.org/errata_search.php?rfc=4346 > > Currently, Section 7.2.2 of RFC 4346 says: > > bad_record_mac > This alert is returned if a record is received with an incorrect > MAC. This alert also MUST be returned if an alert is sent because > a TLSCiphertext decrypted in an invalid way: either it wasn't an > even multiple of the block length, or its padding values, when > checked, weren't correct. This message is always fatal. > > and then continues: > > decryption_failed > This alert MAY be returned if a TLSCiphertext decrypted in an > invalid way: either it wasn't an even multiple of the block > length, or its padding values, when checked, weren't correct. > This message is always fatal. > > Note: Differentiating between bad_record_mac and decryption_failed > alerts may permit certain attacks against CBC mode as used in > TLS [CBCATT]. It is preferable to uniformly use the > bad_record_mac alert to hide the specific type of the error. > > These two contradict each other; it first says "bad_record_mac MUST be > sent", but then says decryption_failed "MAY be returned", and using > bad_record_mac is "preferable". > > Does anyone recall what the intent here was? Early drafts (until -09) > said "bad_record_mac SHOULD be returned", but that was later changed > to "MUST". Should the errata fix this to something like this? > > decryption_failed > This alert was used in TLS 1.0 if a TLSCiphertext decrypted > in an invalid way. It MUST NOT be sent in TLS 1.1. > > (TLS 1.2 is very clear about this; decryption_failed MUST NOT > be sent.) Yeah, I think we just did s/SHOULD/MUST/ and didn't remove the corresponding MAY -Ekr From frantz@pwpconsult.com Thu Apr 30 18:54:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355EC3A6DFF for ; Thu, 30 Apr 2009 18:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq-6by3JAs5s for ; Thu, 30 Apr 2009 18:54:09 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 394613A67E6 for ; Thu, 30 Apr 2009 18:54:09 -0700 (PDT) Received: from [173.75.83.140] (helo=[192.168.1.5]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzhyO-0005Ku-7t for tls@ietf.org; Thu, 30 Apr 2009 21:55:32 -0400 Date: Thu, 30 Apr 2009 18:56:35 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <20090423185550.GW1500@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79017bfb47d147a765635d6ea5925a7b3c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.140 Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 01 May 2009 01:54:10 -0000 Nicolas.Williams@sun.com (Nicolas Williams) on Thursday, April 23, 2009 wro= te: >The more likely explanation is that *some* imaginable >cryptanalytic advances could reduce the effective strength of AES in >such a way that longer keys remain more secure than shorter keys. When I think of the reasons that NSA/DOD could have for requiring AES-128 for secret and AES-192 for top secret, I think they may be looking at the whole cryptographic system. While symmetric cyphers have some solid math behind them, other parts of the system, such as generating random numbers for the keys are frequently more akin to black magic. If my random numbers were only 75% random against some attack, with AES-192 I would still have 128 bits of strength against a brute force attack. With AES-128, I'd only have 96 bits, and I would be quite concerned when protecting top secret data. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it?" -- Marcus Ranum From ekr@networkresonance.com Thu Apr 30 22:45:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC84A3A6B4F for ; Thu, 30 Apr 2009 22:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCVk3JUCmjzl for ; Thu, 30 Apr 2009 22:45:39 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id D37D73A6AA7 for ; Thu, 30 Apr 2009 22:45:38 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3857D19668A; Thu, 30 Apr 2009 22:50:09 -0700 (PDT) Date: Thu, 30 Apr 2009 22:50:08 -0700 From: Eric Rescorla To: Bill Frantz In-Reply-To: References: <20090423185550.GW1500@Sun.COM> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090501055009.3857D19668A@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Comparative cipher suite strengths X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 01 May 2009 05:45:40 -0000 At Thu, 30 Apr 2009 18:56:35 -0700, Bill Frantz wrote: > > Nicolas.Williams@sun.com (Nicolas Williams) on Thursday, April 23, 2009 wrote: > > >The more likely explanation is that *some* imaginable > >cryptanalytic advances could reduce the effective strength of AES in > >such a way that longer keys remain more secure than shorter keys. > > When I think of the reasons that NSA/DOD could have for requiring AES-128 > for secret and AES-192 for top secret, I think they may be looking at the > whole cryptographic system. While symmetric cyphers have some solid math > behind them, other parts of the system, such as generating random numbers > for the keys are frequently more akin to black magic. > > If my random numbers were only 75% random against some attack, with AES-192 > I would still have 128 bits of strength against a brute force attack. With > AES-128, I'd only have 96 bits, and I would be quite concerned when > protecting top secret data. I don't think this lines up particularly well with how CSPRNGs work. You start with some random seed information S which you use to seed the CSPRNG. That seed has some number of bits of entropy. Call it E. You then generate your cryptographic key. No matter how long that key is, the total strength of the system is the cost of brute-forcing S, i.e., 2^E operations. This is true whether the symmetric cipher is 128 bits or 256 bits. -Ekr