From tls-bounces@lists.ietf.org Mon Oct 01 17:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcT3H-0000l8-GB; Mon, 01 Oct 2007 17:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcT3F-0000jn-IQ for tls@ietf.org; Mon, 01 Oct 2007 17:43:41 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcT3D-0004MV-U5 for tls@ietf.org; Mon, 01 Oct 2007 17:43:41 -0400 Received: (qmail 19669 invoked by uid 0); 1 Oct 2007 21:43:26 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 1 Oct 2007 21:43:26 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Oct 2007 17:43:31 -0400 To: ipsec@ietf.org,ietf-smime@imc.org,tls@ietf.org From: The IESG (by way of Russ Housley ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [TLS] Last Call: draft-lepinski-dh-groups (Additional Diffie-Hellman Groups for use with IETF Standards) to Informational RFC X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Message-Id: The IESG has received a request from an individual submitter to consider the following document: - 'Additional Diffie-Hellman Groups for use with IETF Standards ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 03 18:46:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCwD-0001B7-Di; Wed, 03 Oct 2007 18:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCwC-0001B1-9r for tls@ietf.org; Wed, 03 Oct 2007 18:43:28 -0400 Received: from smtp-out.google.com ([216.239.45.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdCw6-0005OR-2Y for tls@ietf.org; Wed, 03 Oct 2007 18:43:28 -0400 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id l93Mh5IV002736 for ; Wed, 3 Oct 2007 15:43:06 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject: in-reply-to:mime-version:content-type: content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kKYR1KRLK2ryR9X9A5BxeFFnIS3aaLzOmtM026LAvTt4PdO+AL9ZpzlOMoo2kVqan +YdqyHzuTu09NoRPLOB/A== Received: from nf-out-0910.google.com (nfdb21.prod.google.com [10.48.129.21]) by zps75.corp.google.com with ESMTP id l93MgOBp022018 for ; Wed, 3 Oct 2007 15:43:02 -0700 Received: by nf-out-0910.google.com with SMTP id b21so3317291nfd for ; Wed, 03 Oct 2007 15:43:02 -0700 (PDT) Received: by 10.86.78.4 with SMTP id a4mr973347fgb.1191451382308; Wed, 03 Oct 2007 15:43:02 -0700 (PDT) Received: by 10.86.73.14 with HTTP; Wed, 3 Oct 2007 15:43:02 -0700 (PDT) Message-ID: <28425e380710031543i28a1274bl6cf25fd270ed3c2d@mail.gmail.com> Date: Wed, 3 Oct 2007 15:43:02 -0700 From: "Nagendra Modadugu" To: tls@ietf.org In-Reply-To: <28425e380710031503x4c26b1b1r97b9f18fa8892787@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28425e380710031503x4c26b1b1r97b9f18fa8892787@mail.gmail.com> X-Google-Sender-Auth: 2b21766c39d0f085 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [TLS] comments & clarifications for rfc4507bis X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Apologies if the points below have been previously addressed. The comments below are in reference to the version of the draft dated August 27, 2007. S3.3: The server MUST NOT assume that the client actually received the updated ticket until it successfully verifies the client's Finished message. This text seems incorrect. The full-handshake case is actually a bit awkward, since the server cannot assume that the ticket has been received (by the client) until application data is received from the client. S3.4: If a server is planning on issuing a SessionTicket to a client that does not present one, it SHOULD include an empty Session ID in the ServerHello. If the server includes a non-empty session ID, then it is indicating intent to use stateful session resume. If the client receives a SessionTicket from the server, then it discards any Session ID that was sent in the ServerHello. Why are servers afforded the flexibility of simultaneously including an extension and session ID? Or differently put, why should a server ever need to generate a session ID if it intends to do stateless resumes? (Session IDs generated by the server will be discarded by the client in any case.) S3.4: In this case, the client ignores the Session ID sent in the ServerHello ... "the Session ID" -> "the Session ID (whether empty or non-empty)" S3.4: If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake. What if the server rejects the ticket in this case? It seems reasonable that the server responds with an empty session ID to indicate to the client that a full-handshake is being initiated. Thanks, nagendra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 04 16:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXDZ-0002Pm-Bo; Thu, 04 Oct 2007 16:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXDY-0002E2-65 for tls@ietf.org; Thu, 04 Oct 2007 16:22:44 -0400 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXDH-0006dq-NU for tls@ietf.org; Thu, 04 Oct 2007 16:22:34 -0400 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id l94KLmbK032477 for ; Thu, 4 Oct 2007 21:21:49 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject: in-reply-to:mime-version:content-type: content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UAIkUVv8IwKRsccckdY1Oc8ZyNICd6A3z5TJM5Bs1EkZE3A29qS+ZIdpgb4Slqd6x l04fZUbuxckCaTJHQAfcA== Received: from nf-out-0910.google.com (nfdc10.prod.google.com [10.48.130.10]) by zps19.corp.google.com with ESMTP id l94KLZaq023054 for ; Thu, 4 Oct 2007 13:21:47 -0700 Received: by nf-out-0910.google.com with SMTP id c10so232630nfd for ; Thu, 04 Oct 2007 13:21:47 -0700 (PDT) Received: by 10.86.57.9 with SMTP id f9mr1822257fga.1191529306726; Thu, 04 Oct 2007 13:21:46 -0700 (PDT) Received: by 10.86.73.14 with HTTP; Thu, 4 Oct 2007 13:21:46 -0700 (PDT) Message-ID: <28425e380710041321w3eb15158o5ba9d2e2157e6766@mail.gmail.com> Date: Thu, 4 Oct 2007 13:21:46 -0700 From: "Nagendra Modadugu" To: tls@ietf.org In-Reply-To: <28425e380710041156s2a9e3c32vee0d1d612381daaa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28425e380710031503x4c26b1b1r97b9f18fa8892787@mail.gmail.com> <28425e380710031543i28a1274bl6cf25fd270ed3c2d@mail.gmail.com> <28425e380710041156s2a9e3c32vee0d1d612381daaa@mail.gmail.com> X-Google-Sender-Auth: 059df9aaabd40818 X-Spam-Score: -4.3 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [TLS] comments & clarifications for rfc4507bis X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org A few more comments: S3.1: The client caches this ticket along with the master secret and other parameters associated with the current session. When the client wishes to resume the session, it includes the ticket in the SessionTicket extension within the ClientHello message. The text is not clear what "includes the ticket" refers to. It could either mean the entire NewSessionTicket message, or just NewSessionTicket.ticket. The client does not need to echo back NewSessionTicket.ticket_lifetime_hint, so it is not obvious which of the two meanings is implied. The description would be unabiguous if the text included a struct along the lines of: struct { opaque NewSessionTicket.ticket<1..2^16-1> } SessionTicket; S4: enum { anonymous(0), certificate_based(1), psk(2), + (255) } ClientAuthenticationType; On 10/3/07, Nagendra Modadugu wrote: > Apologies if the points below have been previously addressed. The > comments below are in reference to the version of the draft dated > August 27, 2007. > > S3.3: The server MUST NOT assume that the client actually received the updated > ticket until it successfully verifies the client's Finished > message. > > This text seems incorrect. The full-handshake case is actually a bit > awkward, since the server cannot assume that the ticket has been > received (by the client) until application data is received from the client. > > S3.4: If a server is planning on issuing a SessionTicket to a client > that does not present one, it SHOULD include an empty Session ID in the > ServerHello. If the server includes a non-empty session ID, then it > is indicating intent to use stateful session resume. If the client > receives a SessionTicket from the server, then it discards any > Session ID that was sent in the ServerHello. > > Why are servers afforded the flexibility of simultaneously including an > extension and session ID? Or differently put, why should a server ever > need to generate a session ID if it intends to do stateless resumes? > (Session IDs generated by the server will be discarded by the client in > any case.) > > S3.4: In this case, the client ignores the Session ID sent in > the ServerHello ... > > "the Session ID" -> "the Session ID (whether empty or non-empty)" > > S3.4: If the server accepts the ticket and the Session ID is not empty, > then it MUST respond with the same Session ID present in the > ClientHello. This allows the client to easily differentiate when > the server is resuming a session from when it is falling back to a > full handshake. > > What if the server rejects the ticket in this case? It seems > reasonable that the server responds with an empty session ID to > indicate to the client that a full-handshake is being initiated. > > Thanks, > nagendra > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 05 18:26:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdvZz-00033r-UP; Fri, 05 Oct 2007 18:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdvZy-00032X-Er for tls@ietf.org; Fri, 05 Oct 2007 18:23:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdvZx-00071W-20 for tls@ietf.org; Fri, 05 Oct 2007 18:23:30 -0400 X-IronPort-AV: E=Sophos;i="4.21,237,1188802800"; d="scan'208";a="231500982" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Oct 2007 15:23:28 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l95MNSYY006258; Fri, 5 Oct 2007 15:23:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l95MNNqD025396; Fri, 5 Oct 2007 22:23: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, 5 Oct 2007 15:23:24 -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 Subject: RE: [TLS] comments & clarifications for rfc4507bis Date: Fri, 5 Oct 2007 15:23:32 -0700 Message-ID: In-Reply-To: <28425e380710041321w3eb15158o5ba9d2e2157e6766@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] comments & clarifications for rfc4507bis Thread-Index: AcgGxTj+Q/E6W74KQdSA0b5z/Rl6wgA2AHzg From: "Joseph Salowey (jsalowey)" To: "Nagendra Modadugu" , X-OriginalArrivalTime: 05 Oct 2007 22:23:24.0296 (UTC) FILETIME=[58044080:01C8079E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4912; t=1191623008; x=1192487008; 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]=20comments=20&=20clarifications=20for=20rfc4507 bis |Sender:=20; bh=4W2D/19LX8Q2HCE2IZUnp+uu4rld6aJ5KY6BqKvP+nI=; b=hkAExEyxPGdAO4xXCi/T3siiiwcXFn+B6JAuAY2CZ2L9/ZoG7nqo0eaSBaZPa/73dro/B0EH INIQ+MS353hUyOoZ9SmUrjzRwdzjh/BMlJfynGc+v7X/FWHxoPCdEUC7; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Nagendra, Thanks for reviewing the draft and providing comments: Comments inline below:=20 > -----Original Message----- > From: Nagendra Modadugu [mailto:ngm+ietf@google.com]=20 > Sent: Thursday, October 04, 2007 1:22 PM > To: tls@ietf.org > Subject: [TLS] comments & clarifications for rfc4507bis >=20 > A few more comments: >=20 > S3.1: The client caches this ticket along with the master secret and > other parameters associated with the current session. =20 > When the client > wishes to resume the session, it includes the ticket in the > SessionTicket extension within the ClientHello message. >=20 > The text is not clear what "includes the ticket" refers to. =20 > It could either mean the entire NewSessionTicket message, or=20 > just NewSessionTicket.ticket. The client does not need to=20 > echo back NewSessionTicket.ticket_lifetime_hint, so it is not=20 > obvious which of the two meanings is implied. The=20 > description would be unabiguous if the text included a struct=20 > along the lines of: >=20 > struct { > opaque NewSessionTicket.ticket<1..2^16-1> > } SessionTicket; >=20 >=20 [Joe] I would rather clarify this by saying: "When the client wishes to resume the session, it includes the ticket contained within the NewSessionTicket message, in the SessionTicket extension within the ClientHello message. " The new struct actually reintroduces an issue with encoding that we trying to correct with this revision. =20 > S4: > enum { > anonymous(0), > certificate_based(1), > psk(2), > + (255) > } ClientAuthenticationType; >=20 [Joe] OK, thanks, more below > On 10/3/07, Nagendra Modadugu wrote: > > Apologies if the points below have been previously addressed. The=20 > > comments below are in reference to the version of the draft dated=20 > > August 27, 2007. > > > > S3.3: The server MUST NOT assume that the client actually=20 > received the updated > > ticket until it successfully verifies the client's Finished > > message. > > > > This text seems incorrect. The full-handshake case is=20 > actually a bit=20 > > awkward, since the server cannot assume that the ticket has been=20 > > received (by the client) until application data is received=20 > from the client. > > [Joe] Ah, I see your point, the client sends its finished message before it receives the ticket. We should probably change this to "The server MUST NOT assume that the client actually received the updated ticket until it successfully receives application data from the client." =20 > > S3.4: If a server is planning on issuing a SessionTicket to a client > > that does not present one, it SHOULD include an empty=20 > Session ID in the > > ServerHello. If the server includes a non-empty=20 > session ID, then it > > is indicating intent to use stateful session resume. =20 > If the client > > receives a SessionTicket from the server, then it discards any > > Session ID that was sent in the ServerHello. > > > > Why are servers afforded the flexibility of simultaneously=20 > including=20 > > an extension and session ID? Or differently put, why=20 > should a server=20 > > ever need to generate a session ID if it intends to do=20 > stateless resumes? > > (Session IDs generated by the server will be discarded by=20 > the client=20 > > in any case.) > > [Joe] During discussions for RFC 4507 there was a desire to allow stateful resume during fallback to a full handshake. =20 > > S3.4: In this case, the client ignores the Session ID sent in > > the ServerHello ... > > > > "the Session ID" -> "the Session ID (whether empty or non-empty)" > > > > S3.4: If the server accepts the ticket and the Session ID=20 > is not empty, > > then it MUST respond with the same Session ID present in the > > ClientHello. This allows the client to easily=20 > differentiate when > > the server is resuming a session from when it is=20 > falling back to a > > full handshake. > > > > What if the server rejects the ticket in this case? It seems=20 > > reasonable that the server responds with an empty session ID to=20 > > indicate to the client that a full-handshake is being initiated. > > [Joe] If the server rejects the ticket and it is planning on issuing a new ticket then it SHOULD include an empty session ID. If the server rejects the ticket and does not plan to issue a new ticket then it MUST either include a different session ID or an empty session ID. A non-empty session ID allows for stateful session resume. =20 > > Thanks, > > nagendra > > >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 05 19:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwuP-0005Dw-6S; Fri, 05 Oct 2007 19:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwuN-0005DX-BR for tls@ietf.org; Fri, 05 Oct 2007 19:48:39 -0400 Received: from smtp-out.google.com ([216.239.45.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdwuA-0001rH-A1 for tls@ietf.org; Fri, 05 Oct 2007 19:48:34 -0400 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id l95Nlx79029424 for ; Fri, 5 Oct 2007 16:47:59 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject:cc: in-reply-to:mime-version:content-type: content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=KH3hrGNVtNvUgT4ya8qQ/Rxx788d5m9UUODlLWmaRoiofjpFMpz6i7GRb4Gb7u5gS GQkJ3fMiBNqQxH+hBt+GQ== Received: from mu-out-0910.google.com (muew8.prod.google.com [10.102.174.8]) by zps38.corp.google.com with ESMTP id l95Nlvh8022371 for ; Fri, 5 Oct 2007 16:47:58 -0700 Received: by mu-out-0910.google.com with SMTP id w8so894240mue for ; Fri, 05 Oct 2007 16:47:57 -0700 (PDT) Received: by 10.86.71.1 with SMTP id t1mr2874125fga.1191628077444; Fri, 05 Oct 2007 16:47:57 -0700 (PDT) Received: by 10.86.73.14 with HTTP; Fri, 5 Oct 2007 16:47:57 -0700 (PDT) Message-ID: <28425e380710051647m72ae0414na572730b63457e6@mail.gmail.com> Date: Fri, 5 Oct 2007 16:47:57 -0700 From: "Nagendra Modadugu" To: "Joseph Salowey (jsalowey)" Subject: Re: [TLS] comments & clarifications for rfc4507bis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28425e380710041321w3eb15158o5ba9d2e2157e6766@mail.gmail.com> X-Google-Sender-Auth: 1dd73a74ec149be2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 10/5/07, Joseph Salowey (jsalowey) wrote: > Hi Nagendra, > > Thanks for reviewing the draft and providing comments: > > Comments inline below: > > > -----Original Message----- > > From: Nagendra Modadugu [mailto:ngm+ietf@google.com] > > Sent: Thursday, October 04, 2007 1:22 PM > > To: tls@ietf.org > > Subject: [TLS] comments & clarifications for rfc4507bis > > > > A few more comments: > > > > S3.1: The client caches this ticket along with the master secret and > > other parameters associated with the current session. > > When the client > > wishes to resume the session, it includes the ticket in the > > SessionTicket extension within the ClientHello message. > > > > The text is not clear what "includes the ticket" refers to. > > It could either mean the entire NewSessionTicket message, or > > just NewSessionTicket.ticket. The client does not need to > > echo back NewSessionTicket.ticket_lifetime_hint, so it is not > > obvious which of the two meanings is implied. The > > description would be unabiguous if the text included a struct > > along the lines of: > > > > struct { > > opaque NewSessionTicket.ticket<1..2^16-1> > > } SessionTicket; > > > > > [Joe] I would rather clarify this by saying: > > "When the client wishes to resume the session, it includes the ticket > contained within the NewSessionTicket message, in the SessionTicket > extension within the ClientHello message. " > > The new struct actually reintroduces an issue with encoding that we > trying to correct with this revision. > The text (even the correction you suggest) is not unambiguous about what the 'the ticket' constitutes. Is it a length encoded vector NewSessionTicket.ticket or the serialized structure embedded within? I'm not familiar with what the previous draft specified, but I assume you mean the latter. Could you clarify? I'm afraid that leaving this portion of the description in textual form may lead to implementation bugs -- it would be nice to see a struct. > > S4: > > enum { > > anonymous(0), > > certificate_based(1), > > psk(2), > > + (255) > > } ClientAuthenticationType; > > > [Joe] OK, thanks, more below > > > On 10/3/07, Nagendra Modadugu wrote: > > > Apologies if the points below have been previously addressed. The > > > comments below are in reference to the version of the draft dated > > > August 27, 2007. > > > > > > S3.3: The server MUST NOT assume that the client actually > > received the updated > > > ticket until it successfully verifies the client's Finished > > > message. > > > > > > This text seems incorrect. The full-handshake case is > > actually a bit > > > awkward, since the server cannot assume that the ticket has been > > > received (by the client) until application data is received > > from the client. > > > > [Joe] Ah, I see your point, the client sends its finished message before > it receives the ticket. We should probably change this to > > "The server MUST NOT assume that the client actually received the > updated ticket until it successfully receives application data from the > client." > > > > S3.4: If a server is planning on issuing a SessionTicket to a client > > > that does not present one, it SHOULD include an empty > > Session ID in the > > > ServerHello. If the server includes a non-empty > > session ID, then it > > > is indicating intent to use stateful session resume. > > If the client > > > receives a SessionTicket from the server, then it discards any > > > Session ID that was sent in the ServerHello. > > > > > > Why are servers afforded the flexibility of simultaneously > > including > > > an extension and session ID? Or differently put, why > > should a server > > > ever need to generate a session ID if it intends to do > > stateless resumes? > > > (Session IDs generated by the server will be discarded by > > the client > > > in any case.) > > > > [Joe] During discussions for RFC 4507 there was a desire to allow > stateful resume during fallback to a full handshake. > If this is the case then "it [server] SHOULD include an empty Session ID in the ServerHello" and "client ignores the Session ID sent in the ServerHello" are confusing. If the draft is recommending (for or) against simultaneously supporting stateful and stateless resumption, it should say so explicitly (noting that a server should be aware that clients supporting stateless resumption might not attempt stateful resumption.) Simultaneously supporting stateful and stateless resumption leads to some tricky situations which the draft does not address. Consider the following situation: Client C makes a TLS connection T1 to server S and receives session-ID SID1 and SessionTicket ST1. The client does another full handshake and receives SID2 and ST2. Now C makes a third connection to S, but this time attempting to resume, including session ID SID1 and SessionTicket ST2 (note this is the second SessionTicket received.) The server has a cache hit on SID1 and also finds that ST2 is valid. Which session does the server pick? What should the client infer about the server's choice? I'd like to add that this situation is not esoteric. A client implementation may have two hash tables (one of session IDs and other of SessionTickets.) It's pretty easy to end up mixing and matching. > > > S3.4: In this case, the client ignores the Session ID sent in > > > the ServerHello ... > > > > > > "the Session ID" -> "the Session ID (whether empty or non-empty)" > > > > > > S3.4: If the server accepts the ticket and the Session ID > > is not empty, > > > then it MUST respond with the same Session ID present in the > > > ClientHello. This allows the client to easily > > differentiate when > > > the server is resuming a session from when it is > > falling back to a > > > full handshake. > > > > > > What if the server rejects the ticket in this case? It seems > > > reasonable that the server responds with an empty session ID to > > > indicate to the client that a full-handshake is being initiated. > > > > [Joe] If the server rejects the ticket and it is planning on issuing a > new ticket then it SHOULD include an empty session ID. If the server This text does not preclude a server from (a) rejecting the ticket and (b) echoing the session ID sent by the client. Doing (b) is confusing for the client for the reasons described in the example above -- how does the client tell that the server has reject the ticket, but is instead doing a stateful resume (where the session ID and ticket refer to different sessions)? This problem could be addressed by saying something along the lines of: 'If a client receives a session ID along with a session ticket from a server, the client infers that the server supports both stateless and stateful resumption. Clients attempting stateless resumes SHOULD send empty session IDs. If a client attempting a stateless resume includes a session ID, then the session ID MUST be the same session ID that was issued along with the session ticket." Thanks, nagendra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 08 09:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesYq-0007Jv-9V; Mon, 08 Oct 2007 09:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesYo-0007JV-VC for tls@lists.ietf.org; Mon, 08 Oct 2007 09:22:14 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IesYi-0006qX-PD for tls@lists.ietf.org; Mon, 08 Oct 2007 09:22:14 -0400 Received: by ug-out-1314.google.com with SMTP id z38so763992ugc for ; Mon, 08 Oct 2007 06:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=Rpyizvm/Foy5xO0Qjy0yCvmKFtR4hvPvst8/b3kgLO8=; b=Egr+c3kE5e+l2k3bdX8UXXChx0hUEVJ2uWFNLzUQOHNpEUVCiuXagFKkFgxzWlzfkeo4/SfxET6pmvaILywQx2xNuaNrHb0SBW3/8m9ls1E62jbUK5J+3D6Nq2scQ9p17YMbtB0IXmObSZOw7HQ0uO94zyfFfudL5n/Bitmuzp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=RERE1vvAGytYCHl0HhIwX146TCmi+Koj0bCquqvXFlHy3LxmyjKPrn/TzRD5PNdX3xqe8ckeG9vBIJJuDkoROAVMtI74csmBs7faF0CbJ2KnpuxEdU9WDGF1BR0eOLTmbfXxL/h15/F8pFHQtlijvaxw9CHzCWmbz8hwdyQd934= Received: by 10.78.130.6 with SMTP id c6mr3957160hud.1191849702490; Mon, 08 Oct 2007 06:21:42 -0700 (PDT) Received: by 10.78.146.7 with HTTP; Mon, 8 Oct 2007 06:21:42 -0700 (PDT) Message-ID: Date: Mon, 8 Oct 2007 16:21:42 +0300 From: "Nikos Mavrogiannopoulos" To: tls@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 714f163f11231dcd X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [TLS] security levels for TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hello, It seems that in TLS the security level of a connection relies on several factors including the ciphersuite. In certificate authentication the certificate plays also a large factor in the security, and especially the public key of it, plus the signer's public key. This is not visible and neither understandable in everyday work with TLS by typical users. For example a browser connection to a site with a 512 bit RSA key that negotiated an 128 bit ciphersuite will not differ to a connection with a 2048 bit RSA key and the same ciphersuite, with regard to visible user data. This makes difficult for users to judge the security level of the connection and one must never assume that a user would understand what a 512 bit RSA key means. For this reason I think using some form of uniform security levels to indicated TLS security would be useful in end-applications. Those levels could be defined in steps (as in [0]), based on objective information of the key sizes in the certificates, the DHE prime and generator sizes (if applicable), the MAC output size of the ciphersuite as well as the key size of the cipher. Then the security level could be printed either as a number (70 bits of security) or as "weak, low, medium, high" based on some definitions of these terms... I could make it more detailed if there is some interest. What do you think? regards, Nikos [0]. "Practical Cryptography", Fergunson, Schneier _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 08 11:38:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieuer-0004K7-5b; Mon, 08 Oct 2007 11:36:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieueq-0004Hm-5a for tls@lists.ietf.org; Mon, 08 Oct 2007 11:36:36 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieueh-0002dh-RO for tls@lists.ietf.org; Mon, 08 Oct 2007 11:36:36 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DAEBB33C21; Mon, 8 Oct 2007 08:32:18 -0700 (PDT) Date: Mon, 08 Oct 2007 08:32:18 -0700 From: Eric Rescorla To: "Nikos Mavrogiannopoulos" Subject: Re: [TLS] security levels for TLS In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071008153218.DAEBB33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Mon, 8 Oct 2007 16:21:42 +0300, Nikos Mavrogiannopoulos wrote: > > Hello, > It seems that in TLS the security level of a connection relies on > several factors including the ciphersuite. In certificate > authentication the certificate plays also a large factor in the > security, and especially the public key of it, plus the signer's > public key. > > This is not visible and neither understandable in everyday work with > TLS by typical users. For example a browser connection to a site with > a 512 bit RSA key that negotiated an 128 bit ciphersuite will not > differ to a connection with a 2048 bit RSA key and the same > ciphersuite, with regard to visible user data. This makes difficult > for users to judge the security level of the connection and one must > never assume that a user would understand what a 512 bit RSA key > means. > > For this reason I think using some form of uniform security levels to > indicated TLS security would be useful in end-applications. Those > levels could be defined in steps (as in [0]), based on objective > information of the key sizes in the certificates, the DHE prime and > generator sizes (if applicable), the MAC output size of the > ciphersuite as well as the key size of the cipher. > > Then the security level could be printed either as a number (70 bits > of security) or as "weak, low, medium, high" based on some definitions > of these terms... I could make it more detailed if there is some > interest. What do you think? I think this is something that the TLS WG should avoid getting involved in. 1. It's not really possible to come up with a single figure of merit in an uncontroversial way. To take the simplest possible case, what security level should we assign to TLS_RSA_WITH_NULL_SHA1 when the key is 1024 bits? What's the security level of TLS_RSA_DHE_* when the RSA key is 1024 bits and the DH key is 512? How about the other way around? 2. These numbers change over time as attacks get better. Unfortunately, those changes aren't straightforward. For instance, it's not really that easy to assess the security of HMAC-MD5 right now, especially if the question you're interested in asking is how secure it will be in a year (and the horizon you'd need to be thinking about is more like 5 years). 3. It seems likely that once you get past a fairly modest algorithm strength (40 bits? 64 bits?) the dominant security predictor about a given system is implementation quality (remotely exploitable vulns, RNG quality, ...), not algorithm strength. I don't know how to assess that. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 08 12:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevGD-000571-Kh; Mon, 08 Oct 2007 12:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevGC-00055Z-Fy for tls@lists.ietf.org; Mon, 08 Oct 2007 12:15:12 -0400 Received: from fk-out-0910.google.com ([209.85.128.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IevG0-0003f4-BP for tls@lists.ietf.org; Mon, 08 Oct 2007 12:15:08 -0400 Received: by fk-out-0910.google.com with SMTP id z22so1535968fkz for ; Mon, 08 Oct 2007 09:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=7YROxN+fD5484y4vTNnVc0xJKfIx+M2CxK/CPptpq7M=; b=RBPY4dkPnxiDKU/sUVAt2FjTn1QNj1KXng9MKeFz0TRp9FTUONFq1jG9BtBdQs5FqAAB9XYLZ+rqLOBq2Ha5fGnjE7uO3TYaLlrEo1x0ulY8nFB0wT70wcgq3BLSGp6DyduSQCVxZwdrzcWkat8eqUmCJgS6xby1zA4zwToB2Zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=XmDaq4We9kmKZn0wqPDDey2q+6XD81ILHl2ViySzwPY+/JlZ0eLySfnS8TQMnWvGc7Ac1erfsH69LKnKKdgf4NHpefqCEg1ZKjcQthmfJFfRMqcdbPlqIm28PjTce4KJ5deBCXMlHfZnIDx6Gh2kpKL7AhJKjWJ2IrcjMfOs/78= Received: by 10.82.106.14 with SMTP id e14mr5760846buc.1191860075952; Mon, 08 Oct 2007 09:14:35 -0700 (PDT) Received: from crystal.lan ( [77.49.221.115]) by mx.google.com with ESMTPS id j9sm13315158mue.2007.10.08.09.14.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2007 09:14:34 -0700 (PDT) From: Nikos Mavrogiannopoulos To: Eric Rescorla Subject: Re: [TLS] security levels for TLS Date: Mon, 8 Oct 2007 19:14:28 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071008153218.DAEBB33C21@delta.rtfm.com> In-Reply-To: <20071008153218.DAEBB33C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710081914.29437.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Monday 08 October 2007, Eric Rescorla wrote: > I think this is something that the TLS WG should avoid getting involved > in. I do agree that there is a lot of complexity in this issue, but the TLS WG is the only WG that could do this at least for TLS. > 1. It's not really possible to come up with a single figure of merit > in an uncontroversial way. To take the simplest possible case, what > security level should we assign to TLS_RSA_WITH_NULL_SHA1 when the > key is 1024 bits? What's the security level of TLS_RSA_DHE_* > when the RSA key is 1024 bits and the DH key is 512? How about > the other way around? This cannot be 100% objective by definition, but it can be based on a rational process. Of course the security level of those cryptosystems should be calculated using the weakest of the used algorithms. I've thought about that while reading "Selecting cryptographic key sizes" (available at http://www.win.tue.nl/~klenstra/key.pdf) Which gives an answer to your questions above. > 2. These numbers change over time as attacks get better. Unfortunately, > those changes aren't straightforward. For instance, it's not > really that easy to assess the security of HMAC-MD5 right now, > especially if the question you're interested in asking is how > secure it will be in a year (and the horizon you'd need to be > thinking about is more like 5 years). I'm not talking about assessing individual algorithms, but rather give an estimation of security based on objective facts as the key size etc. Of course one cannot give precise security levels. > 3. It seems likely that once you get past a fairly modest algorithm > strength (40 bits? 64 bits?) the dominant security predictor > about a given system is implementation quality (remotely exploitable > vulns, RNG quality, ...), not algorithm strength. I don't know how > to assess that. Indeed, but having at least an estimation of security based on some objective factor I think it is a good step forward. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 08 12:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevQp-0006X3-30; Mon, 08 Oct 2007 12:26:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevQn-0006Wx-Qw for tls@lists.ietf.org; Mon, 08 Oct 2007 12:26:09 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IevQm-00044g-Jc for tls@lists.ietf.org; Mon, 08 Oct 2007 12:26:09 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5788B33C21; Mon, 8 Oct 2007 09:22:08 -0700 (PDT) Date: Mon, 08 Oct 2007 09:22:07 -0700 From: Eric Rescorla To: Nikos Mavrogiannopoulos Subject: Re: [TLS] security levels for TLS In-Reply-To: <200710081914.29437.nmav@gnutls.org> References: <20071008153218.DAEBB33C21@delta.rtfm.com> <200710081914.29437.nmav@gnutls.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071008162208.5788B33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Mon, 8 Oct 2007 19:14:28 +0300, Nikos Mavrogiannopoulos wrote: > > On Monday 08 October 2007, Eric Rescorla wrote: > > > I think this is something that the TLS WG should avoid getting involved > > in. > I do agree that there is a lot of complexity in this issue, but the > TLS WG is the only WG that could do this at least for TLS. Yes, but just because we are the only ones who could do it does not mean that we should? > > 1. It's not really possible to come up with a single figure of merit > > in an uncontroversial way. To take the simplest possible case, what > > security level should we assign to TLS_RSA_WITH_NULL_SHA1 when the > > key is 1024 bits? What's the security level of TLS_RSA_DHE_* > > when the RSA key is 1024 bits and the DH key is 512? How about > > the other way around? > > This cannot be 100% objective by definition, but it can be based on a rational > process. Of course the security level of those cryptosystems should be > calculated using the weakest of the used algorithms. So, the security level of null encryption is 0 because the weakest algorithm (the confidentiality algorithm) has a zero-length key? If that's so, what's the security level of an X.509 certificate signed with a 1024-bit RSA key. That doesn't offer any confidentiality either. > I've thought about that while reading "Selecting cryptographic key sizes" > (available at http://www.win.tue.nl/~klenstra/key.pdf) > Which gives an answer to your questions above. I'm familiar with this work. It does not answer my questions above, and the reason it does not is that they are questions that depend critically on the operational environment and the threat model. Cryptosecurity is about a lot more than key size. > > 2. These numbers change over time as attacks get better. Unfortunately, > > those changes aren't straightforward. For instance, it's not > > really that easy to assess the security of HMAC-MD5 right now, > > especially if the question you're interested in asking is how > > secure it will be in a year (and the horizon you'd need to be > > thinking about is more like 5 years). > > I'm not talking about assessing individual algorithms, but rather give an > estimation of security based on objective facts as the key size etc. Of > course one cannot give precise security levels. So, HMAC-CRC with a key size of 1000 bits would have what security level in this scheme? > > 3. It seems likely that once you get past a fairly modest algorithm > > strength (40 bits? 64 bits?) the dominant security predictor > > about a given system is implementation quality (remotely exploitable > > vulns, RNG quality, ...), not algorithm strength. I don't know how > > to assess that. > > Indeed, but having at least an estimation of security based on some objective > factor I think it is a good step forward. I don't. When most of the variance is in some other factor, then measuring security of whatever factor you happen to be able to measure is extremely misleading. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 08 14:44:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexZK-00043T-JD; Mon, 08 Oct 2007 14:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexZJ-00043J-Mx for tls@lists.ietf.org; Mon, 08 Oct 2007 14:43:05 -0400 Received: from mail.opera.com ([213.236.208.66] helo=mailbox.opera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IexZD-0000TD-Bg for tls@lists.ietf.org; Mon, 08 Oct 2007 14:43:05 -0400 Received: from killashandra-ii.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) by mailbox.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l98IgcBM002631; Mon, 8 Oct 2007 18:42:38 GMT Date: Mon, 08 Oct 2007 20:42:09 +0200 To: "Nikos Mavrogiannopoulos" , tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.21 (Win32) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yngve@opera.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: , Errors-To: tls-bounces@lists.ietf.org On Mon, 08 Oct 2007 15:21:42 +0200, Nikos Mavrogiannopoulos wrote: > Hello, > It seems that in TLS the security level of a connection relies on > several factors including the ciphersuite. In certificate > authentication the certificate plays also a large factor in the > security, and especially the public key of it, plus the signer's > public key. > > This is not visible and neither understandable in everyday work with > TLS by typical users. For example a browser connection to a site with > a 512 bit RSA key that negotiated an 128 bit ciphersuite will not > differ to a connection with a 2048 bit RSA key and the same > ciphersuite, with regard to visible user data. This makes difficult > for users to judge the security level of the connection and one must > never assume that a user would understand what a 512 bit RSA key > means. > > For this reason I think using some form of uniform security levels to > indicated TLS security would be useful in end-applications. Those > levels could be defined in steps (as in [0]), based on objective > information of the key sizes in the certificates, the DHE prime and > generator sizes (if applicable), the MAC output size of the > ciphersuite as well as the key size of the cipher. > > Then the security level could be printed either as a number (70 bits > of security) or as "weak, low, medium, high" based on some definitions > of these terms... I could make it more detailed if there is some > interest. What do you think? Opera has been using a multi-level security indicator since we implemented SSL, the value of which is determined by input such as the symmetric keylengths, the public keys used in the certificate chain and the key exchange, OCSP results, certificate warnings, etc. We also display warnings if the strength of a method is less than we consider reasonably secure (at the moment, in 9.5 alpha, the limit for RSA/DH(E)/DSA is 900 bits, but this can be increased in 100 bit steps by a preference). Our position is that the weakest method defines the strength of a connection and a document, which for example means that we consider a AES-256 connection weak if one of the certificates use a 512 bit RSA key, or if a 2048 bit RSA key is used to secure a 56 bit DES connection. The W3C Web Security Context (WSC) Working Group is presently considering at least one proposal [1] for how an improved security indicator can be defined, as well as numerous other issues in the area. For more informations please see: Opera's system: (related) W3C WSC WG: [1] -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 08 18:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If0td-0003SW-Pm; Mon, 08 Oct 2007 18:16:17 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1If0tc-0003RS-MM for tls-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 18:16:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If0tc-0003RG-Cj for tls@ietf.org; Mon, 08 Oct 2007 18:16:16 -0400 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If0tW-0006Wj-2R for tls@ietf.org; Mon, 08 Oct 2007 18:16:16 -0400 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id l98MFOM5032161 for ; Mon, 8 Oct 2007 23:15:25 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject: in-reply-to:mime-version:content-type: content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZlpYnOvsdoWcfMFz+WcU7W5+VXBg+R3oFVeFocmHd7SUQ8SBLOH4M1IP/XLuKFsnL Zupp+UOGWEoubyoAQpQdg== Received: from ug-out-1314.google.com (ugeo4.prod.google.com [10.66.166.4]) by zps38.corp.google.com with ESMTP id l98MFNG5014594 for ; Mon, 8 Oct 2007 15:15:23 -0700 Received: by ug-out-1314.google.com with SMTP id o4so12078uge for ; Mon, 08 Oct 2007 15:15:23 -0700 (PDT) Received: by 10.66.220.12 with SMTP id s12mr62071ugg.1191881722750; Mon, 08 Oct 2007 15:15:22 -0700 (PDT) Received: by 10.67.24.14 with HTTP; Mon, 8 Oct 2007 15:15:22 -0700 (PDT) Message-ID: <28425e380710081515t6b78d005m8552bf8d867d628b@mail.gmail.com> Date: Mon, 8 Oct 2007 15:15:22 -0700 From: "Nagendra Modadugu" To: tls@ietf.org In-Reply-To: <28425e380710041156s2a9e3c32vee0d1d612381daaa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28425e380710031503x4c26b1b1r97b9f18fa8892787@mail.gmail.com> <28425e380710031543i28a1274bl6cf25fd270ed3c2d@mail.gmail.com> <28425e380710041156s2a9e3c32vee0d1d612381daaa@mail.gmail.com> X-Google-Sender-Auth: ae8bdafd639c2579 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [TLS] Re: comments & clarifications for rfc4507bis X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org One more comment: S3.3: The value indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order. Is 'lifetime' relative (e.g. 10 hours = 10 * 3600) or absolute, e.g. in seconds since UTC? It would make sense that NewSessionTicket.ticket_lifetime_hint is relative (to avoid the effects of clock-skew between the server and client.) The text would be clearer if it were explicit about the meaning of 'lifetime'. On 10/4/07, Nagendra Modadugu wrote: > A few more comments: > > S3.1: The client caches this ticket along with the master secret and > other parameters associated with the current session. When the client > wishes to resume the session, it includes the ticket in the > SessionTicket extension within the ClientHello message. > > The text is not clear what "includes the ticket" refers to. It could > either mean the entire NewSessionTicket message, or just > NewSessionTicket.ticket. The client does not need to echo back > NewSessionTicket.ticket_lifetime_hint, so it is not obvious which of > the two meanings is implied. The description would be unabiguous if > the text included a struct along the lines of: > > struct { > opaque NewSessionTicket.ticket<1..2^16-1> > } SessionTicket; > > > S4: > enum { > anonymous(0), > certificate_based(1), > psk(2), > + (255) > } ClientAuthenticationType; > > On 10/3/07, Nagendra Modadugu wrote: > > Apologies if the points below have been previously addressed. The > > comments below are in reference to the version of the draft dated > > August 27, 2007. > > > > S3.3: The server MUST NOT assume that the client actually received the updated > > ticket until it successfully verifies the client's Finished > > message. > > > > This text seems incorrect. The full-handshake case is actually a bit > > awkward, since the server cannot assume that the ticket has been > > received (by the client) until application data is received from the client. > > > > S3.4: If a server is planning on issuing a SessionTicket to a client > > that does not present one, it SHOULD include an empty Session ID in the > > ServerHello. If the server includes a non-empty session ID, then it > > is indicating intent to use stateful session resume. If the client > > receives a SessionTicket from the server, then it discards any > > Session ID that was sent in the ServerHello. > > > > Why are servers afforded the flexibility of simultaneously including an > > extension and session ID? Or differently put, why should a server ever > > need to generate a session ID if it intends to do stateless resumes? > > (Session IDs generated by the server will be discarded by the client in > > any case.) > > > > S3.4: In this case, the client ignores the Session ID sent in > > the ServerHello ... > > > > "the Session ID" -> "the Session ID (whether empty or non-empty)" > > > > S3.4: If the server accepts the ticket and the Session ID is not empty, > > then it MUST respond with the same Session ID present in the > > ClientHello. This allows the client to easily differentiate when > > the server is resuming a session from when it is falling back to a > > full handshake. > > > > What if the server rejects the ticket in this case? It seems > > reasonable that the server responds with an empty session ID to > > indicate to the client that a full-handshake is being initiated. > > > > Thanks, > > nagendra > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 09 18:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfNab-0008Bc-9w; Tue, 09 Oct 2007 18:30:09 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IfNaZ-00088t-MH for tls-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 18:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfNaZ-00088l-Cj for tls@lists.ietf.org; Tue, 09 Oct 2007 18:30:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfNaY-0006X3-2Q for tls@lists.ietf.org; Tue, 09 Oct 2007 18:30:07 -0400 Received: from [192.168.1.100] (pool-72-76-39-171.nwrknj.fios.verizon.net [72.76.39.171]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l99MTa5Q019983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 15:29:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 9 Oct 2007 18:29:33 -0400 To: "Nikos Mavrogiannopoulos" , tls@lists.ietf.org From: Paul Hoffman Subject: Re: [TLS] security levels for TLS Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Ekr's right: this is not a tractable problem. We could certainly come up with some numbers, but they would be meaningless (and therefore dangerous) with so much context that we might as well have just given the context by itself. The fact that the W3C wants to wade into this swamp should not lead us there, other than to maybe offer them a rope back to the shore where they started. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 10 09:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbJy-00052N-01; Wed, 10 Oct 2007 09:09:54 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IfbJw-00052C-UA for tls-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 09:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbJw-0004z6-I0 for tls@lists.ietf.org; Wed, 10 Oct 2007 09:09:52 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfbJk-0000T5-Np for tls@lists.ietf.org; Wed, 10 Oct 2007 09:09:47 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l9AD9M1m001372 for ; Wed, 10 Oct 2007 09:09:22 -0400 (EDT) Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Wed, 10 Oct 2007 09:09:22 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 09:09:22 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] security levels for TLS Date: Wed, 10 Oct 2007 09:09:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] security levels for TLS Thread-Index: AcgKxNNFI4IrJ5qDT0qCCvs0oWHqPAAd54GQ References: From: "Kemp, David P." To: X-OriginalArrivalTime: 10 Oct 2007 13:09:22.0294 (UTC) FILETIME=[C64E0960:01C80B3E] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15474003 X-TM-AS-Result: : Yes--15.888500-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMjcyNi03MDE1?= =?us-ascii?B?NzYtNzA2MDIzLTcwMzM2Ni0xMzk3MDMtNzAwMjcyLTcwOTU4NC03?= =?us-ascii?B?MTEwNzctNzA1MTExLTcwMTQzNy03MDA0MDUtNzAyMDEyLTcwMzc0?= =?us-ascii?B?Ny03MDM4MDgtNzA1Njk0LTcwNTAyNi03MDk5MDgtNzA1NTg0LTcw?= =?us-ascii?B?ODE3OS03MTAyMDctNzAwMTA0LTcwNjUzOC03MDA3MzItMzAwMDE1?= =?us-ascii?B?LTEzOTAwNi03MDI2NDUtNzAwNDczLTcwNTUyNi03MDQwMzItNzA0?= =?us-ascii?B?MTcxLTcwNTAzOC03MDA4MTAtNzAwNzA2LTExMzIyOC03MDUzMDMt?= =?us-ascii?B?NzAwMzcwLTcwMTI0OS03MDAwNDctMTQ4MDM5LTE0ODA1MA==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org NIST has taken the "build it and they will come" approach to projecting a multi-dimensional security space down to a few coarse-granularity levels in http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf. There is merit in what W3C is attempting to do, but it's questionable whether a consensus process with no benevolent dictator can pull it off. And the more quantization levels one attempts to define in a security metric, the more difficult the problem becomes. If W3C took the SP800-63 approach and tried to characterize just 3 or 4 levels (good/better/best, red/yellow/green, Harvey balls, etc), they would have a chance at producing something that would be truly useful for policy-driven access enforcement. Human enforcement, of course, is a lost cause - how many people even look at the padlock in the first place, much less would make distinctions based on its color? Dave -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Tuesday, October 09, 2007 6:30 PM To: Nikos Mavrogiannopoulos; tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS Ekr's right: this is not a tractable problem. We could certainly come=20 up with some numbers, but they would be meaningless (and therefore=20 dangerous) with so much context that we might as well have just given=20 the context by itself. The fact that the W3C wants to wade into this swamp should not lead=20 us there, other than to maybe offer them a rope back to the shore=20 where they started. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 10 12:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifeih-0005Ge-Lt; Wed, 10 Oct 2007 12:47:39 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ifeig-0005C0-45 for tls-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifeif-00056C-QI for tls@lists.ietf.org; Wed, 10 Oct 2007 12:47:37 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfeiT-0008Dh-PE for tls@lists.ietf.org; Wed, 10 Oct 2007 12:47:35 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 2E990145CD5 for ; Wed, 10 Oct 2007 12:46:32 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id EE9A0145CD3 for ; Wed, 10 Oct 2007 12:46:31 -0400 (EDT) Message-ID: <470D0243.3050009@pobox.com> Date: Wed, 10 Oct 2007 09:48:03 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org There are two aspects to this that I see: 1) a TLS client should be configurable such that it will reject negotiated sessions that don't satisfy its requirements. The configurable parameters would include the minimum acceptable size for RSA and DSA keys, and DH parameters (p). This can be done now without any changes to TLS, but has the problem that several attempts may be necessary to establish an acceptable connection. 2) a TLS client might want to tell the server that if TLS_DHE_RSA_WITH_AES_128_CBC_SHA1 is the negotiated cipher, it will accept a minimum RSA key size of X and a minimum DH parameter size of Y. If the server has several sets of DH parameters (such as those in RFC 3526), it would select one that meets the minimum and is smallest for best performance. If the server doesn't have the ability to satisfy the minimums, it could return an insufficient_security fatal alert. Support for (2) could be added using an extension: enum { RSA, DHE_RSA, DHE_DSS, ... } KeyExchangeAlgorithm; struct { CipherSuite cipher_suite; HashType mac_algorithm<0..255>; // possible select (KeyExchangeAlgorithm) { case RSA: uint16 rsa_key_size; // bytes uint16 premaster_secret_size; // possible case DHE_RSA: uint16 rsa_key_size; // bytes uint16 dh_group_size; // bytes case DHE_DSS: uint16 dsa_key_size; // bytes uint16 dh_group_size; // bytes case .... }; } SecurityRequirements; The client would package up SecurityRequirements structures for each of the cipher suites listed in its ClientHello message. Notice the possibility to change the MAC algorithm without needing to define new cipher suites. A list is used to be able to specify preferences (and can be empty for AEAD ciphers). The server would return a single SecurityRequirements corresponding to the selected cipher suite, containing the parameters chosen (MAC algorithm, premaster secret size, etc.). Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 10 14:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffyR-0000Pu-DR; Wed, 10 Oct 2007 14:07:59 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IffyP-0000Jt-F6 for tls-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffyO-0000IQ-Pl for tls@lists.ietf.org; Wed, 10 Oct 2007 14:07:56 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IffyD-00031R-3E for tls@lists.ietf.org; Wed, 10 Oct 2007 14:07:56 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7ABC533C21; Wed, 10 Oct 2007 11:03:24 -0700 (PDT) Date: Wed, 10 Oct 2007 11:03:23 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470D0243.3050009@pobox.com> References: <470D0243.3050009@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071010180324.7ABC533C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Wed, 10 Oct 2007 09:48:03 -0700, Mike wrote: > > There are two aspects to this that I see: > > 1) a TLS client should be configurable such > that it will reject negotiated sessions > that don't satisfy its requirements. The > configurable parameters would include the > minimum acceptable size for RSA and DSA > keys, and DH parameters (p). This can be > done now without any changes to TLS, but > has the problem that several attempts may > be necessary to establish an acceptable > connection. This seems like a perfectly reasonable capability for a developer to provide, I'm not convinced that a developer *should* provide it. In any case, it's not an IETF issue. > 2) a TLS client might want to tell the server > that if TLS_DHE_RSA_WITH_AES_128_CBC_SHA1 > is the negotiated cipher, it will accept > a minimum RSA key size of X and a minimum > DH parameter size of Y. If the server > has several sets of DH parameters (such as > those in RFC 3526), it would select one > that meets the minimum and is smallest for > best performance. If the server doesn't > have the ability to satisfy the minimums, > it could return an insufficient_security > fatal alert. This adds significant complexity for what's in my experience, a non-problem. The vast majority of servers I am familiar with have one and only one set of asymmetric keying material, so selecting it isn't a problem. Moreover, it's simply not the case that one can express the security of an algorithm purely in terms of the number of bits of claimed keying material. Examples include 3DES (112 or 168?, depends on the attack), EC (it's not clear that all groups of the same size are equally secure). Absent some significant evidence that this is a problem in practice, I'm against the TLS WG doing anything along these lines. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 11:40:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig06z-0004YB-SY; Thu, 11 Oct 2007 11:38:09 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig06y-0004Xj-8O for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:38:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig06x-0004VY-V8 for tls@lists.ietf.org; Thu, 11 Oct 2007 11:38:07 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig06j-0007Fh-V5 for tls@lists.ietf.org; Thu, 11 Oct 2007 11:38:00 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 5F8EF146879 for ; Thu, 11 Oct 2007 11:37:35 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 1AD4A146874 for ; Thu, 11 Oct 2007 11:37:34 -0400 (EDT) Message-ID: <470E4399.3010008@pobox.com> Date: Thu, 11 Oct 2007 08:39:05 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> In-Reply-To: <20071010180324.7ABC533C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I think there is good reason to try to solve this problem in the TLS layer. The alternative is to force every TLS- enabled application to solve it (and likely they won't solve it and be less secure). Wouldn't it be ideal if an application could just say: TLS::SetSecurityLevel (3); and know that the resulting connection will either meet the (implementation-dependent) criteria for that level of security, or the TLS negotiation will fail? Currently an application has to do the following: 1) configure TLS layer with acceptable cipher suites 2) connect to server 3) negotiate a TLS session (many applications will stop here) 4) check that the negotiated parameters meet the application's idea of good security 5) if not, abort TLS session, disconnect, remove some cipher suites from the acceptable list and goto step 1 This is inefficient and error-prone, and makes it much harder to know how secure your IT infrastructure as a whole is since there are as many points of failure as there are applications. Also as attacks improve and the security requirements change, every application needs to be reexamined and modified. It would be much better if all that was needed was to replace the TLS library with an updated version. Or better yet, the TLS library may have a plain text configuration file for its security levels that could be replaced, and all you need to do is restart your applications. > Absent some significant evidence that this is a problem in > practice, I'm against the TLS WG doing anything along these > lines. The folks at Opera Software have expressed how difficult it was to secure their browser, and how insecure some servers are (256-bit DH parameters!). The W3C is also attempting to solve this problem, but the need extends beyond HTTPS. Another issue I've been meaning to bring up is that if you want forward secrecy, you need to use Diffie- Hellman; however, there is no way to tell the server the size of the parameter p you want. Increasing the size of p has significant performance implications, so servers will typically use 1024 bits. On my Windows machine, it takes 0.02 seconds to generate a public key and another 0.02 seconds to compute the secret using 1024-bit parameters. Moving to 2048-bit parameters, the computation time increases to 0.15 seconds each. 4096-bit computations take 1.1 seconds. No server operator will decrease throughput by a factor of 50 for everyone, just to accommodate the few who want this level of security. It would be better if those who want to use 4096 bits could ask for it. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 12:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0V5-0007Ic-7Z; Thu, 11 Oct 2007 12:03:03 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig0V3-0007HH-Po for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 12:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0V3-00075R-G6 for tls@lists.ietf.org; Thu, 11 Oct 2007 12:03:01 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig0Up-0008Rm-Iq for tls@lists.ietf.org; Thu, 11 Oct 2007 12:02:56 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 965C733C28; Thu, 11 Oct 2007 08:58:29 -0700 (PDT) Date: Thu, 11 Oct 2007 08:58:27 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470E4399.3010008@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071011155829.965C733C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Thu, 11 Oct 2007 08:39:05 -0700, Mike wrote: > > I think there is good reason to try to solve this problem > in the TLS layer. The alternative is to force every TLS- > enabled application to solve it (and likely they won't > solve it and be less secure). Wouldn't it be ideal if an > application could just say: > > TLS::SetSecurityLevel (3); No, it would not, because, I've now said several times, security is not expressible via a single metric, making this a complete rathole. > Currently an application has to do the following: > > 1) configure TLS layer with acceptable cipher suites > 2) connect to server > 3) negotiate a TLS session > (many applications will stop here) > 4) check that the negotiated parameters meet the > application's idea of good security > 5) if not, abort TLS session, disconnect, remove > some cipher suites from the acceptable list and > goto step 1 Again, do you have any evidence this is a problem in practice. I appreciate it's a potential problem *in theory* but that's not the same thing. > It would be much better if all that was needed was to > replace the TLS library with an updated version. Or > better yet, the TLS library may have a plain text > configuration file for its security levels that could > be replaced, and all you need to do is restart your > applications. And again, this is an API/local isssue. IETF doesn't do those. > > Absent some significant evidence that this is a problem in > > practice, I'm against the TLS WG doing anything along these > > lines. > > The folks at Opera Software have expressed how difficult > it was to secure their browser, and how insecure some > servers are (256-bit DH parameters!). Yes that's interesting but irrelevant. Those are pretty clearly mistakes on the server side, as are RSA e values of 1. Neither is likely to be fixed by specifying security levels in the way you suggest. > Another issue I've been meaning to bring up is that > if you want forward secrecy, you need to use Diffie- > Hellman; however, there is no way to tell the server > the size of the parameter p you want. Increasing the > size of p has significant performance implications, > so servers will typically use 1024 bits. On my Windows > machine, it takes 0.02 seconds to generate a public key > and another 0.02 seconds to compute the secret using > 1024-bit parameters. Moving to 2048-bit parameters, > the computation time increases to 0.15 seconds each. > 4096-bit computations take 1.1 seconds. No server > operator will decrease throughput by a factor of 50 > for everyone, just to accommodate the few who want > this level of security. It would be better if those > who want to use 4096 bits could ask for it. Again, please present some evidence that this is a real practical issue outside of a very small population of keylength fetishists. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 12:23:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0oi-0000Ys-Un; Thu, 11 Oct 2007 12:23:20 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig0oh-0000Yi-Lr for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 12:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0oh-0000YZ-CK for tls@lists.ietf.org; Thu, 11 Oct 2007 12:23:19 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig0nd-0000s1-0b for tls@lists.ietf.org; Thu, 11 Oct 2007 12:23:19 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9BGLt4i017697 for ; Thu, 11 Oct 2007 16:21:55 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BGLs2u029507 for ; Thu, 11 Oct 2007 10:21:54 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BGLsoW027048; Thu, 11 Oct 2007 11:21:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BGLrPn027047; Thu, 11 Oct 2007 11:21:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Oct 2007 11:21:53 -0500 From: Nicolas Williams To: Eric Rescorla Subject: Re: [TLS] security levels for TLS Message-ID: <20071011162153.GO24532@Sun.COM> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011155829.965C733C28@delta.rtfm.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 11, 2007 at 08:58:27AM -0700, Eric Rescorla wrote: > At Thu, 11 Oct 2007 08:39:05 -0700, > Mike wrote: > > > > I think there is good reason to try to solve this problem > > in the TLS layer. The alternative is to force every TLS- > > enabled application to solve it (and likely they won't > > solve it and be less secure). Wouldn't it be ideal if an > > application could just say: > > > > TLS::SetSecurityLevel (3); > > No, it would not, because, I've now said several times, security is > not expressible via a single metric, making this a complete rathole. Agreed. SASL used to have a notion of "security strength factor" (SSF), and that was a disaster. You cannot calculate an _absolute_ and _objective_ measure of security for anything, least of all cryptographic algorithms subject to future cryptanalytic advances (i.e., all of them). (Don't even mention future quantum computers.) Basically, the best you could do is have an application choose a cryptographic profile by descriptive names like "strong" and "fast," but where the content of such profiles is subject to change over time, and perhaps even a local matter. Today "strong" might mean AES-128 is OK, and tomorrow it might mean only AES-256 is OK, and the next day it might mean something else, and so on. > > Currently an application has to do the following: > > > > Again, do you have any evidence this is a problem in practice. > I appreciate it's a potential problem *in theory* but that's > not the same thing. The easy answer is to give the application fewer choices, namely a choice of locally-configured profiles (see above). In fact, I strongly urge TLS API developers to provide such a facility. > And again, this is an API/local isssue. IETF doesn't do > those. There you go again. The IETF most certainly deals in APIs. Though in this case I think the IETF need not have any specifications requiring or recommending a facility like I describe above. If it helps ward off requests for silly things like "security strength factors" and those are common enough, then perhaps we should indeed have an information RFC explaining why we can't and what developers can do instead. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 12:28:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0sb-0006de-UR; Thu, 11 Oct 2007 12:27:21 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig0sa-0006cb-MN for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 12:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0sa-0006YS-9q for tls@lists.ietf.org; Thu, 11 Oct 2007 12:27:20 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig0sZ-00019v-3l for tls@lists.ietf.org; Thu, 11 Oct 2007 12:27:20 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7722A33C28; Thu, 11 Oct 2007 09:23:12 -0700 (PDT) Date: Thu, 11 Oct 2007 09:23:11 -0700 From: Eric Rescorla To: Nicolas Williams Subject: Re: [TLS] security levels for TLS In-Reply-To: <20071011162153.GO24532@Sun.COM> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <20071011162153.GO24532@Sun.COM> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071011162312.7722A33C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Thu, 11 Oct 2007 11:21:53 -0500, Nicolas Williams wrote: > On Thu, Oct 11, 2007 at 08:58:27AM -0700, Eric Rescorla wrote: > > And again, this is an API/local isssue. IETF doesn't do > > those. > > There you go again. The IETF most certainly deals in APIs. Let me rephrase: the IETF generally doesn't deal in APIs with a few prominent exceptions. The TLS-WG has never done so and I don't think it's a good idea to do so now. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 14:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2kA-0003sz-Kx; Thu, 11 Oct 2007 14:26:46 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig2k9-0003nv-B9 for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 14:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2k9-0003nn-1T for tls@lists.ietf.org; Thu, 11 Oct 2007 14:26:45 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig2k3-0006Gh-Tw for tls@lists.ietf.org; Thu, 11 Oct 2007 14:26:45 -0400 Received: by machshav.com (Postfix, from userid 512) id BAB0B5B4; Thu, 11 Oct 2007 18:26:27 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86C0A171; Thu, 11 Oct 2007 18:26:27 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id AE299766013; Thu, 11 Oct 2007 14:26:27 -0400 (EDT) Date: Thu, 11 Oct 2007 18:26:27 +0000 From: "Steven M. Bellovin" To: Eric Rescorla Subject: Re: [TLS] security levels for TLS Message-ID: <20071011182627.72bc12fd@berkshire.machshav.com> In-Reply-To: <20071011162312.7722A33C28@delta.rtfm.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <20071011162153.GO24532@Sun.COM> <20071011162312.7722A33C28@delta.rtfm.com> Organization: Columbia University X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@lists.ietf.org, Nicolas Williams X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, 11 Oct 2007 09:23:11 -0700 Eric Rescorla wrote: > At Thu, 11 Oct 2007 11:21:53 -0500, > Nicolas Williams wrote: > > On Thu, Oct 11, 2007 at 08:58:27AM -0700, Eric Rescorla wrote: > > > And again, this is an API/local isssue. IETF doesn't do > > > those. > > > > There you go again. The IETF most certainly deals in APIs. > > Let me rephrase: the IETF generally doesn't deal in APIs with a few > prominent exceptions. The TLS-WG has never done so and I don't think > it's a good idea to do so now. > And certainly not where the goal is this dubious. I'm with ekr: this is a bad idea. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 14:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2qo-0004vv-UD; Thu, 11 Oct 2007 14:33:39 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig2ql-0004oj-NK for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 14:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2ql-0004oS-6V for tls@lists.ietf.org; Thu, 11 Oct 2007 14:33:35 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig2qe-0006Va-V7 for tls@lists.ietf.org; Thu, 11 Oct 2007 14:33:35 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9BIXIg8006824 for ; Thu, 11 Oct 2007 18:33:18 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BIXHQ4014582 for ; Thu, 11 Oct 2007 12:33:18 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BIXH4D027139; Thu, 11 Oct 2007 13:33:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BIXGCM027138; Thu, 11 Oct 2007 13:33:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Oct 2007 13:33:16 -0500 From: Nicolas Williams To: "Steven M. Bellovin" Subject: Re: [TLS] security levels for TLS Message-ID: <20071011183316.GU24532@Sun.COM> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <20071011162153.GO24532@Sun.COM> <20071011162312.7722A33C28@delta.rtfm.com> <20071011182627.72bc12fd@berkshire.machshav.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011182627.72bc12fd@berkshire.machshav.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 11, 2007 at 06:26:27PM +0000, Steven M. Bellovin wrote: > On Thu, 11 Oct 2007 09:23:11 -0700 > Eric Rescorla wrote: > > > At Thu, 11 Oct 2007 11:21:53 -0500, > > Nicolas Williams wrote: > > > On Thu, Oct 11, 2007 at 08:58:27AM -0700, Eric Rescorla wrote: > > > > And again, this is an API/local isssue. IETF doesn't do > > > > those. > > > > > > There you go again. The IETF most certainly deals in APIs. > > > > Let me rephrase: the IETF generally doesn't deal in APIs with a few > > prominent exceptions. The TLS-WG has never done so and I don't think > > it's a good idea to do so now. > > > And certainly not where the goal is this dubious. I'm with ekr: this > is a bad idea. To clarify, I agree as well. We already know from experience with SASL that this is a bad idea. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 11 20:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig8ey-0008OX-9X; Thu, 11 Oct 2007 20:45:48 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ig8ew-0008OP-PR for tls-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:45:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig8ew-0008OH-Bh for tls@ietf.org; Thu, 11 Oct 2007 20:45:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig8ev-00059e-68 for tls@ietf.org; Thu, 11 Oct 2007 20:45:46 -0400 X-IronPort-AV: E=Sophos;i="4.21,262,1188802800"; d="scan'208";a="235228016" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2007 17:45:44 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9C0ji0r025843; Thu, 11 Oct 2007 17:45:44 -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.12.10/8.12.6) with ESMTP id l9C0jiZp007469; Fri, 12 Oct 2007 00:45:44 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, 11 Oct 2007 17:45:44 -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 Subject: RE: [TLS] comments & clarifications for rfc4507bis Date: Thu, 11 Oct 2007 17:45:53 -0700 Message-ID: In-Reply-To: <28425e380710051647m72ae0414na572730b63457e6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] comments & clarifications for rfc4507bis Thread-Index: AcgHqi698GZqg9fNRCuPdGa039bdsADt9lTg From: "Joseph Salowey (jsalowey)" To: "Nagendra Modadugu" X-OriginalArrivalTime: 12 Oct 2007 00:45:44.0104 (UTC) FILETIME=[389E0A80:01C80C69] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9206; t=1192149944; x=1193013944; c=relaxed/simple; s=sjdkim1004; 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]=20comments=20&=20clarifications=20for=20rfc4507 bis |Sender:=20; bh=rhoJtUT7aNA3cS2+Zlmt1GWafVEUxG76k+MsVnuNNVU=; b=LoiCWplowuQamS1bNkHWm7dVqrJgDxlBh8G4eH8nay8tb2FoaNlI7utvhFFxnXTio9HJRLHw 6V75oIUEI1Yt6z7v7jfbT/fH3CFyo85DBKRrGmvngj4gLLPX52erb0U+BUTGl9eeOLw2yEtwjq 7d53gWUHLQnaSeb0BGqxXUk5U=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Nagendra, Comments inline below:=20 > -----Original Message----- > From: ngm@google.com [mailto:ngm@google.com] On Behalf Of=20 > Nagendra Modadugu > Sent: Friday, October 05, 2007 4:48 PM > To: Joseph Salowey (jsalowey) > Cc: tls@ietf.org > Subject: Re: [TLS] comments & clarifications for rfc4507bis >=20 > On 10/5/07, Joseph Salowey (jsalowey) wrote: > > Hi Nagendra, > > > > Thanks for reviewing the draft and providing comments: > > > > Comments inline below: > > > > > -----Original Message----- > > > From: Nagendra Modadugu [mailto:ngm+ietf@google.com] > > > Sent: Thursday, October 04, 2007 1:22 PM > > > To: tls@ietf.org > > > Subject: [TLS] comments & clarifications for rfc4507bis > > > > > > A few more comments: > > > > > > S3.1: The client caches this ticket along with the master=20 > secret and > > > other parameters associated with the current session. > > > When the client > > > wishes to resume the session, it includes the ticket in the > > > SessionTicket extension within the ClientHello message. > > > > > > The text is not clear what "includes the ticket" refers to. > > > It could either mean the entire NewSessionTicket message, or just=20 > > > NewSessionTicket.ticket. The client does not need to echo back=20 > > > NewSessionTicket.ticket_lifetime_hint, so it is not=20 > obvious which of=20 > > > the two meanings is implied. The description would be=20 > unabiguous if=20 > > > the text included a struct along the lines of: > > > > > > struct { > > > opaque NewSessionTicket.ticket<1..2^16-1> > > > } SessionTicket; > > > > > > > > [Joe] I would rather clarify this by saying: > > > > "When the client wishes to resume the session, it includes=20 > the ticket=20 > > contained within the NewSessionTicket message, in the SessionTicket=20 > > extension within the ClientHello message. " > > > > The new struct actually reintroduces an issue with encoding that we=20 > > trying to correct with this revision. > > >=20 > The text (even the correction you suggest) is not unambiguous=20 > about what the 'the ticket' constitutes. Is it a length=20 > encoded vector NewSessionTicket.ticket or the serialized=20 > structure embedded within? > I'm not familiar with what the previous draft specified, but=20 > I assume you mean the latter. Could you clarify? >=20 > I'm afraid that leaving this portion of the description in=20 > textual form may lead to implementation bugs -- it would be=20 > nice to see a struct. >=20 [Joe] It is the serialized ticket without the length encoding that would be introduced by the struct encoding. The text has been modified to try to remove this ambiguity. Would the following text help: "When the client wishes to resume the session, it includes the serialized ticket contained within the NewSessionTicket message, in the SessionTicket extension within the ClientHello message. Appendix A provides a detailed description of the encoding of the extension and changes from RFC 4507. " > > > > > On 10/3/07, Nagendra Modadugu wrote: > > > > Apologies if the points below have been previously=20 > addressed. The=20 > > > > comments below are in reference to the version of the=20 > draft dated=20 > > > > S3.4: If a server is planning on issuing a=20 > SessionTicket to a client > > > > that does not present one, it SHOULD include an empty > > > Session ID in the > > > > ServerHello. If the server includes a non-empty > > > session ID, then it > > > > is indicating intent to use stateful session resume. > > > If the client > > > > receives a SessionTicket from the server, then it=20 > discards any > > > > Session ID that was sent in the ServerHello. > > > > > > > > Why are servers afforded the flexibility of simultaneously > > > including > > > > an extension and session ID? Or differently put, why > > > should a server > > > > ever need to generate a session ID if it intends to do > > > stateless resumes? > > > > (Session IDs generated by the server will be discarded by > > > the client > > > > in any case.) > > > > > > [Joe] During discussions for RFC 4507 there was a desire to allow=20 > > stateful resume during fallback to a full handshake. > > >=20 > If this is the case then "it [server] SHOULD include an empty=20 > Session ID in the ServerHello" and "client ignores the=20 > Session ID sent in the ServerHello" are confusing. If the=20 > draft is recommending (for or) against simultaneously=20 > supporting stateful and stateless resumption, it should say=20 > so explicitly (noting that a server should be aware that=20 > clients supporting stateless resumption might not attempt stateful > resumption.) >=20 > Simultaneously supporting stateful and stateless resumption=20 > leads to some tricky situations which the draft does not=20 > address. Consider the following situation: >=20 > Client C makes a TLS connection T1 to server S and receives=20 > session-ID SID1 and > SessionTicket ST1. The client does another full handshake=20 > and receives SID2 and ST2. > Now C makes a third connection to S, but this time=20 > attempting to resume, including session ID > SID1 and SessionTicket ST2 (note this is the second SessionTicket > received.) The server > has a cache hit on SID1 and also finds that ST2 is valid. =20 > Which session does the server > pick? What should the client infer about the server's choice? >=20 > I'd like to add that this situation is not esoteric. A=20 > client implementation may have two hash tables (one of=20 > session IDs and other of SessionTickets.) It's pretty easy=20 > to end up mixing and matching. >=20 [Joe] OK, thanks I think I see the confusion. The desired behavior is for the server to fall back to a full handshake if it does not accept the ticket. The client cannot simultaneously request both stateful and stateless resumption, stateless resumption takes precedence. When the server responds with the server hello in the case of a full handshake it can provide a session ID for stateful resume. I think the text does state this, however the first paragraph is a bit confusing and potentially conflicts with the second paragraph: "If a server is planning on issuing a SessionTicket to a client that does not present one, it SHOULD include an empty Session ID in the ServerHello. If the server rejects the ticket and falls back to the=20 full handshake then it may include a non-empty Session ID to indicate its support for stateful resume. If the client receives a=20 SessionTicket from the server, then it discards any Session ID that=20 was sent in the ServerHello. " > > > > S3.4: In this case, the client ignores the Session ID sent in > > > > the ServerHello ... > > > > > > > > "the Session ID" -> "the Session ID (whether empty or=20 > non-empty)" > > > > > > > > S3.4: If the server accepts the ticket and the Session ID > > > is not empty, > > > > then it MUST respond with the same Session ID=20 > present in the > > > > ClientHello. This allows the client to easily > > > differentiate when > > > > the server is resuming a session from when it is > > > falling back to a > > > > full handshake. > > > > > > > > What if the server rejects the ticket in this case? It seems=20 > > > > reasonable that the server responds with an empty session ID to=20 > > > > indicate to the client that a full-handshake is being initiated. > > > > > > [Joe] If the server rejects the ticket and it is planning=20 > on issuing a=20 > > new ticket then it SHOULD include an empty session ID. If=20 > the server >=20 > This text does not preclude a server from (a) rejecting the ticket and > (b) echoing the session ID sent by the client. Doing (b) is=20 > confusing for the client for the reasons described in the=20 > example above -- how does the client tell that the server has=20 > reject the ticket, but is instead doing a stateful resume=20 > (where the session ID and ticket refer to different=20 > sessions)? This problem could be addressed by saying=20 > something along the lines of: >=20 > 'If a client receives a session ID along with a session=20 > ticket from a server, the client infers that the server=20 > supports both stateless and stateful resumption. Clients=20 > attempting stateless resumes SHOULD send empty session IDs. =20 > If a client attempting a stateless resume includes a session=20 > ID, then the session ID MUST be the same session ID that was=20 > issued along with the session ticket." >=20 [Joe] I think the changes above in the first paragraph, above, clarifies the issue along with the line in the second paragraph that states=20 "If a ticket is presented by the client, the server MUST NOT attempt to use the Session ID in the ClientHello for stateful session resume." If the client presents a ticket then the server must ignore the Session ID and not perform stateful session resume. > Thanks, > nagendra >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 00:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5E-0005Zf-Is; Fri, 12 Oct 2007 00:25:08 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgC5D-0005ZS-Ar for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 00:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5D-0005Dy-0k for tls@lists.ietf.org; Fri, 12 Oct 2007 00:25:07 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgC51-0002xD-Qk for tls@lists.ietf.org; Fri, 12 Oct 2007 00:25:00 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 67BE42EF for ; Fri, 12 Oct 2007 00:24:53 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 18D35862AD for ; Fri, 12 Oct 2007 00:24:52 -0400 (EDT) Message-ID: <470EF76B.5050102@pobox.com> Date: Thu, 11 Oct 2007 21:26:19 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> In-Reply-To: <20071011155829.965C733C28@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org [There are two different issues here: the original topic of the thread regarding determining the overall security of a TLS session and representing it as one of a few "levels", and the topic I'm more interested in which is adding the capability for a TLS client to tell the server all of the missing parameters not specified by a cipher suite. Adding the latter would enable the former.] >> I think there is good reason to try to solve this problem >> in the TLS layer. The alternative is to force every TLS- >> enabled application to solve it (and likely they won't >> solve it and be less secure). Wouldn't it be ideal if an >> application could just say: >> >> TLS::SetSecurityLevel (3); > > No, it would not, because, I've now said several times, security is > not expressible via a single metric, making this a complete rathole. Clearly behind the scenes, the TLS layer would translate the single metric into the myriad options available. Some cipher suites would only be used at level 1 or 2, say, but not at levels 3 or 4. Higher levels would require longer RSA keys, more DH parameter bits, etc. These profiles would change over time to reflect the current threat levels posed by attackers. You've said that this is not possible because, for instance, DES3 does not have a single value for the key length since one attack renders its effective strength at 168 bits, while another weakens it to 112 bits. I woFrom tls-bounces@lists.ietf.org Fri Oct 12 00:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5E-0005Zf-Is; Fri, 12 Oct 2007 00:25:08 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgC5D-0005ZS-Ar for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 00:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5D-0005Dy-0k for tls@lists.ietf.org; Fri, 12 Oct 2007 00:25:07 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgC51-0002xD-Qk for tls@lists.ietf.org; Fri, 12 Oct 2007 00:25:00 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 67BE42EF for ; Fri, 12 Oct 2007 00:24:53 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 18D35862AD for ; Fri, 12 Oct 2007 00:24:52 -0400 (EDT) Message-ID: <470EF76B.5050102@pobox.com> Date: Thu, 11 Oct 2007 21:26:19 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> In-Reply-To: <20071011155829.965C733C28@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org [There are two different issues here: the original topic of the thread regarding determining the overall security of a TLS session and representing it as one of a few "levels", and the topic I'm more interested in which is adding the capability for a TLS client to tell the server all of the missing parameters not specified by a cipher suite. Adding the latter would enable the former.] >> I think there is good reason to try to solve this problem >> in the TLS layer. The alternative is to force every TLS- >> enabled application to solve it (and likely they won't >> solve it and be less secure). Wouldn't it be ideal if an >> application could just say: >> >> TLS::SetSecurityLevel (3); > > No, it would not, because, I've now said several times, security is > not expressible via a single metric, making this a complete rathole. Clearly behind the scenes, the TLS layer would translate the single metric into the myriad options available. Some cipher suites would only be used at level 1 or 2, say, but not at levels 3 or 4. Higher levels would require longer RSA keys, more DH parameter bits, etc. These profiles would change over time to reflect the current threat levels posed by attackers. You've said that this is not possible because, for instance, DES3 does not have a single value for the key length since one attack renders its effective strength at 168 bits, while another weakens it to 112 bits. I would say that you would have to go with the lower 112 bits, and perhaps you wouldn't even allow it at level 1. I have to admit I don't know the subtleties of elliptic curve cryptography to know how to translate "level 2" to a list of acceptable curves and key lengths, but I'm sure someone on this list does. Right now all cipher suites are under-specified. If we had, for example: TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA we would probably not be talking about this. I proposed that we let clients "fill in the blanks" that the cipher suites don't specify. Isn't it better to tell the server exactly what you want in terms of security, than to leave it up to chance? You argued that servers only have one set of asymmetric keys, so there are no options anyway. I would counter that there is currently no way to tell the server that you want a 4096-bit RSA key, for example, so of course they don't have multiple keys. Chicken/egg. I'm an interface designer, and believe that the average application developer has only a boolean view of security: either security (TLS) is enabled, or it isn't. It's easy to extend that to a 3 or 4 level security model, but beyond that, you're asking for trouble. (A TLS toolkit would still provide a security expert full control of course.) >> Currently an application has to do the following: >> >> 1) configure TLS layer with acceptable cipher suites >> 2) connect to server >> 3) negotiate a TLS session >> (many applications will stop here) >> 4) check that the negotiated parameters meet the >> application's idea of good security >> 5) if not, abort TLS session, disconnect, remove >> some cipher suites from the acceptable list and >> goto step 1 > > Again, do you have any evidence this is a problem in practice. > I appreciate it's a potential problem *in theory* but that's > not the same thing. On May 14, 2007, Yngve Pettersen of Opera Software wrote to the TLS mailing list on the topic of "Short Ephemeral Diffie- Hellman keys". The last paragraph illustrates this: I have recently started to see an increasing number of reports about SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases very short ones. Opera's SSL/TLS client will display warnings to users if the server is using RSA/DH/DSA keys shorter than (currently) 900 bits. All keys used in the chain, including the CA certificates are included in this evaluation, as well as the ephermal key, if the server selects a cipher with an ephermal key. The short DHE keys I have seen have usually been 512 bits, but I have seen servers sending keys as short as 256 bits. I have seen these keys on both normal webservers and mail servers, but I have an impression that there are more reports about the mail servers. I think it might be an idea for TLS specification to include recommendations about how such keys should be selected. My preference for such a recommendation is that the ephermal key should be as long, or as strong, as the key used to sign the ephermal key. I don't think the specification should mention specific keylengths, because what is secure is likely to change over time. Comments? [this is the important part:] As far as Opera is concerned, I am considering a few options, including automatically disabling the ephermal ciphersuites or re-sorting the cipher suite list toplace them last, and renegotiate the connection. [Apparently my memory was incorrect and the session was renegotiated instead of the close->reconnect->negotiate sequence I stated; however, support for renegotiation is optional, so it may not always work.] >> The folks at Opera Software have expressed how difficult >> it was to secure their browser, and how insecure some >> servers are (256-bit DH parameters!). > > Yes that's interesting but irrelevant. Those are pretty > clearly mistakes on the server side, as are RSA e values > of 1. Neither is likely to be fixed by specifying security > levels in the way you suggest. This proves my point -- lots of application developers anduld say that you would have to go with the lower 112 bits, and perhaps you wouldn't even allow it at level 1. I have to admit I don't know the subtleties of elliptic curve cryptography to know how to translate "level 2" to a list of acceptable curves and key lengths, but I'm sure someone on this list does. Right now all cipher suites are under-specified. If we had, for example: TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA we would probably not be talking about this. I proposed that we let clients "fill in the blanks" that the cipher suites don't specify. Isn't it better to tell the server exactly what you want in terms of security, than to leave it up to chance? You argued that servers only have one set of asymmetric keys, so there are no options anyway. I would counter that there is currently no way to tell the server that you want a 4096-bit RSA key, for example, so of course they don't have multiple keys. Chicken/egg. I'm an interface designer, and believe that the average application developer has only a boolean view of security: either security (TLS) is enabled, or it isn't. It's easy to extend that to a 3 or 4 level security model, but beyond that, you're asking for trouble. (A TLS toolkit would still provide a security expert full control of course.) >> Currently an application has to do the following: >> >> 1) configure TLS layer with acceptable cipher suites >> 2) connect to server >> 3) negotiate a TLS session >> (many applications will stop here) >> 4) check that the negotiated parameters meet the >> application's idea of good security >> 5) if not, abort TLS session, disconnect, remove >> some cipher suites from the acceptable list and >> goto step 1 > > Again, do you have any evidence this is a problem in practice. > I appreciate it's a potential problem *in theory* but that's > not the same thing. On May 14, 2007, Yngve Pettersen of Opera Software wrote to the TLS mailing list on the topic of "Short Ephemeral Diffie- Hellman keys". The last paragraph illustrates this: I have recently started to see an increasing number of reports about SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases very short ones. Opera's SSL/TLS client will display warnings to users if the server is using RSA/DH/DSA keys shorter than (currently) 900 bits. All keys used in the chain, including the CA certificates are included in this evaluation, as well as the ephermal key, if the server selects a cipher with an ephermal key. The short DHE keys I have seen have usually been 512 bits, but I have seen servers sending keys as short as 256 bits. I have seen these keys on both normal webservers and mail servers, but I have an impression that there are more reports about the mail servers. I think it might be an idea for TLS specification to include recommendations about how such keys should be selected. My preference for such a recommendation is that the ephermal key should be as long, or as strong, as the key used to sign the ephermal key. I don't think the specification should mention specific keylengths, because what is secure is likely to change over time. Comments? [this is the important part:] As far as Opera is concerned, I am considering a few options, including automatically disabling the ephermal ciphersuites or re-sorting the cipher suite list toplace them last, and renegotiate the connection. [Apparently my memory was incorrect and the session was renegotiated instead of the close->reconnect->negotiate sequence I stated; however, support for renegotiation is optional, so it may not always work.] >> The folks at Opera Software have expressed how difficult >> it was to secure their browser, and how insecure some >> servers are (256-bit DH parameters!). > > Yes that's interesting but irrelevant. Those are pretty > clearly mistakes on the server side, as are RSA e values > of 1. Neither is likely to be fixed by specifying security > levels in the way you suggest. This proves my point -- lots of application developers and/ or server operators don't understand this stuff to the level required to make all the right choices. >> Another issue I've been meaning to bring up is that >> if you want forward secrecy, you need to use Diffie- >> Hellman; however, there is no way to tell the server >> the size of the parameter p you want. Increasing the >> size of p has significant performance implications, >> so servers will typically use 1024 bits. >> [...] It would be better if those >> who want to use 4096 bits could ask for it. > > Again, please present some evidence that this is a real > practical issue outside of a very small population of > keylength fetishists. RSA key exchange provides up to 368 bits of security, but doesn't provide forward secrecy. If I want forward secrecy, then I need to use Diffie-Hellman. A server that has 1024- bit Diffie-Hellman parameters only provides me with some- where in the neighborhood of 70-80 bits of security (extrapolated from the data in RFC 3526). You are saying that I am a "keylength fetishist" because I want better than 70-80 bits of security? So I'm allowed either lots of "strength" *or* forward secrecy, but not both? That's irresponsible. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 00:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5F-0005aV-Qp; Fri, 12 Oct 2007 00:25:09 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgC5E-0005Zj-MH for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 00:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5E-0005ZX-BI for tls@ietf.org; Fri, 12 Oct 2007 00:25:08 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgC5D-0002xu-2X for tls@ietf.org; Fri, 12 Oct 2007 00:25:08 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id E0FD92EF for ; Fri, 12 Oct 2007 00:25:27 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id B1912862AF for ; Fri, 12 Oct 2007 00:25:27 -0400 (EDT) Message-ID: <470EF791.5010405@pobox.com> Date: Thu, 11 Oct 2007 21:26:57 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] comments & clarifications for rfc4507bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>>> The description would be unabiguous if >>>> the text included a struct along the lines of: >>>> >>>> struct { >>>> opaque NewSessionTicket.ticket<1..2^16-1> >>>> } SessionTicket; >>> >>> The new struct actually reintroduces an issue with encoding that we >>> trying to correct with this revision. >> >> I'm afraid that l/ or server operators don't understand this stuff to the level required to make all the right choices. >> Another issue I've been meaning to bring up is that >> if you want forward secrecy, you need to use Diffie- >> Hellman; however, there is no way to tell the server >> the size of the parameter p you want. Increasing the >> size of p has significant performance implications, >> so servers will typically use 1024 bits. >> [...] It would be better if those >> who want to use 4096 bits could ask for it. > > Again, please present some evidence that this is a real > practical issue outside of a very small population of > keylength fetishists. RSA key exchange provides up to 368 bits of security, but doesn't provide forward secrecy. If I want forward secrecy, then I need to use Diffie-Hellman. A server that has 1024- bit Diffie-Hellman parameters only provides me with some- where in the neighborhood of 70-80 bits of security (extrapolated from the data in RFC 3526). You are saying that I am a "keylength fetishist" because I want better than 70-80 bits of security? So I'm allowed either lots of "strength" *or* forward secrecy, but not both? That's irresponsible. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 00:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5F-0005aV-Qp; Fri, 12 Oct 2007 00:25:09 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgC5E-0005Zj-MH for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 00:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgC5E-0005ZX-BI for tls@ietf.org; Fri, 12 Oct 2007 00:25:08 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgC5D-0002xu-2X for tls@ietf.org; Fri, 12 Oct 2007 00:25:08 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id E0FD92EF for ; Fri, 12 Oct 2007 00:25:27 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id B1912862AF for ; Fri, 12 Oct 2007 00:25:27 -0400 (EDT) Message-ID: <470EF791.5010405@pobox.com> Date: Thu, 11 Oct 2007 21:26:57 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] comments & clarifications for rfc4507bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>>> The description would be unabiguous if >>>> the text included a struct along the lines of: >>>> >>>> struct { >>>> opaque NewSessionTicket.ticket<1..2^16-1> >>>> } SessionTicket; >>> >>> The new struct actually reintroduces an issue with encoding that we >>> trying to correct with this revision. >> >> I'm afraid that leaving this portion of the description in >> textual form may lead to implementation bugs -- it would be >> nice to see a struct. >> > [Joe] It is the serialized ticket without the length encoding that would > be introduced by the struct encoding. The text has been modified to try > to remove this ambiguity. How about: struct { opaque NewSessionTicket.ticket[NewSessionTicket.ticket.length]; } SessionTicket; Not perfect, but better than nothing. I too was looking for a struct to define the extension data.... Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls eaving this portion of the description in >> textual form may lead to implementation bugs -- it would be >> nice to see a struct. >> > [Joe] It is the serialized ticket without the length encoding that would > be introduced by the struct encoding. The text has been modified to try > to remove this ambiguity. How about: struct { opaque NewSessionTicket.ticket[NewSessionTicket.ticket.length]; } SessionTicket; Not perfect, but better than nothing. I too was looking for a struct to define the extension data.... Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 00:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCBB-0005x1-U9; Fri, 12 Oct 2007 00:31:17 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgCB9-0005uo-TQ for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 00:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCB9-0005rg-Jd for tls@lists.ietf.org; Fri, 12 Oct 2007 00:31:15 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgCB0-000361-FE for tls@lists.ietf.org; Fri, 12 Oct 2007 00:31:07 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 4041B2F0 for ; Fri, 12 Oct 2007 00:30:59 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 100BE863B2 for ; Fri, 12 Oct 2007 00:30:58 -0400 (EDT) Message-ID: <470EF8DC.8060700@pobox.com> Date: Thu, 11 Oct 2007 21:32:28 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <20071011162153.GO24532@Sun.COM> In-Reply-To: <20071011162153.GO24532@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>> I think there is good reason to try to solve this problem >>> in the TLS layer. The alternative is to force every TLS- >>> enabled application to solve it (and likely they won't >>> solve it and be less secure). Wouldn't it be ideal if an >>> application could just say: >>> >>> TLS::SetSecurityLevel (3); >> No, it would not, because, I've now said several times, security is >> not expressible via a single metric, making this a complete rathole. > > Agreed. SASL used to have a notion of "security strength factor" (SSF), > and that was a disaster. > > Basically, the best you could do is have an application choose a > cryptographic profile by descriptive names like "strong" and "fast," but > where the content of such profiles is subject to change over time, and > perhaps even a local matter. Today "strong" might mean AES-128 is OK, > and tomorrow it might mean only AES-256 is OK, and the next day it might > mean something else, and so on. > > The easy answer is to give the application fewer choices, namely a > choice of locally-configured profiles (see above). > > In fact, I strongly urge TLS API developers to provide such a facility. I'm confused -- that is exactly what TLS::SetSecurityLevel (3); was intended to represent. Perhaps if I had not used the number 3, but instead used SECURITY_LEVEL_STRONG this would have made more sense to people? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 01:02:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCei-0005nW-PO; Fri, 12 Oct 2007 01:01:48 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgCeh-0005nG-Lt for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 01:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgCeh-0005n6-Bz for tls@lists.ietf.org; Fri, 12 Oct 2007 01:01:47 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgCed-0003sm-UJ for tls@lists.ietf.org; Fri, 12 Oct 2007 01:01:47 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DE16033C21; Thu, 11 Oct 2007 21:57:18 -0700 (PDT) Date: Thu, 11 Oct 2007 21:57:17 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470EF76B.5050102@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012045718.DE16033C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Thu, 11 Oct 2007 21:26:19 -0700, Mike wrote: > You've said that this is not possible because, for instance, > DES3 does not have a single value for the key length since > one attack renders its effective strength at 168 bits, while > another weakens it to 112 bits. I would say that you would > have to go with the lower 112 bits, and perhaps you wouldn't > even allow it at level 1. Well, I consider 168 bits a lot more accurate under most threat models--which is of course the point. As for "level 1", I don't even understand what you're saying here. 3DES is plenty secure for any known application. The difference between 112 and 168 is basically insignificant for any practical application. The existence (or nonexistence) of known (or unknown) analytic attacks is much more important. > I have to admit I don't know the > subtleties of elliptic curve cryptography to know how to > translate "level 2" to a list of acceptable curves and key > lengths, but I'm sure someone on this list does. No, it's not clear that it's known, actually. As another example, how do you compare 1024 bits with PFS to 1024 bits without? > Right now all cipher suites are under-specified. If we had, > for example: > > TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA > > we would probably not be talking about this. I proposed that > we let clients "fill in the blanks" that the cipher suites > don't specify. Isn't it better to tell the server exactly > what you want in terms of security, than to leave it up to > chance? Arguably, it would have been, but it's not the way that the system is now, and I haven't seen an argument that this needs to change.. > I'm an interface designer, and believe that the average > application developer has only a boolean view of security: > either security (TLS) is enabled, or it isn't. It's easy > to extend that to a 3 or 4 level security model, but beyond > that, you're asking for trouble. (A TLS toolkit would still > provide a security expert full control of course.) You should feel free to do this in your implementation. I'm only objecting to TLS-WG being involved. [Yngve's report of extremely weak DH keys deleted]. > As far as Opera is concerned, I am considering a few options, including > automatically disabling the ephermal ciphersuites or re-sorting the > cipher suite list toplace them last, and renegotiate the connection. > > [Apparently my memory was incorrect and the session was > renegotiated instead of the close->reconnect->negotiate > sequence I stated; however, support for renegotiation is > optional, so it may not always work.] Yes, yes, I know about all this. But as I said, use of a 256-bit DH group (and probably 512-bit) is a clear implementation error. > >> The folks at Opera Software have expressed how difficult > >> it was to secure their browser, and how insecure some > >> servers are (256-bit DH parameters!). > > > > Yes that's interesting but irrelevant. Those are pretty > > clearly mistakes on the server side, as are RSA e values > > of 1. Neither is likely to be fixed by specifying security > > levels in the way you suggest. > > This proves my point -- lots of application developers and/ > or server operators don't understand this stuff to the level > required to make all the right choices. Yes, I agree that they don't but it's not clear to me why you think that having the client express its opinion improves the situation, given that the problem is that the server is misconfigured. > >> Another issue I've been meaning to bring up is that > >> if you want forward secrecy, you need to use Diffie- > >> Hellman; however, there is no way to tell the server > >> the size of the parameter p you want. Increasing the > >> size of p has significant performance implications, > >> so servers will typically use 1024 bits. > >> [...] It would be better if those > >> who want to use 4096 bits could ask for it. > > > > Again, please present some evidence that this is a real > > practical issue outside of a very small population of > > keylength fetishists. > > RSA key exchange provides up to 368 bits of security, but > doesn't provide forward secrecy. As does DH with appropriate key sizes. RSA and DH have approximately equivalent strengths with the same modulus size. > If I want forward secrecy, > then I need to use Diffie-Hellman. A server that has 1024- > bit Diffie-Hellman parameters only provides me with some- > where in the neighborhood of 70-80 bits of security > (extrapolated from the data in RFC 3526). You are saying > that I am a "keylength fetishist" because I want better > than 70-80 bits of security? So I'm allowed either lots > of "strength" *or* forward secrecy, but not both? That's > irresponsible. Nobody is stopping you from using any DH key size you want with TLS (or RSA, for that matter.) It's just that the server controls the key size with no input from the client. I have yet to see any evidence that there's substantial demand from clients for input on the key size. That said, if you really care, you can use ECC, which *does* permit the client to advertise the groups it wants. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 13:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOiu-0007oI-6U; Fri, 12 Oct 2007 13:54:56 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgOit-0007nj-4o for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOis-0007PO-QA for tls@lists.ietf.org; Fri, 12 Oct 2007 13:54:54 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOif-0006wZ-Pw for tls@lists.ietf.org; Fri, 12 Oct 2007 13:54:46 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id A19672F0 for ; Fri, 12 Oct 2007 13:54:21 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 6DC2F89737 for ; Fri, 12 Oct 2007 13:54:21 -0400 (EDT) Message-ID: <470FB525.7010308@pobox.com> Date: Fri, 12 Oct 2007 10:55:49 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> In-Reply-To: <20071012045718.DE16033C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> Right now all cipher suites are under-specified. If we had, >> for example: >> >> TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA >> >> we would probably not be talking about this. I proposed that >> we let clients "fill in the blanks" that the cipher suites >> don't specify. Isn't it better to tell the server exactly >> what you want in terms of security, than to leave it up to >> chance? > > Arguably, it would have been, but it's not the way that the > system is now.... I thought of an easier way to achieve this that should be less controversial and simple to implement. As an extension, it would be completely optional as well, but I believe it would be widely implemented: enum { diffie_hellman_parameter (0), server_rsa_key (1), ca_rsa_key (2), server_dsa_key (3), ca_dsa_key (4), .... (65535) } KeyType; struct { KeyType key_type; uint24 preferred_size; } PreferredKeySize; struct { PreferredKeySize sizes<0..2^16-1>; } PreferredKeySizeExtension; A server that understands this extension would reply with an empty extension_data. The server would do its best to select keys, certificate chains, and DH parameters to satisfy the client's request. If it is unable or unwilling to do so, the negotiation should proceed giving the client the opportunity to accept weaker parameters than it asked for. (Or a boolean value could be added to the extension indicating whether the client might accept weaker parameters; if not, the server could immediately send a fatal insufficient_security alert.) > and I haven't seen an argument that this > needs to change.. The server's response would let the client know that it would be a waste of time to try negotiating again with different cipher suites if it found the key lengths to be unacceptable. Clients and servers would spend less time performing fruitless renegotiations, which would reduce server throughput. This seems like a good argument to me. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 14:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOx1-0001jm-Lw; Fri, 12 Oct 2007 14:09:31 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgOx0-0001ja-AR for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOx0-0001jS-0t for tls@lists.ietf.org; Fri, 12 Oct 2007 14:09:30 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOwq-0007MT-4Q for tls@lists.ietf.org; Fri, 12 Oct 2007 14:09:30 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1D22D33C21; Fri, 12 Oct 2007 11:04:45 -0700 (PDT) Date: Fri, 12 Oct 2007 11:04:44 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470FB525.7010308@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012180445.1D22D33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 10:55:49 -0700, Mike wrote: > The server's response would let the client know that it would > be a waste of time to try negotiating again with different > cipher suites if it found the key lengths to be unacceptable. > Clients and servers would spend less time performing fruitless > renegotiations, which would reduce server throughput. This > seems like a good argument to me. Yes, but it's unconvincing to me for reasons I've already stated. When I start to hear stories about repeated client reconnect probes due to key size mismatches *for reasons other than obvious server config errors*, I'll get interested in this. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 15:04:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPmp-0004ry-UY; Fri, 12 Oct 2007 15:03:03 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgPmp-0004rt-28 for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPmo-0004jG-OT for tls@lists.ietf.org; Fri, 12 Oct 2007 15:03:02 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPmY-0000YG-NX for tls@lists.ietf.org; Fri, 12 Oct 2007 15:02:55 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 5DA3C147540 for ; Fri, 12 Oct 2007 15:02:48 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 30ACC147309 for ; Fri, 12 Oct 2007 15:02:47 -0400 (EDT) Message-ID: <470FC52E.6080707@pobox.com> Date: Fri, 12 Oct 2007 12:04:14 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> In-Reply-To: <20071012180445.1D22D33C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> The server's response would let the client know that it would >> be a waste of time to try negotiating again with different >> cipher suites if it found the key lengths to be unacceptable. >> Clients and servers would spend less time performing fruitless >> renegotiations, which would reduce server throughput. This >> seems like a good argument to me. > > Yes, but it's unconvincing to me for reasons I've already stated. > When I start to hear stories about repeated client reconnect > probes due to key size mismatches *for reasons other than obvious > server config errors*, I'll get interested in this. Apparently no argument will suffice, and you would rather keep the status quo than be proactive. How long do you think it would take to add this extension to a TLS toolkit? In my own code, I could probably do it in less than a day, with time left over to get in a round of 18 holes. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 15:27:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQ9b-0002bk-Um; Fri, 12 Oct 2007 15:26:35 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQ9b-0002b8-8o for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQ9a-0002b0-VW for tls@lists.ietf.org; Fri, 12 Oct 2007 15:26:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQ9Z-0001Un-Lv for tls@lists.ietf.org; Fri, 12 Oct 2007 15:26:34 -0400 Received: from [192.168.1.3] (adsl-216-139-154-36.nyct.net [216.139.154.36]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9CJQUki078076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2007 12:26:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <470FC52E.6080707@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> Date: Fri, 12 Oct 2007 15:26:26 -0400 To: Mike , tls@lists.ietf.org From: Paul Hoffman Subject: Re: [TLS] security levels for TLS Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 12:04 PM -0700 10/12/07, Mike wrote: >Apparently no argument will suffice, and you would rather keep the >status quo than be proactive. How long do you think it would take >to add this extension to a TLS toolkit? In my own code, I could >probably do it in less than a day, with time left over to get in a >round of 18 holes. No doubt. Of what positive and negative value would such code be? Confusing and/or giving users false senses of security are definitely negative. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 15:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQKw-0003fP-4E; Fri, 12 Oct 2007 15:38:18 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQKu-0003dD-Tz for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQKu-0003ZE-Jr for tls@lists.ietf.org; Fri, 12 Oct 2007 15:38:16 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQKk-0001pW-O8 for tls@lists.ietf.org; Fri, 12 Oct 2007 15:38:12 -0400 Received: by nf-out-0910.google.com with SMTP id 4so956329nfv for ; Fri, 12 Oct 2007 12:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Bh0OMHHWvvTghC1V4fJbfjht7MTmRb16mmT83x6Gkkg=; b=ek8Zwcmx9w5llzrT25g/GUGhxClmCKfb6T4M9WDQpBtv295PQSrLD7YuuoDbmd5OLokCiH+7ojwvtq4FG72RmcSetbgnMl0qycFa2rd/TK4a6202VV2thIZK5IP2UG5O98bJlNKRQ899n0EHJ1x/cQOwl+LA7Xe1qJIBRkkP4sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ujm8Xe1PORk5m/9TUkHMYKMg02bmRlDKmIWvHKeRhaMd11OzMFnMaiWr47jHwJIBLX6qB8bnVDB+HaBdV4LXGBlGHIOQoGIqIS5WDtRp2tG3Z29x8IgBi84WWE3SAlzhG82jdZYhUdIWTllUi3Y28XhAQPJfAhjaH8BDvs/Ovg0= Received: by 10.86.98.18 with SMTP id v18mr2611051fgb.1192217854637; Fri, 12 Oct 2007 12:37:34 -0700 (PDT) Received: from crystal.lan ( [77.49.71.58]) by mx.google.com with ESMTPS id f31sm2097328fkf.2007.10.12.12.37.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2007 12:37:33 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS Date: Fri, 12 Oct 2007 22:37:30 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470FC52E.6080707@pobox.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710122237.30517.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Friday 12 October 2007, Paul Hoffman wrote: > At 12:04 PM -0700 10/12/07, Mike wrote: > >Apparently no argument will suffice, and you would rather keep the > >status quo than be proactive. How long do you think it would take > >to add this extension to a TLS toolkit? In my own code, I could > >probably do it in less than a day, with time left over to get in a > >round of 18 holes. > > No doubt. Of what positive and negative value would such code be? > Confusing and/or giving users false senses of security are definitely > negative. Actually I think the latter sentence describes the current situation! regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 16:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQkX-0000au-86; Fri, 12 Oct 2007 16:04:45 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQkV-0000a7-SW for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQkV-0000Zz-Iv for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:43 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQkT-0002pN-RD for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:43 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 70EEA33C23; Fri, 12 Oct 2007 13:00:32 -0700 (PDT) Date: Fri, 12 Oct 2007 13:00:32 -0700 From: Eric Rescorla To: Nikos Mavrogiannopoulos Subject: Re: [TLS] security levels for TLS In-Reply-To: <200710122237.30517.nmav@gnutls.org> References: <470FC52E.6080707@pobox.com> <200710122237.30517.nmav@gnutls.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012200032.70EEA33C23@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 22:37:30 +0300, Nikos Mavrogiannopoulos wrote: > > On Friday 12 October 2007, Paul Hoffman wrote: > > At 12:04 PM -0700 10/12/07, Mike wrote: > > >Apparently no argument will suffice, and you would rather keep the > > >status quo than be proactive. How long do you think it would take > > >to add this extension to a TLS toolkit? In my own code, I could > > >probably do it in less than a day, with time left over to get in a > > >round of 18 holes. > > > > No doubt. Of what positive and negative value would such code be? > > Confusing and/or giving users false senses of security are definitely > > negative. > > Actually I think the latter sentence describes the current situation! How so? Nothing at all stops you from putting any indicator you like in your code. Why does IETF have to standardize it? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 16:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQjz-0000EM-6M; Fri, 12 Oct 2007 16:04:11 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQjx-0000E1-UW for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQjx-0000Dt-L3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQjw-0002oF-E3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7B05733C21; Fri, 12 Oct 2007 12:59:52 -0700 (PDT) Date: Fri, 12 Oct 2007 12:59:51 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470FC52E.6080707@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012195952.7B05733C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 12:04:14 -0700, Mike wrote: > > >> The server's response would let the client know that it would > >> be a waste of time to try negotiating again with different > >> cipher suites if it found the key lengths to be unacceptable. > >> Clients and servers would spend less time performing fruitless > >> renegotiations, which would reduce server throughput. This > >> seems like a good argument to me. > > > > Yes, but it's unconvincing to me for reasons I've already stated. > > When I start to hear stories about repeated client reconnect > > probes due to key size mismatches *for reasons other than obvious > > server config errors*, I'll get interested in this. > > Apparently no argument will suffice, and you would rather keep the > status quo than be proactive. Say rather that I would rather not make unnecessary modifications to a stable standard. As for the claim that "no argument will suffice", the message you replied to pretty clearly spelled out what would suffice, so I'll take this message as meaning that you don't have any real evidence along these lines. > How long do you think it would take > to add this extension to a TLS toolkit? This does not seem to me to be a relevant consideration. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 16:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQkX-0000au-86; Fri, 12 Oct 2007 16:04:45 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQkV-0000a7-SW for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQkV-0000Zz-Iv for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:43 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQkT-0002pN-RD for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:43 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 70EEA33C23; Fri, 12 Oct 2007 13:00:32 -0700 (PDT) Date: Fri, 12 Oct 2007 13:00:32 -0700 From: Eric Rescorla To: Nikos Mavrogiannopoulos Subject: Re: [TLS] security levels for TLS In-Reply-To: <200710122237.30517.nmav@gnutls.org> References: <470FC52E.6080707@pobox.com> <200710122237.30517.nmav@gnutls.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012200032.70EEA33C23@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 22:37:30 +0300, Nikos Mavrogiannopoulos wrote: > > On Friday 12 October 2007, Paul Hoffman wrote: > > At 12:04 PM -0700 10/12/07, Mike wrote: > > >Apparently no argument will suffice, and you would rather keep the > > >status quo than be proactive. How long do you think it would take > > >to add this extension to a TLS toolkit? In my own code, I could > > >probably do it in less than a day, with time left over to get in a > > >round of 18 holes. > > > > No doubt. Of what positive and negative value would such code be? > > Confusing and/or giving users false senses of security are definitely > > negative. > > Actually I think the latter sentence describes the current situation! How so? Nothing at all stops you from putting any indicator you like in your code. Why does IETF have to standardize it? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 16:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQjz-0000EM-6M; Fri, 12 Oct 2007 16:04:11 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQjx-0000E1-UW for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQjx-0000Dt-L3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQjw-0002oF-E3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7B05733C21; Fri, 12 Oct 2007 12:59:52 -0700 (PDT) Date: Fri, 12 Oct 2007 12:59:51 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470FC52E.6080707@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012195952.7B05733C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 12:04:14 -0700, Mike wrote: > > >> The server's response would let the client know that it would > >> be a waste of time to try negotiating again with different > >> cipher suites if it found the key lengths to be unacceptable. > >> Clients and servers would spend less time performing fruitless > >> renegotiations, which would reduce server throughput. This > >> seems like a good argument to me. > > > > Yes, but it's unconvincing to me for reasons I've already stated. > > When I start to hear stories about repeated client reconnect > > probes due to key size mismatches *for reasons other than obvious > > server config errors*, I'll get interested in this. > > Apparently no argument will suffice, and you would rather keep the > status quo than be proactive. Say rather that I would rather not make unnecessary modifications to a stable standard. As for the claim that "no argument will suffice", the message you replied to pretty clearly spelled out what would suffice, so I'll take this message as meaning that you don't have any real evidence along these lines. > How long do you think it would take > to add this extension to a TLS toolkit? This does not seem to me to be a relevant consideration. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 16:16:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQvO-0007aq-21; Fri, 12 Oct 2007 16:15:58 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQvM-0007Xo-Mf for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQvM-0007Xc-CO for tls@lists.ietf.org; Fri, 12 Oct 2007 16:15:56 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQvH-00035i-2P for tls@lists.ietf.org; Fri, 12 Oct 2007 16:15:56 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9CKFeSD011568 for ; Fri, 12 Oct 2007 20:15:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9CKFdXx000173 for ; Fri, 12 Oct 2007 14:15:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9CKFd26028265; Fri, 12 Oct 2007 15:15:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9CKFadj028264; Fri, 12 Oct 2007 15:15:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 12 Oct 2007 15:15:35 -0500 From: Nicolas Williams To: Mike Subject: Re: [TLS] security levels for TLS Message-ID: <20071012201535.GG24532@Sun.COM> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <20071011162153.GO24532@Sun.COM> <470EF8DC.8060700@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470EF8DC.8060700@pobox.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 11, 2007 at 09:32:28PM -0700, Mike wrote: > >The easy answer is to give the application fewer choices, namely a > >choice of locally-configured profiles (see above). > > > >In fact, I strongly urge TLS API developers to provide such a facility. > > I'm confused -- that is exactly what TLS::SetSecurityLevel (3); > was intended to represent. Perhaps if I had not used the number > 3, but instead used SECURITY_LEVEL_STRONG this would have made > more sense to people? It's not what was requested early on in this thread. Local, named profiles -> good. Standard profiles with absolute security ratings associated with them -> super bad. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 16:24:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgR39-0003Pz-7W; Fri, 12 Oct 2007 16:23:59 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgR37-0003Pt-4O for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgR36-0003KK-R3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:23:56 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgR2x-0003OS-FP for tls@lists.ietf.org; Fri, 12 Oct 2007 16:23:48 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9CKNWUm003749 for ; Fri, 12 Oct 2007 20:23:32 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9CKNWqo001976 for ; Fri, 12 Oct 2007 14:23:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9CKNWRA028272; Fri, 12 Oct 2007 15:23:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9CKNWHM028271; Fri, 12 Oct 2007 15:23:32 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 12 Oct 2007 15:23:32 -0500 From: Nicolas Williams To: Mike Subject: Re: [TLS] security levels for TLS Message-ID: <20071012202331.GH24532@Sun.COM> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470FC52E.6080707@pobox.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Fri, Oct 12, 2007 at 12:04:14PM -0700, Mike wrote: > Apparently no argument will suffice, and you would rather keep the > status quo than be proactive. How long do you think it would take > to add this extension to a TLS toolkit? In my own code, I could > probably do it in less than a day, with time left over to get in a > round of 18 holes. That's not a helpful argument. I suggest you go look at SASL's SSF concept and why noone cares for it. There's lots of mailing list archive material to wade through! Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 17:43:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSFo-00073J-Ni; Fri, 12 Oct 2007 17:41:08 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgSFn-000733-Dd for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSFn-00070W-3y for tls@lists.ietf.org; Fri, 12 Oct 2007 17:41:07 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSFW-0005sk-O1 for tls@lists.ietf.org; Fri, 12 Oct 2007 17:40:56 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 1A7A02EF for ; Fri, 12 Oct 2007 17:40:24 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id D954A89367 for ; Fri, 12 Oct 2007 17:40:23 -0400 (EDT) Message-ID: <470FEA1F.7030500@pobox.com> Date: Fri, 12 Oct 2007 14:41:51 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> How long do you think it would take >> to add this extension to a TLS toolkit? In my own code, I could >> probably do it in less than a day, with time left over to get in a >> round of 18 holes. > > No doubt. Of what positive and negative value would such code be? Positives: - this would allow a server to maintain multiple sets of keys and certificate chains of varying cryptographic strength; clients with differing requirements could ask for the level they desire, instead of being stuck with the lowest common denominator - a server could support multiple sets of Diffie-Hellman parameters, such as all of the groups in RFC 3526; a client could choose the parameters rather than being forced to accept the server's default (which is probably chosen more for performance than security) - knowing exactly what the client is looking for helps the server select the appropriate cipher suite without the need for the client to renegotiate the connection; for example, if the server only supports 1024-bit DH parameters, and the client asks for 1536-bit, the server can skip past the DHE_* cipher suites and select maybe an RSA-based cipher suite that the client would accept - this mechanism would give power to the client that it currently doesn't have, to directly influence the crypto- graphic strength of the connection beyond simply listing acceptable cipher suites - hash agility (or now signature algorithm agility) is being added to TLS; this is cryptographic strength agility - a client is free to develop its own security profiles; no "standard" profiles would be defined - a server can keep statistics on the values it receives, allowing an administrator to know when it would make sense to add support for longer keys, based on actual demand Negatives: - effort is needed to write a specification and approve it - a server may not support the extension, so a client may have to implement an inefficient renegotiation scheme in addition anyway - Eric doesn't like it ;-) - Others? > Confusing and/or giving users false senses of security are definitely > negative. Fully agreed. I don't see how this would be confusing or give a false sense of security. The client still has to check that the requested key lengths (and other parameters it cares about) are satisfied in the negotiated session. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 17:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSVN-0002jE-AP; Fri, 12 Oct 2007 17:57:13 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgSVL-0002iz-Ug for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSVL-0002gC-L9 for tls@lists.ietf.org; Fri, 12 Oct 2007 17:57:11 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSV8-0006Gx-Hb for tls@lists.ietf.org; Fri, 12 Oct 2007 17:57:04 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 38D90147759 for ; Fri, 12 Oct 2007 17:56:53 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 09B57147744 for ; Fri, 12 Oct 2007 17:56:52 -0400 (EDT) Message-ID: <470FEDFB.3030106@pobox.com> Date: Fri, 12 Oct 2007 14:58:19 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <20071012195952.7B05733C21@delta.rtfm.com> In-Reply-To: <20071012195952.7B05733C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > As for the claim that "no argument will suffice", the message you > replied to pretty clearly spelled out what would suffice, so > I'll take this message as meaning that you don't have any > real evidence along these lines. That comment was made out of frustration, and I apologize for it. >> How long do you think it would take >> to add this extension to a TLS toolkit? > > This does not seem to me to be a relevant consideration. I just responded to Paul with a list of a half dozen benefits of adding this extension. If you agree that the benefits are of value, then the fact that it's easy to implement is a bonus. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 18:00:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSYF-0003cc-24; Fri, 12 Oct 2007 18:00:11 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgSYD-0003bt-AH for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 18:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSYD-0003bl-0e for tls@lists.ietf.org; Fri, 12 Oct 2007 18:00:09 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSY6-0006Ju-Q8 for tls@lists.ietf.org; Fri, 12 Oct 2007 18:00:08 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9CLx12d008662 for ; Fri, 12 Oct 2007 21:59:02 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9CLx1Ye002469 for ; Fri, 12 Oct 2007 15:59:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9CLx1OS028401; Fri, 12 Oct 2007 16:59:01 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9CLx1C1028400; Fri, 12 Oct 2007 16:59:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 12 Oct 2007 16:59:01 -0500 From: Nicolas Williams To: Mike Subject: Re: [TLS] security levels for TLS Message-ID: <20071012215901.GR24532@Sun.COM> References: <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470FEA1F.7030500@pobox.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Fri, Oct 12, 2007 at 02:41:51PM -0700, Mike wrote: > >>How long do you think it would take > >>to add this extension to a TLS toolkit? In my own code, I could > >>probably do it in less than a day, with time left over to get in a > >>round of 18 holes. > > > >No doubt. Of what positive and negative value would such code be? > > Positives: > > - this would allow a server to maintain multiple sets of keys > and certificate chains of varying cryptographic strength; > clients with differing requirements could ask for the level > they desire, instead of being stuck with the lowest common > denominator It can do things like this today. > - knowing exactly what the client is looking for helps the > server select the appropriate cipher suite without the need > for the client to renegotiate the connection; for example, > if the server only supports 1024-bit DH parameters, and the > client asks for 1536-bit, the server can skip past the DHE_* > cipher suites and select maybe an RSA-based cipher suite > that the client would accept The server and client already know how to negotiate properly. > - this mechanism would give power to the client that it > currently doesn't have, to directly influence the crypto- > graphic strength of the connection beyond simply listing > acceptable cipher suites The client already can negotiate from what it's willing to accept, and that's sufficient. > - hash agility (or now signature algorithm agility) is being > added to TLS; this is cryptographic strength agility You're ignoring everything we've been telling you about why absolute security measurements of ciphersuites are not a good idea. > - a client is free to develop its own security profiles; no > "standard" profiles would be defined The client and server are already free to do so. > - a server can keep statistics on the values it receives, > allowing an administrator to know when it would make sense > to add support for longer keys, based on actual demand The server can already do this. > Negatives: > > - effort is needed to write a specification and approve it > - a server may not support the extension, so a client may > have to implement an inefficient renegotiation scheme in > addition anyway > - Eric doesn't like it ;-) > - Others? This is not about personal preferences. We're telling you this is not needed and that fixed absolute cryptographic strength numbers are neither feasible nor a good idea. > >Confusing and/or giving users false senses of security are definitely > >negative. > > Fully agreed. I don't see how this would be confusing or give > a false sense of security. The client still has to check that > the requested key lengths (and other parameters it cares about) > are satisfied in the negotiated session. Eric points out that local policy is sufficient to achieve what you want. I do think that a standard way to describe security policies for TLS and other protocols might be useful for distributing policy, but at the end of the day that'd still be _local_ policy, with no changes to TLS being required. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 19:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTi6-0004QP-DZ; Fri, 12 Oct 2007 19:14:26 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgTi5-0004OZ-Lc for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 19:14:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTi5-0003sE-C4 for tls@lists.ietf.org; Fri, 12 Oct 2007 19:14:25 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgThp-0000El-CD for tls@lists.ietf.org; Fri, 12 Oct 2007 19:14:15 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id BBDBA2EF for ; Fri, 12 Oct 2007 19:13:57 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id F24DB8996E for ; Fri, 12 Oct 2007 19:13:56 -0400 (EDT) Message-ID: <4710000A.7020006@pobox.com> Date: Fri, 12 Oct 2007 16:15:22 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470FC52E.6080707@pobox.com> <200710122237.30517.nmav@gnutls.org> <20071012200032.70EEA33C23@delta.rtfm.com> In-Reply-To: <20071012200032.70EEA33C23@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>> Confusing and/or giving users false senses of security are definitely >>> negative. >> Actually I think the latter sentence describes the current situation! > > How so? Nothing at all stops you from putting any indicator you > like in your code. Why does IETF have to standardize it? I think there is some mis-communication going on. I have never even mentioned the IETF standardizing an "indicator" of security level. Someone else may have, but I reject that idea as well. All I've proposed is that the client send a few extra bytes of information specifying the sizes of keys/parameters that are not defined by the cipher suites. Every client is free to determine what it thinks is acceptable in this regard. There would be no "standard profiles" or even "suggested profiles" since over time they would become outdated. Here is a simple code example of what I envision: TlsSecurityProfile profile_Generic; TlsSecurityProfile profile_Strong; profile_Generic.SetRSAKeyLength (1024, 900); // desired, minimum profile_Generic.SetDSAKeyLength (1024, 900); profile_Generic.SetDHParameterSize (1024, 1000); profile_Strong.SetRSAKeyLength (2048, 2000); profile_Strong.SetDSAKeyLength (2048, 2000); profile_Strong.SetDHParameterSize (1536, 1536); ConnectTLS ("www.amazon.com:443", profile_Generic); ConnectTLS ("www.mybank.com:443", profile_Strong); Currently TLS cannot totally support this interface, but with the extension I proposed, it could. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 20:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUPc-0001Jq-Dz; Fri, 12 Oct 2007 19:59:24 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgUPb-0001Iw-1z for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 19:59:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUPa-0001Ij-Oi for tls@lists.ietf.org; Fri, 12 Oct 2007 19:59:22 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgUPU-0002RV-Ik for tls@lists.ietf.org; Fri, 12 Oct 2007 19:59:22 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E3DFC33C21; Fri, 12 Oct 2007 15:00:36 -0700 (PDT) Date: Fri, 12 Oct 2007 15:00:36 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <470FEA1F.7030500@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071012220036.E3DFC33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 14:41:51 -0700, Mike wrote: > > >> How long do you think it would take > >> to add this extension to a TLS toolkit? In my own code, I could > >> probably do it in less than a day, with time left over to get in a > >> round of 18 holes. > > > > No doubt. Of what positive and negative value would such code be? > > Positives: > > - this would allow a server to maintain multiple sets of keys > and certificate chains of varying cryptographic strength; > clients with differing requirements could ask for the level > they desire, instead of being stuck with the lowest common > denominator > - a server could support multiple sets of Diffie-Hellman > parameters, such as all of the groups in RFC 3526; a client > could choose the parameters rather than being forced to > accept the server's default (which is probably chosen more > for performance than security) Note that the server can already maintain multiple keys and choose one based on the cipher suite. It's merely that the client can't *directly* request specific asymmetric key sizes for DH and RSA. > Negatives: > > - effort is needed to write a specification and approve it > - a server may not support the extension, so a client may > have to implement an inefficient renegotiation scheme in > addition anyway - It encourages an inappropriate focus on key size. As I said already, There's a lot more to security than key size. - It adds yet more unnecessary complexity to a spec which is already quite complicated. - It's yet another way to have interop problems. - Implementations which want DH key sizes significantly greater than 1024 would be better served to move to EC, which already has explicit support for communicating which groups are supported. > - Eric doesn't like it ;-) I don't see you getting a lot of support from others, either. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 20:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUUR-0004kQ-Be; Fri, 12 Oct 2007 20:04:23 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgUUP-0004fr-RD for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 20:04:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUUP-0004fj-Hl for tls@lists.ietf.org; Fri, 12 Oct 2007 20:04:21 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgUUO-0002e4-Ax for tls@lists.ietf.org; Fri, 12 Oct 2007 20:04:21 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F21A233C21; Fri, 12 Oct 2007 17:00:10 -0700 (PDT) Date: Fri, 12 Oct 2007 17:00:10 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <4710000A.7020006@pobox.com> References: <470FC52E.6080707@pobox.com> <200710122237.30517.nmav@gnutls.org> <20071012200032.70EEA33C23@delta.rtfm.com> <4710000A.7020006@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071013000010.F21A233C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 16:15:22 -0700, Mike wrote: > > >>> Confusing and/or giving users false senses of security are definitely > >>> negative. > >> Actually I think the latter sentence describes the current situation! > > > > How so? Nothing at all stops you from putting any indicator you > > like in your code. Why does IETF have to standardize it? > > I think there is some mis-communication going on. I have never > even mentioned the IETF standardizing an "indicator" of security > level. Someone else may have, but I reject that idea as well. Well, two things seem to be being discussed simultaneously: 1. Standardizing simplified "levels" of security which correspond to cipher suites and key sizes. E.g., STRONG would be symmetric algorithm X or Y with asymmetric algorithm A and key size a or asymmetric algorithm B with key size b. MEDIUM is symmetric algorithm W with asymmetric algorithm A with key size a' or asymmetric algorithm B with key size b'. This is purely a documentation issue and doesn't require any on-the-wire changes to TLS. 2. Modifying TLS to allow the client to indicate the size of the keys/group it would like for each asymmetric algorithm. This is an on-the-wire protocol change. As I understand your messages, you've been endorsing both of these. I'm against both of these, for related, but distinct reasons. I'm against the former because I think it's actually very hard to produce any reasonable standardized account of which algorithms and key sizes fit into which level. In any case, this is something that an implementation can easily offer without any standard, it simply will not necessarily have the same level->algorithm mapping as another implementation. I'm against the second because I believe it adds marginal benefit at a significant cost to interoperability and complexity. An extension like this only makes sense if: 1. Servers have a number of different kinds of keying material of different strengths. 2. Clients are in a position to make intelligent choices about which asymmetric key strengths are appropriate. In my experience, neither is true. Moreover, it's worth noting that in the current environment any client which attempts to request a key > 1024 bits will find that it can connect to practically nobody. To a first order, this is just another way to create interop problems. With regard to key lengths: as I indicated before, the dominant security issue in systems of this kind is quality of implementation and maintenance. If you don't trust the server to choose appropriate key sizes, why on earth would you trust that it's not chock full of remote vulnerabilities? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 20:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUi5-0006Yu-N3; Fri, 12 Oct 2007 20:18:29 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgUi4-0006Y3-8m for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 20:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUi3-0006SV-Si for tls@lists.ietf.org; Fri, 12 Oct 2007 20:18:27 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgUht-000365-OH for tls@lists.ietf.org; Fri, 12 Oct 2007 20:18:23 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 195202F2 for ; Fri, 12 Oct 2007 20:17:18 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id C975B899D2 for ; Fri, 12 Oct 2007 20:17:17 -0400 (EDT) Message-ID: <47100EE5.9070103@pobox.com> Date: Fri, 12 Oct 2007 17:18:45 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> <20071012215901.GR24532@Sun.COM> In-Reply-To: <20071012215901.GR24532@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> - this would allow a server to maintain multiple sets of keys >> and certificate chains of varying cryptographic strength; >> clients with differing requirements could ask for the level >> they desire, instead of being stuck with the lowest common >> denominator > > It can do things like this today. How? The ClientHello only has a list of cipher suites to go by, and they don't specify the sizes of the asymmetric keys. [You removed the benefit of being able to specify the size of DH parameters, so I'll assume you know you can't currently do that today. That alone is worth adding this extension, in my opinion.] >> - knowing exactly what the client is looking for helps the >> server select the appropriate cipher suite without the need >> for the client to renegotiate the connection; for example, >> if the server only supports 1024-bit DH parameters, and the >> client asks for 1536-bit, the server can skip past the DHE_* >> cipher suites and select maybe an RSA-based cipher suite >> that the client would accept > > The server and client already know how to negotiate properly. No, they don't. If a server sees a DHE_* cipher suite in the ClientHello, but doesn't know that the client wants 1536-bit (or larger) parameters, it may select it, even though it only has 1024-bit parameters. The client would have to renegotiate the session without including the DHE cipher suites, which is an avoidable waste of computing resources. >> - this mechanism would give power to the client that it >> currently doesn't have, to directly influence the crypto- >> graphic strength of the connection beyond simply listing >> acceptable cipher suites > > The client already can negotiate from what it's willing to accept, and > that's sufficient. Instead of "sufficient" I would say it is "tolerable, but lacking." >> - hash agility (or now signature algorithm agility) is being >> added to TLS; this is cryptographic strength agility > > You're ignoring everything we've been telling you about why absolute > security measurements of ciphersuites are not a good idea. I've never said anything about absolute security measurements. Why are all the security experts against specifying the relevant parameters? Why is it wrong for a TLS client to tell the server that it wants to use 2048-bit RSA keys? >> - a client is free to develop its own security profiles; no >> "standard" profiles would be defined > > The client and server are already free to do so. Right, but if the profile says, "accept 2048-bit RSA keys," there is no way for the client to tell the server that that is what it wants. >> - a server can keep statistics on the values it receives, >> allowing an administrator to know when it would make sense >> to add support for longer keys, based on actual demand > > The server can already do this. How can it do that if this extension doesn't even exist? >> Negatives: >> >> - effort is needed to write a specification and approve it >> - a server may not support the extension, so a client may >> have to implement an inefficient renegotiation scheme in >> addition anyway >> - Eric doesn't like it ;-) >> - Others? > > This is not about personal preferences. That's why I put a wink after it. > We're telling you this is not > needed and that fixed absolute cryptographic strength numbers are > neither feasible nor a good idea. Again with the "fixed absolute cryptographic strength numbers." I have never said anything about that. Need is a crazy thing. Nobody needed a camera in their cell phone just a few years ago, but it's now hard to find one without a camera (in the U.S. at least). Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 20:41:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgV4H-0004bn-Bu; Fri, 12 Oct 2007 20:41:25 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgV4F-0004bM-TH for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 20:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgV4F-0004Yp-JQ for tls@lists.ietf.org; Fri, 12 Oct 2007 20:41:23 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgV48-0003vQ-Iy for tls@lists.ietf.org; Fri, 12 Oct 2007 20:41:18 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 4BD282F0 for ; Fri, 12 Oct 2007 20:40:58 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 172D7898DB for ; Fri, 12 Oct 2007 20:40:57 -0400 (EDT) Message-ID: <4710146E.4080909@pobox.com> Date: Fri, 12 Oct 2007 17:42:22 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> <20071012220036.E3DFC33C21@delta.rtfm.com> In-Reply-To: <20071012220036.E3DFC33C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Note that the server can already maintain multiple keys and choose one > based on the cipher suite. It's merely that the client can't *directly* > request specific asymmetric key sizes for DH and RSA. I'm proposing an extremely simple way to let the client directly request the desired key sizes. Isn't that better than hoping that the server replies with an acceptable key? >> Negatives: >> >> - effort is needed to write a specification and approve it >> - a server may not support the extension, so a client may >> have to implement an inefficient renegotiation scheme in >> addition anyway > > - It encourages an inappropriate focus on key size. As I said already, > There's a lot more to security than key size. But key size -is- a big part of it, and you should be able to tell a server what key sizes you want, rather than leave it up to chance. Let me express this in a different way: Imagine if TLS already had the ability for a client to specify key sizes to the server, and I was arguing to get rid of that. Wouldn't you think I was crazy for suggesting it? > - It adds yet more unnecessary complexity to a spec which is already > quite complicated. I'm aware of how complicated it is. I'm in the process of trying to add support for some of the existing extensions such as the trusted CA indication, and the complexity of that is so much more. > - It's yet another way to have interop problems. Isn't every addition? > - Implementations which want DH key sizes significantly greater than > 1024 would be better served to move to EC, which already has > explicit support for communicating which groups are supported. And pay someone for the right to generate a self-signed certificate? If you can do it with EC, why do you argue against doing it for DHE? >> - Eric doesn't like it ;-) > > I don't see you getting a lot of support from others, either. I find myself in this position occasionally, and accept that most people will stay out of the line of fire. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 20:41:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgV4f-0004mM-8x; Fri, 12 Oct 2007 20:41:49 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgV4e-0004m5-F0 for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 20:41:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgV4e-0004ll-4C for tls@lists.ietf.org; Fri, 12 Oct 2007 20:41:48 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgV4d-0007qw-MV for tls@lists.ietf.org; Fri, 12 Oct 2007 20:41:48 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E4C6D33C21; Fri, 12 Oct 2007 17:37:37 -0700 (PDT) Date: Fri, 12 Oct 2007 17:37:37 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <47100EE5.9070103@pobox.com> References: <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> <20071012215901.GR24532@Sun.COM> <47100EE5.9070103@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071013003737.E4C6D33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 17:18:45 -0700, Mike wrote: > >> - knowing exactly what the client is looking for helps the > >> server select the appropriate cipher suite without the need > >> for the client to renegotiate the connection; for example, > >> if the server only supports 1024-bit DH parameters, and the > >> client asks for 1536-bit, the server can skip past the DHE_* > >> cipher suites and select maybe an RSA-based cipher suite > >> that the client would accept > > > > The server and client already know how to negotiate properly. > > No, they don't. If a server sees a DHE_* cipher suite in the > ClientHello, but doesn't know that the client wants 1536-bit > (or larger) parameters, it may select it, even though it only > has 1024-bit parameters. The client would have to renegotiate > the session without including the DHE cipher suites, which is > an avoidable waste of computing resources. Look, this scenario is basically bogus now, and I suspect in the future. Nearly all servers have 1024-bit RSA keys signed by 1024-bit RSA CA keys. If they have DHE, then that's 1024-bit too. If the client wants 1536-bit anything, it's SOL, and neither asking for it in its ClientHello nor dropping DHE from its cipher suites and reconnecting will help. And even if the server *did* have multiple DHE groups, why would it be OK from the client's perspective to have those authenticated with a long-term 1024-bit RSA key? That's part of what people have been trying to tell you about absolute security levels. Now, one could certainly argue that in the future servers may have a variety of ephemeral DH parameters, but they're going to in general want to use the weakest one that's acceptable to them. Either this extension is mandatory to comply with (like ECC groups), in which case the client basically can't set it above 1024 or he won't be able to talk to most servers, or it's optional, in which case I would expect servers to ignore it, since it will reduce their performance and if they wanted stronger keys they would just use them. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 21:14:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVZG-0003sr-Rn; Fri, 12 Oct 2007 21:13:26 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgVZF-0003sk-Pl for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 21:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVZF-0003os-GG for tls@lists.ietf.org; Fri, 12 Oct 2007 21:13:25 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgVZ8-0005ed-BZ for tls@lists.ietf.org; Fri, 12 Oct 2007 21:13:19 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 0B6122EF for ; Fri, 12 Oct 2007 21:13:11 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id B9A46899D8 for ; Fri, 12 Oct 2007 21:13:10 -0400 (EDT) Message-ID: <47101BFE.6020300@pobox.com> Date: Fri, 12 Oct 2007 18:14:38 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <470FC52E.6080707@pobox.com> <200710122237.30517.nmav@gnutls.org> <20071012200032.70EEA33C23@delta.rtfm.com> <4710000A.7020006@pobox.com> <20071013000010.F21A233C21@delta.rtfm.com> In-Reply-To: <20071013000010.F21A233C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> I think there is some mis-communication going on. I have never >> even mentioned the IETF standardizing an "indicator" of security >> level. Someone else may have, but I reject that idea as well. > > Well, two things seem to be being discussed simultaneously: > > 1. Standardizing simplified "levels" of security which correspond to > cipher suites and key sizes. > > This is purely a documentation issue and doesn't require any > on-the-wire changes to TLS. > > 2. Modifying TLS to allow the client to indicate the size of the > keys/group it would like for each asymmetric algorithm. This > is an on-the-wire protocol change. > > As I understand your messages, you've been endorsing both of these. I said above that I reject the idea of standardizing levels. Why don't you believe that? You must be attributing someone else's statements with me. > I'm against both of these, for related, but distinct reasons. > > I'm against the former because I think it's actually very hard to > produce any reasonable standardized account of which algorithms and > key sizes fit into which level. In any case, this is something that an > implementation can easily offer without any standard, it simply will > not necessarily have the same level->algorithm mapping as another > implementation. I said in one of my first messages that this would be implementation dependent. > I'm against the second because I believe it adds marginal benefit > at a significant cost to interoperability and complexity. An > extension like this only makes sense if: > > 1. Servers have a number of different kinds of keying material > of different strengths. > 2. Clients are in a position to make intelligent choices about > which asymmetric key strengths are appropriate. > > In my experience, neither is true. Moreover, it's worth noting > that in the current environment any client which attempts to > request a key > 1024 bits will find that it can connect to > practically nobody. To a first order, this is just another > way to create interop problems. Well if you implement TLS 1.1 and expect to connect to anyone, you will be disappointed, and yet we're working even on TLS 1.2. There is always a transition period with new capabilities. > With regard to key lengths: as I indicated before, the dominant > security issue in systems of this kind is quality of implementation > and maintenance. If you don't trust the server to choose appropriate > key sizes, why on earth would you trust that it's not chock full > of remote vulnerabilities? Perhaps the server has different goals than you do -- it might want to maximize transactions. But maybe it would let you select better security if you asked for it. Currently there is no way to ask. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 12 21:34:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVs9-0004iy-39; Fri, 12 Oct 2007 21:32:57 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgVs7-0004gs-Fn for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 21:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVs7-0004gk-5w for tls@lists.ietf.org; Fri, 12 Oct 2007 21:32:55 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgVs2-0006Wi-0v for tls@lists.ietf.org; Fri, 12 Oct 2007 21:32:55 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id A1E1C147937 for ; Fri, 12 Oct 2007 21:32:57 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 6456B1478AC for ; Fri, 12 Oct 2007 21:32:57 -0400 (EDT) Message-ID: <471020A0.9080505@pobox.com> Date: Fri, 12 Oct 2007 18:34:24 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] security levels for TLS References: <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> <20071012215901.GR24532@Sun.COM> <47100EE5.9070103@pobox.com> <20071013003737.E4C6D33C21@delta.rtfm.com> In-Reply-To: <20071013003737.E4C6D33C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >> If a server sees a DHE_* cipher suite in the >> ClientHello, but doesn't know that the client wants 1536-bit >> (or larger) parameters, it may select it, even though it only >> has 1024-bit parameters. The client would have to renegotiate >> the session without including the DHE cipher suites, which is >> an avoidable waste of computing resources. > > Look, this scenario is basically bogus now, and I suspect > in the future. Right, and I want to fix that. > Nearly all servers have 1024-bit RSA keys signed by 1024-bit > RSA CA keys. If they have DHE, then that's 1024-bit too. > If the client wants 1536-bit anything, it's SOL, and neither > asking for it in its ClientHello nor dropping DHE from its > cipher suites and reconnecting will help. And even if the > server *did* have multiple DHE groups, why would it be > OK from the client's perspective to have those authenticated > with a long-term 1024-bit RSA key? That's part of what > people have been trying to tell you about absolute security > levels. Everyone uses 1024-bits because everyone else uses 1024-bits, and they feel a sense of security in numbers. In other words they can't be fired if something goes wrong because the whole industry does it. > Now, one could certainly argue that in the future servers > may have a variety of ephemeral DH parameters, but they're > going to in general want to use the weakest one that's > acceptable to them. Either this extension is mandatory > to comply with (like ECC groups), in which case the client > basically can't set it above 1024 or he won't be able to > talk to most servers, or it's optional, in which case > I would expect servers to ignore it, since it will reduce > their performance and if they wanted stronger keys they > would just use them. As we've both noted there are performance/security tradeoffs, and I believe the client is in a better position to decide what level of security is desired for any given transaction. The server doesn't know what operations the client is going to be requesting until after TLS is negotiated. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 13 03:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgbOC-0006Pw-3o; Sat, 13 Oct 2007 03:26:24 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgbOA-0006Pr-Pz for tls-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 03:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgbOA-0006Pj-GN for tls@lists.ietf.org; Sat, 13 Oct 2007 03:26:22 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgbO9-0000lD-9W for tls@lists.ietf.org; Sat, 13 Oct 2007 03:26:22 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 4343433C28; Sat, 13 Oct 2007 00:22:10 -0700 (PDT) Date: Sat, 13 Oct 2007 00:22:10 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <47101BFE.6020300@pobox.com> References: <470FC52E.6080707@pobox.com> <200710122237.30517.nmav@gnutls.org> <20071012200032.70EEA33C23@delta.rtfm.com> <4710000A.7020006@pobox.com> <20071013000010.F21A233C21@delta.rtfm.com> <47101BFE.6020300@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071013072210.4343433C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 18:14:38 -0700, Mike wrote: > > >> I think there is some mis-communication going on. I have never > >> even mentioned the IETF standardizing an "indicator" of security > >> level. Someone else may have, but I reject that idea as well. > > > > Well, two things seem to be being discussed simultaneously: > > > > 1. Standardizing simplified "levels" of security which correspond to > > cipher suites and key sizes. > > > > This is purely a documentation issue and doesn't require any > > on-the-wire changes to TLS. > > > > 2. Modifying TLS to allow the client to indicate the size of the > > keys/group it would like for each asymmetric algorithm. This > > is an on-the-wire protocol change. > > > > As I understand your messages, you've been endorsing both of these. > > I said above that I reject the idea of standardizing levels. Why > don't you believe that? Maybe because your writing has been fairly unclear. I read the following as such an endorsement: I think there is good reason to try to solve this problem in the TLS layer. The alternative is to force every TLS- enabled application to solve it (and likely they won't solve it and be less secure). Wouldn't it be ideal if an application could just say: TLS::SetSecurityLevel (3); If you say it's not, I believe you. > > I'm against both of these, for related, but distinct reasons. > > > > I'm against the former because I think it's actually very hard to > > produce any reasonable standardized account of which algorithms and > > key sizes fit into which level. In any case, this is something that an > > implementation can easily offer without any standard, it simply will > > not necessarily have the same level->algorithm mapping as another > > implementation. > > I said in one of my first messages that this would be implementation > dependent. That wasn't clear to me, but fine. > > I'm against the second because I believe it adds marginal benefit > > at a significant cost to interoperability and complexity. An > > extension like this only makes sense if: > > > > 1. Servers have a number of different kinds of keying material > > of different strengths. > > 2. Clients are in a position to make intelligent choices about > > which asymmetric key strengths are appropriate. > > > > In my experience, neither is true. Moreover, it's worth noting > > that in the current environment any client which attempts to > > request a key > 1024 bits will find that it can connect to > > practically nobody. To a first order, this is just another > > way to create interop problems. > > Well if you implement TLS 1.1 and expect to connect to anyone, > you will be disappointed, and yet we're working even on TLS 1.2. Yes, because it was felt that the attacks on MD5 and SHA-1 created an important need. Prior to those attacks, I had every intention of taking TLS 1.1 to draft standard without change. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 13 03:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgbLH-0000H6-IC; Sat, 13 Oct 2007 03:23:23 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgbLG-0000GR-Lm for tls-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 03:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgbLB-0000Em-Ck for tls@lists.ietf.org; Sat, 13 Oct 2007 03:23:17 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgbL8-0000g0-3l for tls@lists.ietf.org; Sat, 13 Oct 2007 03:23:17 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id CF47233C28; Sat, 13 Oct 2007 00:18:47 -0700 (PDT) Date: Sat, 13 Oct 2007 00:18:47 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <4710146E.4080909@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> <20071012220036.E3DFC33C21@delta.rtfm.com> <4710146E.4080909@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071013071847.CF47233C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 17:42:22 -0700, Mike wrote: > > - It encourages an inappropriate focus on key size. As I said already, > > There's a lot more to security than key size. > > But key size -is- a big part of it, and you should be able to tell > a server what key sizes you want, rather than leave it up to chance. Yes, you keep saying that, but you haven't convinced me. > Let me express this in a different way: > > Imagine if TLS already had the ability for a client to specify key > sizes to the server, and I was arguing to get rid of that. Wouldn't > you think I was crazy for suggesting it? Yes, because it would be an unnecessary change, exactly like the one you propose is. We're not designing in a vacuum, we've got an existing protocol that works well. That means that every proposed change requires justification. I don't think you've met that bar. > > - It's yet another way to have interop problems. > > Isn't every addition? Yes. Which is why every addition needs to be justified. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 13 03:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igbbo-00075n-9N; Sat, 13 Oct 2007 03:40:28 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Igbbm-00075h-PV for tls-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 03:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igbbm-00075Z-G5 for tls@lists.ietf.org; Sat, 13 Oct 2007 03:40:26 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igbbl-0001C1-9u for tls@lists.ietf.org; Sat, 13 Oct 2007 03:40:26 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5CDA833C28; Sat, 13 Oct 2007 00:36:14 -0700 (PDT) Date: Sat, 13 Oct 2007 00:36:13 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] security levels for TLS In-Reply-To: <4710146E.4080909@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> <20071012220036.E3DFC33C21@delta.rtfm.com> <4710146E.4080909@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071013073614.5CDA833C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Fri, 12 Oct 2007 17:42:22 -0700, Mike wrote: > >> Negatives: > >> > >> - effort is needed to write a specification and approve it > >> - a server may not support the extension, so a client may > >> have to implement an inefficient renegotiation scheme in > >> addition anyway > > > > - It encourages an inappropriate focus on key size. As I said already, > > There's a lot more to security than key size. > > But key size -is- a big part of it, and you should be able to tell > a server what key sizes you want, rather than leave it up to chance. To sharpen the point I was trying to make earlier, once you're using keys in the 1024-bit range, there are actually a number of other factors which are of equivalent if not larger importance to key size. These include: - The quality of PRNG used to generate the key. - Whether the key is being securely stored (e.g, in an HSM). - When we're talking DH, whether each ephemeral is fresh, and the structure of the DH group. - Which server is in use. - Whether the server software is up to date. The last two in particular are of vastly more importance than key size. I have never heard of a 1024-bit RSA key being cracked, yet I'm aware of remote vulnerabilities in every major C-based SSL server. These vulnerabilities lead to far easier private key extraction than factoring the modulus. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 13 15:19:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgmRs-0004Zg-JG; Sat, 13 Oct 2007 15:14:56 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgmRs-0004ZR-2w for tls-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 15:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgmRr-0004XE-P5 for tls@lists.ietf.org; Sat, 13 Oct 2007 15:14:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgmRo-0007V3-Fy for tls@lists.ietf.org; Sat, 13 Oct 2007 15:14:53 -0400 Received: from [192.168.1.3] (pool-72-76-39-171.nwrknj.fios.verizon.net [72.76.39.171]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9DJEidX080060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Oct 2007 12:14:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <470FEA1F.7030500@pobox.com> References: <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <470FEA1F.7030500@pobox.com> Date: Sat, 13 Oct 2007 15:14:20 -0400 To: Mike , tls@lists.ietf.org From: Paul Hoffman Subject: Re: [TLS] security levels for TLS Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 2:41 PM -0700 10/12/07, Mike wrote: >>Confusing and/or giving users false senses of security are >>definitely negative. > >Fully agreed. I don't see how this would be confusing or give >a false sense of security. OK, that is a point where you seem to disagree with most others posting on this thread. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Oct 14 11:18:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih5Bi-0000pn-Al; Sun, 14 Oct 2007 11:15:30 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ih5Bh-0000nk-Oh for tls-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:15:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih5Bh-0000nN-B3 for tls@ietf.org; Sun, 14 Oct 2007 11:15:29 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ih5Bc-0003Id-KP for tls@ietf.org; Sun, 14 Oct 2007 11:15:26 -0400 Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id l9EF36Y4005349; Sun, 14 Oct 2007 17:14:56 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v752.3) References: Message-Id: From: Yoav Nir Date: Sun, 14 Oct 2007 17:01:24 +0200 To: tls@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: Yaron Sheffer , Hannes Tschofenig Subject: [TLS] Fwd: I-D Action:draft-nir-tls-eap-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1456758089==" Errors-To: tls-bounces@lists.ietf.org --===============1456758089== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16--681480202; protocol="application/pkcs7-signature" --Apple-Mail-16--681480202 Content-Type: multipart/alternative; boundary=Apple-Mail-15--681480388 --Apple-Mail-15--681480388 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all. We've published the -02 iteration of the TEE draft. The aim is to leverage EAP-using infrastructure such as RADIUS and DIAMETER servers for the authentication of TLS sessions. Following comments expressed about version -01, we've added some text that explains why the EAP exchange needs to be integrated into the TLS handshake rather than be part of the application. Comments are welcome. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 14, 2007 4:00:02 PM IST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-tls-eap-02.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : TLS using EAP Authentication > Author(s) : Y. Nir, et al. > Filename : draft-nir-tls-eap-02.txt > Pages : 19 > Date : 2007-10-14 > > This document describes an extension to the TLS protocol to allow TLS > clients to authenticate with legacy credentials using the Extensible > Authentication Protocol (EAP). > > This work follows the example of IKEv2, where EAP has been added to > the IKEv2 protocol to allow clients to use different credentials such > as passwords, token cards, and shared secrets. > > When TLS is used with EAP, additional records are sent after the > ChangeCipherSpec protocol message and before the Finished message, > effectively creating an extended handshake before the application > layer data can be sent. Each EapMsg handshake record contains > exactly one EAP message. Using EAP for client authentication allows > TLS to be used with various AAA back-end servers, such as RADIUS or > Diameter. > > TLS with EAP may be used for securing a data connection such as HTTP > or POP3. We believe it has three main benefits: > o The ability of EAP to work with backend servers can remove that > > burden from the application layer. > o Moving the user authentication into the TLS handshake protects the > > presumably less secure application layer from attacks by > > unauthenticated parties. > o Using mutual authentication methods within EAP can help thwart > > certain classes of phishing attacks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-tls-eap-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-nir-tls-eap-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-nir-tls-eap-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-10-14095758.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-15--681480388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all.

We've published the -02 = iteration of the TEE draft. The aim is to leverage EAP-using = infrastructure such as RADIUS and DIAMETER servers for the = authentication of TLS sessions.

Following comments = expressed about version -01, we've added some text that explains why the = EAP exchange needs to be integrated into the TLS handshake rather than = be part of the application.

Comments are = welcome.


Begin forwarded message:

Date: October 14, 2007 4:00:02 PM = IST
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-nir-tls-eap-02.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =A0 =A0 =A0 =A0 =A0 : TLS using = EAP Authentication
Author(s) = =A0 =A0 =A0 : Y. Nir, et = al.
Filename=A0 =A0 =A0 =A0 : = draft-nir-tls-eap-02.txt
Pages = =A0 =A0 =A0 =A0 =A0 : = 19
Date=A0 =A0 =A0 =A0 =A0 =A0 : = 2007-10-14

This document describes an extension to the TLS = protocol to allow TLS
clients to authenticate = with legacy credentials using the Extensible
Authentication Protocol (EAP).

This = work follows the example of IKEv2, where EAP has been added to
the IKEv2 protocol to allow clients to use different = credentials such
as passwords, token cards, and = shared secrets.

When TLS is used with EAP, additional records are = sent after the
ChangeCipherSpec protocol = message and before the Finished message,
layer data can be sent.=A0 Each EapMsg handshake record = contains
exactly one EAP message.=A0 Using EAP for client = authentication allows
TLS to be used with various = AAA back-end servers, such as RADIUS or

TLS with EAP may be used for securing a data = connection such as HTTP
or POP3.=A0 We believe it has three main = benefits:
o=A0 The ability of EAP to work = with backend servers can remove that

burden from the application = layer.
o=A0 Moving the user = authentication into the TLS handshake protects the


o=A0 Using mutual authentication = methods within EAP can help thwart

certain classes of phishing = attacks.

A URL for this Internet-Draft is:

To = remove yourself from the I-D Announcement list, send a message = to
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then
"get = draft-nir-tls-eap-02.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-nir-tls-eap-02.txt".

NOTE: =A0 The mail server at ietf.org = can return the document in
= MIME-encoded form by using the "mpack" utility.=A0 To use this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: text/plain
Content-ID: = <2007-10-14095758.I-D\@ietf.org>

I-D-Announce mailing list
=

= --Apple-Mail-15--681480388-- --Apple-Mail-16--681480202 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAxNDE1 MDEyNFowIwYJKoZIhvcNAQkEMRYEFMZrt9TOtMRPdAb6bw5dLPvMymVPMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQCqAaTNZLyh xs9cmRbH1PBWwuhNsCQFTpX+CgEO+z5IR3FytZysEPKJkqras+1ui07VTSXOm4WNvdUJpIm7z1Sk 7wpNup/hch7vbHriFc3j1xySVVm6b6xkCsMQ2t3Qu4H6v6WQH/RrKCBxxh5H8h8uZB2k2Ira3Dwi 4niHXMz8yF2bgOJ6HNmny5+h2MpEMutIRe0FAPSCUJGaPhUrpvEMoap2DRtoT8ZmlHjMdlm5kBCf SxitU2uQgQ53sluAZZv07BpZPxd5mMW0+h4Rpo8TNa3IU8e4Cud/o7AX2RJOoP0uJUdsSsz3rAK4 zRif8BFiRnl/3KyKpR2quiZ8H3h3AAAAAAAA --Apple-Mail-16--681480202-- --===============1456758089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1456758089==-- From tls-bounces@lists.ietf.org Sun Oct 14 13:07:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih6sv-00034t-Tk; Sun, 14 Oct 2007 13:04:13 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ih6sv-00034o-3M for tls-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 13:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih6su-000306-Q2 for tls@ietf.org; Sun, 14 Oct 2007 13:04:12 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih6so-00083m-94 for tls@ietf.org; Sun, 14 Oct 2007 13:04:07 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9EH32OG009132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Oct 2007 19:03:17 +0200 From: Simon Josefsson To: Yoav Nir References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071014:tls@ietf.org::f4WI2dGTdENz8y+w:2Ivg X-Hashcash: 1:22:071014:yaronf@checkpoint.com::xyZ3bMIWBtA5Och1:5v3S X-Hashcash: 1:22:071014:ynir@checkpoint.com::wU+8me/zsvhD0X43:FkvL X-Hashcash: 1:22:071014:hannes.tschofenig@gmx.net::DTv0YA8AtfMGjiWH:BAz6 Date: Sun, 14 Oct 2007 19:02:57 +0200 In-Reply-To: (Yoav Nir's message of "Sun, 14 Oct 2007 17:01:24 +0200") Message-ID: <87lka5mxxa.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Hannes Tschofenig , tls@ietf.org, Yaron Sheffer Subject: [TLS] Re: Fwd: I-D Action:draft-nir-tls-eap-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir writes: > Hi all. > > We've published the -02 iteration of the TEE draft. The aim is to > leverage EAP-using infrastructure such as RADIUS and DIAMETER servers > for the authentication of TLS sessions. > > Following comments expressed about version -01, we've added some text > that explains why the EAP exchange needs to be integrated into the > TLS handshake rather than be part of the application. How does your proposal compares with the proposal to support GSS-API in the TLS handshake? It would be an interoperability failure if both EAP-in-TLS and GSSAPI-in-TLS were standardized and there aren't applicability statements for application protocols like HTTP, IMAP, SMTP. There may also be security failures, if an implementation would support both EAP-in-TLS and GSSAPI-in-TLS. This is because there doesn't seem to be any way for applications to negotiate the globally most secure mechanism. Consider if the application supports Kerberos via GSSAPI-in-TLS and a weak EAP mechanism via EAP-in-TLS. There doesn't seem to be any way for the application to detect this situation? It may end up negotiation the weak EAP mechanism even though Kerberos was supported. I think EAP may make slightly more sense than GSS-API because (with the exception of Kerberos) there are few widely deployed GSS-API mechanisms. In contrast there are many deployed EAP mechanisms. Instead of GSSAPI-in-TLS we could define a EAP-GSSAPI mechanism, and use it in EAP-in-TLS. It would be complex though. Thoughts? /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 16 08:08:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlAZ-000876-Iq; Tue, 16 Oct 2007 08:05:07 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IhlAW-00084b-Lp for tls-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 08:05:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlAV-00083t-Mx for tls@ietf.org; Tue, 16 Oct 2007 08:05:03 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhlAU-0000F8-Tp for tls@ietf.org; Tue, 16 Oct 2007 08:05:03 -0400 Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id l9GBp0ZS001211; Tue, 16 Oct 2007 14:05:00 +0200 (IST) In-Reply-To: <87lka5mxxa.fsf@mocca.josefsson.org> References: <87lka5mxxa.fsf@mocca.josefsson.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Yoav Nir Date: Tue, 16 Oct 2007 13:50:16 +0200 To: Simon Josefsson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Hannes Tschofenig , tls@ietf.org, Yaron Sheffer Subject: [TLS] Re: I-D Action:draft-nir-tls-eap-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1340370552==" Errors-To: tls-bounces@lists.ietf.org --===============1340370552== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22--520147746; protocol="application/pkcs7-signature" --Apple-Mail-22--520147746 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed comments inline... On Oct 14, 2007, at 7:02 PM, Simon Josefsson wrote: > Yoav Nir writes: > >> Hi all. >> >> We've published the -02 iteration of the TEE draft. The aim is to >> leverage EAP-using infrastructure such as RADIUS and DIAMETER servers >> for the authentication of TLS sessions. >> >> Following comments expressed about version -01, we've added some text >> that explains why the EAP exchange needs to be integrated into the >> TLS handshake rather than be part of the application. > > How does your proposal compares with the proposal to support GSS- > API in > the TLS handshake? [YN] They're both proposals for integrating other-than-certificate authentication into TLS. Both make use of external authentication servers. In some ways they are competing proposals, but in practice, GSS-API and EAP really map to Kerberos and RADIUS/DIAMETER. Both kinds of infrastructure exist, and should be available for applications. > > It would be an interoperability failure if both EAP-in-TLS and > GSSAPI-in-TLS were standardized and there aren't applicability > statements for application protocols like HTTP, IMAP, SMTP. > > There may also be security failures, if an implementation would > support > both EAP-in-TLS and GSSAPI-in-TLS. This is because there doesn't seem > to be any way for applications to negotiate the globally most secure > mechanism. Consider if the application supports Kerberos via > GSSAPI-in-TLS and a weak EAP mechanism via EAP-in-TLS. There doesn't > seem to be any way for the application to detect this situation? > It may > end up negotiation the weak EAP mechanism even though Kerberos was > supported. [YN] I'm not sure I buy this scenario as a protocol failure. I think the problem here is not some downgrade attack, but the fact that the application supports the weak EAP mechanism. If your infrastructure supports EAP-GTC for passwords, then you're going to be about as secure as the current "connect using TLS and type your password on a form" method of logging in. > > I think EAP may make slightly more sense than GSS-API because (with > the > exception of Kerberos) there are few widely deployed GSS-API > mechanisms. > In contrast there are many deployed EAP mechanisms. Instead of > GSSAPI-in-TLS we could define a EAP-GSSAPI mechanism, and use it in > EAP-in-TLS. It would be complex though. Thoughts? [YN] This can be done, but as far as I can tell, the EAP-GSSAPI effort was abandoned 5 years ago. The last version was http:// tools.ietf.org/html/draft-aboba-pppext-eapgss-12 . If it comes to the TLS WG choosing to take on either one document or another, I guess this effort would be resurrected so that both RADIUS/DIAMETER infrastructures and Kerberos can be accommodated. > > /Simon > --Apple-Mail-22--520147746 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAxNjEx NTAxN1owIwYJKoZIhvcNAQkEMRYEFIqYVJ3/Qs3HnF4xqMEHkhJrJuRKMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQAx76BZA+7e yEBui7U+B0i0vWkn2xm2GUVPKAYvYPOX+lcmFEOn6W/BzFv0BDgVqqV3MIzWs857bm6APCjb1SyQ d4sHyAngcMtBMhS0O1vPsbINooBFidxQdU0q/HD0nEzGYpnorMJDGIUPtZ1wtPKe/9ZwH+g2BU0M RlLm+MqAJSNM8QRLSv56W7+oZl0sdAs8UfZ/YeTBZ3p96cyO8ak7F12MyOsdvCkY9ASI0kAHUALj 63j3ryqifbD6Q9sYaYljSHqvG5mR1WKlNXbvZnbewttsR++lRIy72wEBCn3g0zh5isZnhy/Kjbtf jsqFG35BgJ+3NykwaFOuRx1ZaKvXAAAAAAAA --Apple-Mail-22--520147746-- --===============1340370552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1340370552==-- From tls-bounces@lists.ietf.org Tue Oct 16 11:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhokZ-0001M4-Gu; Tue, 16 Oct 2007 11:54:31 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IhokX-0001Io-67 for tls-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 11:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhokW-0001Hr-HG for tls@ietf.org; Tue, 16 Oct 2007 11:54:28 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhokN-0001EU-5a for tls@ietf.org; Tue, 16 Oct 2007 11:54:28 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 883D933C21 for ; Tue, 16 Oct 2007 08:49:47 -0700 (PDT) Date: Tue, 16 Oct 2007 08:49:44 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071016154947.883D933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [TLS] DH group validation X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org One of the remaining TODOs in TLS 1.2 is what (if anything) the client should do to validate the server's offered DH group. I ran this by Bodo Moeller, who writes: On Thu, Oct 11, 2007 at 12:20:20PM -0700, Eric Rescorla wrote: > The current TLS 1.2 draft has: > > Because TLS allows the server to provide arbitrary DH groups, the > client SHOULD verify the correctness of the DH group. [TODO: provide > a reference to some document describing how] and that it is of > suitable size as defined by local policy. The client SHOULD also > verify that the DH public exponent appears to be of adequate size. > The server MAY choose to assist the client by providing a known > group, such as those defined in [IKEALG] or [MODP]. These can be > verified by simple comparison. > > Any chance you would be willing to provide some text for this TODO? > Or a pointer or something? I suppose I could write something on recommendations for DH groups (although not right now -- I will be traveling without a computer later this week and next week), but I don't really see the point of client verification of server-chosen DH groups, and don't agree that this should be a "SHOULD". In the TLS 1.2 standard ciphersuites, a signature authenticates that the server really has chosen this particular group. (Or, in anonymous ciphersuites, even *with* group verification you can't really trust the DH value if you suspect there might be an active adversary.) You can't verify *all* security-relevant aspects of server behavior, so why spend time verifying this particular one? If the server implementation sucks, it could use a perfectly nice DH group in a perfectly broken way -- such as by using a low-entropy secret exponent. I don't see that verifying the DH group doesn't really add significant value: it does not counter any threats by actual adversaries. Looking at the (purported) group size is reasonable because it is cheap to do, so that the client can detect if the server at least pretends to use a certain security level. The client could do some more complex verification to decide if it would appear secure to reuse its own secret exponent multiple times, but I don't think this is worth the effort: we have session reuse capabilities, anyway; so clients should always use fresh DH exponents if a full handshake happens, and try to reuse a session if they want to reuse older secret values. Bodo I tend to agree with this, and I suggest that we simply suggest that the client SHOULD check the group size. Comments in the other direction? I'd like to note that the reason this section is not filled in is because I don't have any text I'm comfortable with on how to check a DH group. Accordingly, any comments suggesting that we should have validation would be most convincing if they came with a contribution of text describing what you want done. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 16 13:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihpnb-0008RR-Pv; Tue, 16 Oct 2007 13:01:43 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ihpna-0008Pz-AL for tls-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 13:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpnZ-0008PD-Iq for tls@ietf.org; Tue, 16 Oct 2007 13:01:41 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhpnT-00041H-8g for tls@ietf.org; Tue, 16 Oct 2007 13:01:41 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1341495rvb for ; Tue, 16 Oct 2007 10:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=zw7PfgLTw1QhOFXfkUdTWMYMDxvzFmmfeRVhZ5AZwo4=; b=B4EsFQms43iRxzHumJGeTcAShYDIqQeYLxakq/YM9kesTR+sVXhJEKkvrZVrG6gfKbIYVHfGnWawFz+Fq9LtEhbWjScWqalFmruZMRgbHQNskCu4cDR9eL6gI+wur5xaJmzp2DC9h2bhLaI8oflUYqCv7yM39FXfYPnP4VxsFz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=j4rwaaLdblTrRlYPQ4UXjP+7IxAnW+cDdTSvu7e5W6BPaC0YD0qaAmJIqvAABWQcSkSKAjwpo2AO8Bbk73jcVW9favYQ2q/Q0HxR8whF8/fXXlDeRarVzpAnmS9vHuUpJbp9ggdVOZxOW5NqUsV/athJvj74Gfbaplb0yiXcnSc= Received: by 10.141.128.19 with SMTP id f19mr3635983rvn.1192554075604; Tue, 16 Oct 2007 10:01:15 -0700 (PDT) Received: by 10.140.204.17 with HTTP; Tue, 16 Oct 2007 10:01:15 -0700 (PDT) Message-ID: <8637da890710161001g3429f114q4a80c0cd6cb42fde@mail.gmail.com> Date: Tue, 16 Oct 2007 10:01:15 -0700 From: "Wan-Teh Chang" To: "Joseph Salowey (jsalowey)" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: tls@ietf.org Subject: [TLS] Comments on draft-salowey-tls-rfc4507bis-01.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I am helping Nagendra Modadugu implement the TLS SessionTicket extension in NSS. I have some comments and questions on the current Internet-Draft draft-salowey-tls-rfc4507bis-01.txt. I. Page 5 and page 6 jump back and forth between abbreviated handshakes (session resumption) and full handshakes, so it was hard to follow the description at first. I suggest a better order of presentation below. Page 5, third paragraph: "If the server cannot or does not want to honor the ticket, then it can initiate a full handshake with the client." I suggest adding "in one of two ways" at the end of this sentence, to announce to the readers that the next two paragraphs describe the two ways of performing a full handshake after a server rejects a ticket. Page 6, first paragraph: The first sentence of this paragraph says: "It is also permissible to have an exchange similar to Figure 3 using the abbreviated handshake defined in Figure 2 of RFC 4346 ..." Should "Figure 3" be changed to "Figure 2"? This paragraph is in the wrong place. It describes an abbreviated handshake. It should be moved right after Figure 2. It would be nice to add a message flow for this paragraph. Page 6, second paragraph: Change "Client Hello" to "ClientHello". Note: If you reorder the paragraphs as I suggested, you need to rework the text to make the transition smooth. Please let me know if you don't understand my suggestion. II. Page 8, first paragraph: ".... If the ticket is accepted by the server but the handshake fails, the client SHOULD delete the ticket." I assume the client should also delete the cached master secret? III. Page 8, last paragraph: I assume the ticket_lifetime_hint field contains a relative time (time interval) rather than an absolute time (time instant), right? (Nagendra also asked about this in his comments.) IV. Issues with the recommended ticket construction. There are two issues: the 128-bit security level, and the need to have the master secret in plaintext form. Page 10, second paragraph: "The server uses two different keys: one 128-bit key for AES [AES] in CBC mode [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634]." Can we use a 128-bit key for HMAC-SHA-256? Even FIPS 198 requires only a 128-bit key for HMAC-SHA-256 (see FIPS 198, Sec. 3, p. 3). A 128-bit AES key provides a security level of 128 bits, so it could be weaker than the AES-256 cipher suites, especially those used with NSA Suite B 384-bit elliptic curves, which are designed to operate at the 192-bit security level (see Sec. 3 of draft-rescorla-tls-suiteb-01.txt). It would be nice to point out that the security strength of the 128-bit AES key may not be sufficient for all cipher suites, and mention this issue again in Section 5.5 "Ticket Protection Key Management". Page 10, last paragraph: Should the length of the encrypted_state field (2 octets) be encoded in network byte order? Page 11, definition of the StatePlaintext structure: The timestamp field is a uint32. Should a 64-bit timestamp be used? Contrary to the ticket_lifetime_hint field of the NewSessionTicket, this timestamp is an absolute time (time instant), not a relative time (time interval), so an unsigned 32-bit value will overflow in 136 years from the chosen epoch. It is implied that the master_secret field is in plaintext form. Some crypto modules only allow the master secret to be extracted in wrapped (encrypted) form. If an SSL implementation uses such a crypto module, it can't use the recommended ticket construction as is. A ticket construction using AES-GCM would also work, right? V. Appendix A. Detecting RFC 4507 implementations Page 17, last paragraph: I hope the authors will take a stronger stance on discouraging RFC 4507 implementations by deleting this paragraph. But if you'd like to keep it, it is incomplete, as described below. In RFC 4507, the second paragraph of Sec. 3.2 (p. 6) says: If the client does not have a ticket and is prepared to receive one in the NewSessionTicket handshake message, then it MUST include a zero-length ticket in the SessionTicket extension. So an RFC 4507 client would encode the extension as follows: 00 23 Ticket Extension type 35 00 02 Length of extension contents 00 00 Length of ticket whereas a client conforming to this document would do: 00 23 Ticket Extension type 35 00 00 Length of extension contents (ticket) RFC 4507 says in the next paragraph: The server uses an zero length SessionTicket extension to indicate to the client that it will send a new session ticket using the NewSessionTicket handshake message described in Section 3.3. It's not clear how an RFC 4507 server encodes "an zero length SessionTicket extension". It is reasonable to assume that an RFC 4507 client would expect it to be 00 23 00 02 00 00 because that's what the client sends. Therefore, a complete discussion on implementing a server that detects an RFC 4507 implementation should start by describing how to detect "a zero-length ticket in the SessionTicket extension" from an RFC 4507 client. If detected, the server probably should respond with 00 23 00 02 00 00 rather than 00 23 00 00 (unless the RFC 4507 client blindly ignores the extension_data field of the server's SessionTicket extension). Wan-Teh Chang NSS developer _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 16 15:12:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihroe-0005kr-Ff; Tue, 16 Oct 2007 15:10:56 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ihroc-0005gP-PU for tls-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 15:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihrob-0005fL-UG for tls@lists.ietf.org; Tue, 16 Oct 2007 15:10:53 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhroS-0000yi-Ke for tls@lists.ietf.org; Tue, 16 Oct 2007 15:10:53 -0400 Received: by ug-out-1314.google.com with SMTP id z38so141448ugc for ; Tue, 16 Oct 2007 12:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=hnd1qZzTUhgxOffxgSFir0GCXXK2gVHGlxk96viAg2c=; b=En+dK8jxNKD4r8oPZdmY0BCBSk+3W/T2DnsGucM2u4GJ9GRIYJFmcE2uzWcuY27DnSyNgq4RcqC9xJ2+Cimsh3p+E4mu/x+c6Sq/sW+pFo/tW7OaO1Xn819gLLJ3JQEZ8af3Wxq5IJ2PaxOvK5kPdFDqlkPzu1riYPAFFI0Js5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=tQH9vqft16IUM5aqJVVi5EtHmMEX1cGnczhKNzEcrxDjbESfBBmTjyK5W9lvx7X6D0VrevLOvPMfRFmgjcoJt0t9MNhMDflEZkYUwuZm63H0xSGXDomHpM2pLYffKD2TUylRt1rzXuE0W0s+Fr840JmRybv9hdOehqL9j0oKuVs= Received: by 10.67.116.4 with SMTP id t4mr9435173ugm.1192561816703; Tue, 16 Oct 2007 12:10:16 -0700 (PDT) Received: from crystal.lan ( [77.49.219.111]) by mx.google.com with ESMTPS id w5sm11703132mue.2007.10.16.12.10.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2007 12:10:15 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] DH group validation Date: Tue, 16 Oct 2007 22:10:11 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071016154947.883D933C21@delta.rtfm.com> In-Reply-To: <20071016154947.883D933C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710162210.12460.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tuesday 16 October 2007, Eric Rescorla wrote: > In the TLS 1.2 standard ciphersuites, a signature authenticates that > the server really has chosen this particular group. (Or, in anonymous > ciphersuites, even *with* group verification you can't really trust > the DH value if you suspect there might be an active adversary.) You > can't verify *all* security-relevant aspects of server behavior, so > why spend time verifying this particular one? If the server > implementation sucks, it could use a perfectly nice DH group in a > perfectly broken way -- such as by using a low-entropy secret > exponent. I don't see that verifying the DH group doesn't really add > significant value: it does not counter any threats by actual > adversaries. I agree with the above. He can post the transaction in plaintext. I don't see much to gain by further checking the group. > Looking at the (purported) group size is reasonable because it is > cheap to do, so that the client can detect if the server at least > pretends to use a certain security level. But of course then you need to define what a security level is and how it applies to DH key exchange. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 16 15:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhsEm-0005X1-RJ; Tue, 16 Oct 2007 15:37:56 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IhsEl-0005TX-0v for tls-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 15:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhsEk-0005LH-0c for tls@lists.ietf.org; Tue, 16 Oct 2007 15:37:54 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhsEa-0001vW-RA for tls@lists.ietf.org; Tue, 16 Oct 2007 15:37:50 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5712C33C21; Tue, 16 Oct 2007 12:33:02 -0700 (PDT) Date: Tue, 16 Oct 2007 12:33:02 -0700 From: Eric Rescorla To: Nikos Mavrogiannopoulos Subject: Re: [TLS] DH group validation In-Reply-To: <200710162210.12460.nmav@gnutls.org> References: <20071016154947.883D933C21@delta.rtfm.com> <200710162210.12460.nmav@gnutls.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071016193302.5712C33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Tue, 16 Oct 2007 22:10:11 +0300, Nikos Mavrogiannopoulos wrote: > On Tuesday 16 October 2007, Eric Rescorla wrote: > > Looking at the (purported) group size is reasonable because it is > > cheap to do, so that the client can detect if the server at least > > pretends to use a certain security level. > > But of course then you need to define what a security level is and how it > applies to DH key exchange. I don't see that this follows. The current text simply leaves the decision to the client, which seems to do the job: The client SHOULD also verify that the DH public exponent appears to be of adequate size. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 17 02:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2Mu-0003lQ-8G; Wed, 17 Oct 2007 02:27:00 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ii2Mr-0003dQ-Vx for tls-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 02:26:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2Mq-0003TF-Ne for tls@ietf.org; Wed, 17 Oct 2007 02:26:56 -0400 Received: from curly.its.auckland.ac.nz ([130.216.12.33] helo=mailhost.auckland.ac.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii2Mm-0008E7-8w for tls@ietf.org; Wed, 17 Oct 2007 02:26:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5B6AB9C405; Wed, 17 Oct 2007 19:26:48 +1300 (NZDT) 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 8pFMxpObDmcw; Wed, 17 Oct 2007 19:26:48 +1300 (NZDT) 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 208649C3E0; Wed, 17 Oct 2007 19:26:47 +1300 (NZDT) 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 07354E080B5; Wed, 17 Oct 2007 19:26:47 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Ii2Mg-00068U-U2; Wed, 17 Oct 2007 19:26:46 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com, tls@ietf.org Subject: Re: [TLS] DH group validation In-Reply-To: <20071016154947.883D933C21@delta.rtfm.com> Message-Id: Date: Wed, 17 Oct 2007 19:26:46 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >One of the remaining TODOs in TLS 1.2 is what (if anything) the client should >do to validate the server's offered DH group. Isn't this trivially solveable by switching from PKCS #3 to DSA/X9.42/ and referring to any standard that tells people how to apply this? Presumably all it'd take is the addition of fields for the new DLP key parameters, and a reference to the standard of choice for how to generate and verify the keys. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 17 02:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2iY-0003VW-I2; Wed, 17 Oct 2007 02:49:22 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ii2iW-0003VR-NG for tls-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 02:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2iJ-0003Lg-45 for tls@ietf.org; Wed, 17 Oct 2007 02:49:07 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii2iD-0008S9-6t for tls@ietf.org; Wed, 17 Oct 2007 02:49:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9H6mfSe015597 for ; Wed, 17 Oct 2007 09:48:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 09:48:55 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 09:48:55 +0300 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 Subject: RE: [TLS] DH group validation Date: Wed, 17 Oct 2007 09:48:58 +0300 Message-ID: In-Reply-To: <20071016154947.883D933C21@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DH group validation Thread-Index: AcgQDeESop7mbqnZRoSKzQ4VcZBVBgAe9VNg References: <20071016154947.883D933C21@delta.rtfm.com> From: To: X-OriginalArrivalTime: 17 Oct 2007 06:48:55.0790 (UTC) FILETIME=[C98A30E0:01C81089] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > I don't see that verifying the DH group doesn't really add > significant value: it does not counter any threats by actual > adversaries. Not all threats all caused by malicious adversaries. IMHO the=20 purpose of doing some kind of DH group validation is to mitigate=20 risk from a particular kind of implementation mistake. This=20 particular implementation mistake has been seen in real world,=20 so it does have some relevance (although there are, of course,=20 other implementation mistakes that can't be found by this=20 particular check). However, it seems that as long as we don't require any particular verifiable prime generation algorithm (such as X9.42), or use only "known" groups (like IKE does), the only validation we can easily=20 do (without non-trivial computation) is checking the size of "p". We could rephrase the text something like this: The security level offered by TLS also depends on the DH group. The client SHOULD verify that the DH modulus appears to be of adequate size (some implementations of earlier versions of TLS are known to generate very small DH moduli, offering little security).=20 Other aspects of DH group correctness (such as the subgroup size) are more difficult to verify. The server MAY choose to assist the=20 client by providing a group with known level security, such as=20 those defined in [IKEALG] or [MODP]. These can be verified by=20 simple comparison. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 17 03:37:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii3Rg-0008Ua-Pq; Wed, 17 Oct 2007 03:36:00 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Ii3Rd-0008Ma-SJ for tls-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 03:35:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii3Rc-0008G5-UM for tls@ietf.org; Wed, 17 Oct 2007 03:35:56 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii3Ra-0001eW-7Z for tls@ietf.org; Wed, 17 Oct 2007 03:35:54 -0400 Received: from tau.invalid (p508EAF45.dip0.t-ipconnect.de [80.142.175.69]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1Ii3RX0zTw-0003yY; Wed, 17 Oct 2007 09:35:53 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 0994B1C397; Wed, 17 Oct 2007 09:35:49 +0200 (CEST) Date: Wed, 17 Oct 2007 09:35:49 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] DH group validation Message-ID: <20071017073549.GA26553@tau.invalid> References: <20071016154947.883D933C21@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18GN5t5GtoxhgR2ws2nzh/jDdpP7iR9RBT3m25 GoO9U5pHz8wq1/KowzJESbQicdHrWfYDbM5+R63YAAWMge4yCs uVeLTIqmY2vRP+lvyKNTVEuMUF1e3pseMmpMfnzcB53tFRsNGq D/Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, Oct 17, 2007 at 09:48:58AM +0300, Pasi.Eronen@nokia.com wrote: > Bodo Moeller wrote: >> I don't see that verifying the DH group doesn't really add Oops, unintended double negation. But apparently everyone got what I meant: "I don't see that verifying the DH group really adds significant value." >> significant value: it does not counter any threats by actual >> adversaries. > Not all threats all caused by malicious adversaries. IMHO the > purpose of doing some kind of DH group validation is to mitigate > risk from a particular kind of implementation mistake. This > particular implementation mistake has been seen in real world, > so it does have some relevance (although there are, of course, > other implementation mistakes that can't be found by this > particular check). Yes, this is my point (as stated earlier in the paragraph part of which you quoted here). > However, it seems that as long as we don't require any particular > verifiable prime generation algorithm (such as X9.42), or use only > "known" groups (like IKE does), the only validation we can easily > do (without non-trivial computation) is checking the size of "p". I am hoping that we can agree to (optionally?) include "q" into DH parameters for the next version of the standard, allowing for more meaningful quick "validation" on the one hand, and for efficiency improvements on the other hand. (Efficiency improvements since if you have a 2048-bit p with a 224-bit q, the client has much less work to do if it knows it only has to choose an exponent in the range (2, q-1) and not a 2048-bit exponent.) In this case, the client would look at the size of q to see if it looks reasonably large, and presumably also would check that q is at least one bit longer than q. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 20 15:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjK1R-0006NU-93; Sat, 20 Oct 2007 15:30:09 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IjK1P-0006ML-UC for tls-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 15:30:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjK1O-0006Kn-Rz for tls@ietf.org; Sat, 20 Oct 2007 15:30:06 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjK1O-0005GD-Fn for tls@ietf.org; Sat, 20 Oct 2007 15:30:06 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3BE1C33C28; Sat, 20 Oct 2007 12:25:46 -0700 (PDT) Date: Sat, 20 Oct 2007 12:25:45 -0700 From: Eric Rescorla To: Bodo Moeller Subject: Re: [TLS] DH group validation In-Reply-To: <20071017073549.GA26553@tau.invalid> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071020192547.3BE1C33C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Wed, 17 Oct 2007 09:35:49 +0200, Bodo Moeller wrote: > I am hoping that we can agree to (optionally?) include "q" into DH > parameters for the next version of the standard, allowing for more > meaningful quick "validation" on the one hand, and for efficiency > improvements on the other hand. (Efficiency improvements since if you > have a 2048-bit p with a 224-bit q, the client has much less work to > do if it knows it only has to choose an exponent in the range (2, q-1) > and not a 2048-bit exponent.) In this case, the client would look > at the size of q to see if it looks reasonably large, and presumably > also would check that q is at least one bit longer than q. Bodo: I want to make sure I understand this: 1. Is knowing the factorization important in this case? I'm not really a DH expert, but this paper http://eprint.iacr.org/2004/099 seems to argue that if you're digesting ZZ, you don't need to know the factorization of p-1. It looks like this may only be true if the generator is random? Maybe Hugo can weigh in here... 2. This is an optimization only for the client, right? The server at least potentially knows the factorization of p-1, so sending this information doesn't make the server any faster. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 23 09:08:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJRa-0001Jk-Sf; Tue, 23 Oct 2007 09:05:14 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IkJRX-0001Cs-Pc for tls-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 09:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJRW-00019x-CB for tls@lists.ietf.org; Tue, 23 Oct 2007 09:05:10 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkJRQ-0006gg-7K for tls@lists.ietf.org; Tue, 23 Oct 2007 09:05:10 -0400 Received: (qmail 16486 invoked by uid 0); 23 Oct 2007 13:04:46 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (193.0.9.179) by woodstock.binhost.com with SMTP; 23 Oct 2007 13:04:46 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Oct 2007 09:02:34 -0400 To: tls@lists.ietf.org From: Russ Housley Subject: Re: [TLS] DH group validation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Message-Id: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric: > In the TLS 1.2 standard ciphersuites, a signature authenticates that > the server really has chosen this particular group. (Or, in anonymous > ciphersuites, even *with* group verification you can't really trust > the DH value if you suspect there might be an active adversary.) You > can't verify *all* security-relevant aspects of server behavior, so > why spend time verifying this particular one? If the server > implementation sucks, it could use a perfectly nice DH group in a > perfectly broken way -- such as by using a low-entropy secret > exponent. I don't see that verifying the DH group doesn't really add > significant value: it does not counter any threats by actual > adversaries. Makes sense to me. > Looking at the (purported) group size is reasonable because it is > cheap to do, so that the client can detect if the server at least > pretends to use a certain security level. The check is simple and straightforward, but how do you know how big it ought to be? Is this local configuration? Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From o05689ok@eyou.com Wed Oct 24 14:37:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikl6X-0001MS-DJ for tls-archive@lists.ietf.org; Wed, 24 Oct 2007 14:37:21 -0400 Received: from [211.211.30.193] (helo=SPK63.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikl6V-0000wr-T0 for tls-archive@lists.ietf.org; Wed, 24 Oct 2007 14:37:21 -0400 Received: by SPK63.localdomain (Postfix, from userid 48) id DF1F0528F3; Thu, 25 Oct 2007 03:20:52 +0900 (KST) To: tls-archive@lists.ietf.org Subject: =?ISO-2022-JP?B?GyRCIiUiJyIlGyhCMBskQjFfJEdMNT0kQDVGMDJoJCw4K0p8QmobKEIh?= =?ISO-2022-JP?B?IRskQkA4Q2Y9UCQ3JSglcyU4JScla0JnPTg5ZyIlIiciJRsoQg==?= From: Message-ID: <20071025032052.49742@eyou.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2007 03:20:52 +0900 (KST) X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $B"%"'"%"%"'"%"%"'"%"%"'"%"%"'"%"%"'"%"%"'"%"%"'"%"'(B $B"%(B0$B1_$GA4$F$N@8Cf=P$7%`!<%S!<$,$4Mw$K$J$l$^$9$h(B!$B"'(B $B"%"'"%"%"'"%"%"'"%"%"'"%"%"'"%"%"'"%"%"'(B From tls-bounces@lists.ietf.org Mon Oct 29 11:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWKp-0000WX-Dv; Mon, 29 Oct 2007 11:15:23 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1ImWKn-0000WN-PS for tls-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 11:15:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWKn-0000PP-EU for tls@ietf.org; Mon, 29 Oct 2007 11:15:21 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImWKk-0004iT-N2 for tls@ietf.org; Mon, 29 Oct 2007 11:15:19 -0400 Received: from tau.invalid ([134.147.40.246]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1ImWKS2F8u-0003kZ; Mon, 29 Oct 2007 16:15:01 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 5B7AD1B555; Mon, 29 Oct 2007 16:14:58 +0100 (CET) Date: Mon, 29 Oct 2007 16:14:58 +0100 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] DH group validation Message-ID: <20071029151458.GB10330@tau.invalid> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071020192547.3BE1C33C28@delta.rtfm.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/9rSjIQzmvcSa8ViGSs54ro2osUSJAd7HU8cZ rLhkuHwHHcBJHwdBr1VU7BqI6823vK4WV/sQm4SnnkQuu6A4f5 sLc24H2IN7qJzNgEZ1bcvnsoPFZCyWX/Be7XOAKdn/OGi7sn84 4zg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sat, Oct 20, 2007 at 12:25:45PM -0700, Eric Rescorla wrote: >> I am hoping that we can agree to (optionally?) include "q" into DH >> parameters for the next version of the standard, allowing for more >> meaningful quick "validation" on the one hand, and for efficiency >> improvements on the other hand. (Efficiency improvements since if you >> have a 2048-bit p with a 224-bit q, the client has much less work to >> do if it knows it only has to choose an exponent in the range (2, q-1) >> and not a 2048-bit exponent.) In this case, the client would look >> at the size of q to see if it looks reasonably large, and presumably >> also would check that q is at least one bit longer than q. > I want to make sure I understand this: > > 1. Is knowing the factorization important in this case? I'm not > really a DH expert, but this paper http://eprint.iacr.org/2004/099 > seems to argue that if you're digesting ZZ, you don't need to > know the factorization of p-1. It looks like this may only be > true if the generator is random? Maybe Hugo can weigh in > here... When above I say "q", I actually mean that q would be a prime, and that the given DH generator would be the generator of an order-q group. This is something that the specification would have to require. We could make the specification more complex and allow other configurations, but this looks pretty pointless to me: Instead, for non-prime group order (or if you don't know the order), I figure you'd simply omit q in the handshake message. Groups of non-prime order can work too for DH. I won't rehash (no pun intended) the results of the Hashed Diffie-Hellman paper that you are citing, but merely point out that it does *not* state that DH exponents can be as short when *not* using a prime-order generator as they can be when using a prime-order generator! In fact, if the group is not of prime order, this usually means that exponents do have to be longer. If you don't even know the group order, you'll have to use longer exponents just in case. > 2. This is an optimization only for the client, right? The server at > least potentially knows the factorization of p-1, so sending > this information doesn't make the server any faster. Certainly! This is about information that the server sends to the client, since in TLS any DH parameters are always provided by the server. If the server can send the information, then the server also knows the information; and it can use it without having to know whether the client is making use of it too: The server simply will pick its private DH exponent from the positive integers below q if it knows that the DH generator has order q, or even from a subset of shorter integers as determined by the required security level (which can be safely done assuming that, as required above, q is prime). Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 29 12:15:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXFu-0005pV-QP; Mon, 29 Oct 2007 12:14:22 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1ImXFt-0005pK-B6 for tls-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 12:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXFt-0005oC-07 for tls@ietf.org; Mon, 29 Oct 2007 12:14:21 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImXFl-0007Uh-PM for tls@ietf.org; Mon, 29 Oct 2007 12:14:15 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 24C5233C21; Mon, 29 Oct 2007 09:09:22 -0700 (PDT) Date: Mon, 29 Oct 2007 09:09:21 -0700 From: Eric Rescorla To: Bodo Moeller Subject: Re: [TLS] DH group validation In-Reply-To: <20071029151458.GB10330@tau.invalid> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071029160923.24C5233C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Mon, 29 Oct 2007 16:14:58 +0100, Bodo Moeller wrote: > > 2. This is an optimization only for the client, right? The server at > > least potentially knows the factorization of p-1, so sending > > this information doesn't make the server any faster. > > Certainly! This is about information that the server sends to the > client, since in TLS any DH parameters are always provided by the > server. If the server can send the information, then the server also > knows the information; and it can use it without having to know > whether the client is making use of it too: The server simply will > pick its private DH exponent from the positive integers below q if it > knows that the DH generator has order q, or even from a subset of > shorter integers as determined by the required security level (which > can be safely done assuming that, as required above, q is prime). OK, so this seems like a minor optimization but it does require a change to TLS, which, as I've commented before, my instinct is to avoid. My general intuition is that client public key performance isn't an enormous concern, since it's generally a latency issue as opposed to a throughput issue, so I'm mildly negative on this change, just on the theory of changing as little as possible. Right now my sense is that you and Peter Gutmann would like to see this change made and I would rather not. That's a pretty small set of opinions to decide from. Pasi may eventually need to run a straw poll, but first can I ask if there are other WG members who want to weigh in with their feelings on this? The general feeling of the WG may turn out to be clear... Folks? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 29 12:53:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXox-00053m-DI; Mon, 29 Oct 2007 12:50:35 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1ImXow-0004xi-3t for tls-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 12:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImXov-0004vT-PI for tls@lists.ietf.org; Mon, 29 Oct 2007 12:50:33 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImXoo-0001ER-Ie for tls@lists.ietf.org; Mon, 29 Oct 2007 12:50:33 -0400 Received: from tau.invalid (p508EB4E5.dip0.t-ipconnect.de [80.142.180.229]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1ImXog0y5k-00051d; Mon, 29 Oct 2007 17:50:19 +0100 Received: by tau.invalid (Postfix, from userid 1000) id C60471B581; Mon, 29 Oct 2007 17:50:16 +0100 (CET) Date: Mon, 29 Oct 2007 17:50:16 +0100 From: Bodo Moeller To: Russ Housley Subject: Re: [TLS] DH group validation Message-ID: <20071029165016.GA21104@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+jbFUSC2nIxah3Qc3uO39+90Z6GNVylrR1N0p BV+NXHDm4FeSGNMHyVbQpbpK71gqV280iMlmMUN+IXXKnarUd1 IHLr/MUYjj8bKl4z/M4HAsdVP42moKhCch4JJAXk6Map+QdJkW u3Q== X-Spam-Score: -0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, Oct 23, 2007 at 09:02:34AM -0400, Russ Housley wrote: >> In the TLS 1.2 standard ciphersuites, a signature authenticates that >> the server really has chosen this particular group. (Or, in anonymous >> ciphersuites, even *with* group verification you can't really trust >> the DH value if you suspect there might be an active adversary.) You >> can't verify *all* security-relevant aspects of server behavior, so >> why spend time verifying this particular one? If the server >> implementation sucks, it could use a perfectly nice DH group in a >> perfectly broken way -- such as by using a low-entropy secret >> exponent. I don't see that verifying the DH group doesn't really add >> significant value: it does not counter any threats by actual >> adversaries. > Makes sense to me. >> Looking at the (purported) group size is reasonable because it is >> cheap to do, so that the client can detect if the server at least >> pretends to use a certain security level. > The check is simple and straightforward, but how do you know how big > it ought to be? Is this local configuration? Yes; like insisting on certain symmetric key sizes. (If you insist on having at least 100 bits of symmetric encryption security, then you need a group order of at least 200 bits.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 29 17:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcY0-00021A-CE; Mon, 29 Oct 2007 17:53:24 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1ImcXy-0001zF-PX for tls-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 17:53:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcXy-0001yr-FC for tls@ietf.org; Mon, 29 Oct 2007 17:53:22 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcXy-00028q-3V for tls@ietf.org; Mon, 29 Oct 2007 17:53:22 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id CD3DC33C3D for ; Mon, 29 Oct 2007 14:48:13 -0700 (PDT) Date: Mon, 29 Oct 2007 14:48:13 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071029214813.CD3DC33C3D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [TLS] Updated TLS ID X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org An updated TLS ID can be found at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt The changes list is: - Redid the hash function advertisements for CertificateRequest and the client-side extension. They are now pairs of hash/signature and the semantics are clearly defined for all uses of signatures (hopefully). [Issue 41] - Clarified the DH group checking per list discussion [Issue 35] - Added a note about DSS vs. DSA [Issue 58] - Editorial issues [Issue 59] - Cleaned up certificate text in 7.4.2 and 7.4.6 [Issue 57] The major change is the first one: I completely overhauled the signature/hash advertisements as a result of the mailing list discussion. The only open issue I am still aware of is whether we should have "q" in the DH group info in the ServerKeyExchange. I'm hoping to get that nailed down this week, then do a final copy-edit and have a new draft out and ready for WGLC mid Nov. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 30 04:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm3h-0005H0-Q9; Tue, 30 Oct 2007 04:02:45 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Imm3h-0005Gj-19 for tls-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:02:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm3g-0005Fj-Js for tls@ietf.org; Tue, 30 Oct 2007 04:02:44 -0400 Received: from moutng.kundenserver.de ([212.227.126.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imm3b-0000vG-V4 for tls@ietf.org; Tue, 30 Oct 2007 04:02:40 -0400 Received: from tau.invalid (p508EB1E2.dip0.t-ipconnect.de [80.142.177.226]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Imm3W1V3J-00058i; Tue, 30 Oct 2007 09:02:35 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 2DA8B1EBAB; Tue, 30 Oct 2007 09:02:31 +0100 (CET) Date: Tue, 30 Oct 2007 09:02:31 +0100 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] DH group validation Message-ID: <20071030080231.GA26212@tau.invalid> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029160923.24C5233C21@delta.rtfm.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18P8DesKYFc/m6kFkF0HMV3JoW/pJfOW9lxJqP swV6eQj+yWZDw1unlaPrFMzm8ylr4SPP3B1dIYX582UcS7aEHV +3K0aHWwae2R8fhJT8TG3/TT1wh5Wv9QyEr3m+T7yMshEHJmuo BAw== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Mon, Oct 29, 2007 at 09:09:21AM -0700, Eric Rescorla wrote: >>> 2. This is an optimization only for the client, right? The server at >>> least potentially knows the factorization of p-1, so sending >>> this information doesn't make the server any faster. >> Certainly! This is about information that the server sends to the >> client, since in TLS any DH parameters are always provided by the >> server. If the server can send the information, then the server also >> knows the information; and it can use it without having to know >> whether the client is making use of it too: The server simply will >> pick its private DH exponent from the positive integers below q if it >> knows that the DH generator has order q, or even from a subset of >> shorter integers as determined by the required security level (which >> can be safely done assuming that, as required above, q is prime). > OK, so this seems like a minor optimization but it does require a > change to TLS, which, as I've commented before, my instinct is > to avoid. My general intuition is that client public key performance > isn't an enormous concern, This depends very much on the setting. Clients such as cellphones can be quite slow, and this is about a factor of five and more (1024/160 = 6.4) for the time the client has to spend on handshake calculations to achieve forward secrecy. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 30 20:26:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1N7-0006mm-Vr; Tue, 30 Oct 2007 20:23:49 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1In1N6-0006mR-HD for tls-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 20:23:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In1N6-0006it-74 for tls@ietf.org; Tue, 30 Oct 2007 20:23:48 -0400 Received: from smtpout1430.sc1.he.tucows.com ([64.97.157.130] helo=n007.sc1.he.tucows.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In1N1-00018g-Nk for tls@ietf.org; Tue, 30 Oct 2007 20:23:43 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 470D10480042B394 for tls@ietf.org; Wed, 31 Oct 2007 00:23:42 +0000 Message-ID: <4727CA8F.8050708@bolyard.com> Date: Tue, 30 Oct 2007 17:21:35 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9a9pre) Gecko/2007103002 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] DH group validation References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> In-Reply-To: <20071029160923.24C5233C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > OK, so this seems like a minor optimization but it does require a > change to TLS, which, as I've commented before, my instinct is > to avoid. My general intuition is that client public key performance > isn't an enormous concern, since it's generally a latency issue > as opposed to a throughput issue, so I'm mildly negative on this > change, just on the theory of changing as little as possible. > > Right now my sense is that you and Peter Gutmann would like to > see this change made and I would rather not. That's a pretty > small set of opinions to decide from. Pasi may eventually need > to run a straw poll, but first can I ask if there are other > WG members who want to weigh in with their feelings on this? The > general feeling of the WG may turn out to be clear... > > Folks? If we add q to the DH params, IMO it must be optional. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 03:08:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In7dr-0003pS-Et; Wed, 31 Oct 2007 03:05:31 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1In7dp-0003p7-N4 for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 03:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In7dp-0003mA-AZ for tls@ietf.org; Wed, 31 Oct 2007 03:05:29 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In7dh-0004UT-3w for tls@ietf.org; Wed, 31 Oct 2007 03:05:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V74cDx021211 for ; Wed, 31 Oct 2007 09:05:07 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:04:31 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:04:31 +0200 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 Subject: RE: [TLS] DH group validation Date: Wed, 31 Oct 2007 09:04:31 +0200 Message-ID: In-Reply-To: <20071029160923.24C5233C21@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DH group validation Thread-Index: AcgaRt9CTJb1sWPWQnahs8O5nV6BHgBRGF9g References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> From: To: X-OriginalArrivalTime: 31 Oct 2007 07:04:31.0022 (UTC) FILETIME=[48C3C4E0:01C81B8C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > OK, so this seems like a minor optimization but it does require a > change to TLS, which, as I've commented before, my instinct is > to avoid. My general intuition is that client public key performance=20 > isn't an enormous concern, since it's generally a latency issue > as opposed to a throughput issue, so I'm mildly negative on this > change, just on the theory of changing as little as possible. If a server wants to allow clients this chance for optimization,=20 it can do so today: just send a known group (e.g. one of those=20 used in IKE). Those groups also have special properties which=20 make using short private exponents safer, and use generator=20 "2", which makes calculations even faster. This possibility is already mentioned in the current draft as "MAY"; I wouldn't object to changing it to "SHOULD assist the client by providing one of the groups defined in [some ref]", and adding a note this allows clients to perform certain optimizations. Best regards, Pasi=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 04:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8b0-0004Bq-2v; Wed, 31 Oct 2007 04:06:38 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1In8az-000436-3j for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 04:06:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8ax-00040K-L4 for tls@ietf.org; Wed, 31 Oct 2007 04:06:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In8ax-0007PI-2y for tls@ietf.org; Wed, 31 Oct 2007 04:06:35 -0400 Received: from tau.invalid (p508EAF26.dip0.t-ipconnect.de [80.142.175.38]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1In8aw0piM-0004qz; Wed, 31 Oct 2007 09:06:34 +0100 Received: by tau.invalid (Postfix, from userid 1000) id E55EB1BBE7; Wed, 31 Oct 2007 09:06:35 +0100 (CET) Date: Wed, 31 Oct 2007 09:06:35 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] DH group validation Message-ID: <20071031080635.GA20215@tau.invalid> References: <20071029160923.24C5233C21@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX19lr3wbnD0jNTYMvC2TACCvR2v0mVzG74gMaJx MWkCCHtxkL6Zz3JZ27b+dlg195VRc4jdmsz+Vcg0QE4ZwngfTi nodgm0Cl48rUsfUc5tXBnwzGihIn1wUg7juaWJt6Hvxa4vuumQ 4hQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, Oct 31, 2007 at 09:04:31AM +0200, Pasi.Eronen@nokia.com wrote: > Eric Rescorla wrote: >> OK, so this seems like a minor optimization but it does require a >> change to TLS, which, as I've commented before, my instinct is >> to avoid. My general intuition is that client public key performance >> isn't an enormous concern, since it's generally a latency issue >> as opposed to a throughput issue, so I'm mildly negative on this >> change, just on the theory of changing as little as possible. > If a server wants to allow clients this chance for optimization, > it can do so today: just send a known group (e.g. one of those > used in IKE). Those groups also have special properties which > make using short private exponents safer, and use generator > "2", which makes calculations even faster. While this would work to get the speed advantage, it is not very good as an optimization in general because it requires clients to have large tables of known groups to match against. This could be a problem especially for those small devices that would most benefit from short q. Also, known groups always are a trade-off. If everyone were using the same group, then discrete log attacks for this particular modulus and generator might become worthwile. If different servers are using different groups, then there isn't one particular target group. So while using known groups certainly is reasonable, I think we shouldn't create artificial incentives for using known groups. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 04:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9HY-0004dH-Ik; Wed, 31 Oct 2007 04:50:36 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1In9HX-0004cz-EC for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 04:50:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9HW-0004cr-VO for tls@ietf.org; Wed, 31 Oct 2007 04:50:35 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In9HW-0000r4-D1 for tls@ietf.org; Wed, 31 Oct 2007 04:50:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V8o5B0023939; Wed, 31 Oct 2007 10:50:28 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:50:24 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:50:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] DH group validation Date: Wed, 31 Oct 2007 10:50:21 +0200 Message-ID: In-Reply-To: <20071031080635.GA20215@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DH group validation Thread-Index: AcgblPj/vV0/c/XjTtGAOXG9tJiMpAABN+uA References: <20071029160923.24C5233C21@delta.rtfm.com> <20071031080635.GA20215@tau.invalid> From: To: X-OriginalArrivalTime: 31 Oct 2007 08:50:24.0009 (UTC) FILETIME=[1370A790:01C81B9B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > If a server wants to allow clients this chance for > > optimization, it can do so today: just send a known group > > (e.g. one of those used in IKE). Those groups also have special > > properties which make using short private exponents safer, and > > use generator "2", which makes calculations even faster. >=20 > While this would work to get the speed advantage, it is not very > good as an optimization in general because it requires clients to > have large tables of known groups to match against. This could > be a problem especially for those small devices that would most > benefit from short q. A table the storing the current SHOULD/MUST level groups used in=20 IKEv2 would take <400 bytes -- not a small table, but not especially=20 large either (and I guess you could survive with just storing hashes of the p's). =20 > Also, known groups always are a trade-off. If everyone were using the > same group, then discrete log attacks for this particular modulus and > generator might become worthwile. If different servers are using > different groups, then there isn't one particular target group. So > while using known groups certainly is reasonable, I think we shouldn't > create artificial incentives for using known groups. In IKEv1/IKEv2, everyone is using the same group. =CDf this caused huge problems, I think we'd know by now... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 05:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9pa-0002XX-UI; Wed, 31 Oct 2007 05:25:46 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1In9pa-0002Wu-1l for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 05:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In9pZ-0002Vn-6y for tls@ietf.org; Wed, 31 Oct 2007 05:25:45 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In9pU-0002HA-So for tls@ietf.org; Wed, 31 Oct 2007 05:25:45 -0400 Received: from tau.invalid (p508EAF26.dip0.t-ipconnect.de [80.142.175.38]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1In9pB0DW2-0002Eu; Wed, 31 Oct 2007 10:25:23 +0100 Received: by tau.invalid (Postfix, from userid 1000) id A47151BBE7; Wed, 31 Oct 2007 10:25:18 +0100 (CET) Date: Wed, 31 Oct 2007 10:25:18 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] DH group validation Message-ID: <20071031092518.GA21675@tau.invalid> References: <20071029160923.24C5233C21@delta.rtfm.com> <20071031080635.GA20215@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX18YzAAKuesGFtXPhBeGo/R4ezQqNZ1KEOnn641 vjONOcdbAJ+DdBH6bBtgQcrLgehlIZfV4rFNq0aI3j36m8M6Qv qxvqoXP5yIYl+/2dKYDXEeOE46NwT/9LmtttI/aDWYLZDmgxVQ OQw== X-Spam-Score: -0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, Oct 31, 2007 at 10:50:21AM +0200, Pasi.Eronen@nokia.com wrote: > Bodo Moeller wrote: >>> If a server wants to allow clients this chance for >>> optimization, it can do so today: just send a known group >>> (e.g. one of those used in IKE). Those groups also have special >>> properties which make using short private exponents safer, and >>> use generator "2", which makes calculations even faster. >> While this would work to get the speed advantage, it is not very >> good as an optimization in general because it requires clients to >> have large tables of known groups to match against. This could >> be a problem especially for those small devices that would most >> benefit from short q. > A table the storing the current SHOULD/MUST level groups used in=20 > IKEv2 would take <400 bytes -- not a small table, but not especially=20 > large either (and I guess you could survive with just storing hashes > of the p's). True in this case. I was assuming more known groups from other sources, not just the IKE ones. Still this approach has a rather kludgey feel to it. >> Also, known groups always are a trade-off. If everyone were using the >> same group, then discrete log attacks for this particular modulus and >> generator might become worthwile. If different servers are using >> different groups, then there isn't one particular target group. So >> while using known groups certainly is reasonable, I think we shouldn't >> create artificial incentives for using known groups. > In IKEv1/IKEv2, everyone is using the same group. =CDf this caused > huge problems, I think we'd know by now... Remember how the index calculus approach for computing discrete logarithms works: the first stage of computations depends on the modulus only, not on the specific DL problem. This means that considerable effort can be saved if many DL problems share a single modulus. This hasn't been a huge problem since with the specific algorithms known now and the specific computing equipment available now, it looks like the 1024-bit OAKLEY group is out of reach. At the edge, though, a k-bit known group must be expected to be less secure in practice than a well-chosen k-bit unknown group. On the positive side, with well-known groups, everyone has the chance to use fixed precomputation to speed up some of the DH computations. So the penalty for using a larger group for compensation isn't necessarily too bad. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 11:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFRm-0005DS-7w; Wed, 31 Oct 2007 11:25:34 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InFRl-0005Cj-CA for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFRl-0005Cb-2h for tls@ietf.org; Wed, 31 Oct 2007 11:25:33 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFRj-0003M0-NK for tls@ietf.org; Wed, 31 Oct 2007 11:25:33 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VFPCGp011656; Wed, 31 Oct 2007 17:25:19 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 17:24:55 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 17:24:55 +0200 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: Wed, 31 Oct 2007 17:24:59 +0200 Message-ID: In-Reply-To: <20071029214813.CD3DC33C3D@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated TLS ID (certificate restrictions #57) Thread-Index: Acgad9mRenxV3jX6Tbiohh5KjIaG/wBWH5MQ References: <20071029214813.CD3DC33C3D@delta.rtfm.com> From: To: , X-OriginalArrivalTime: 31 Oct 2007 15:24:55.0806 (UTC) FILETIME=[30EE39E0:01C81BD2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [TLS] Re: Updated TLS ID (certificate restrictions #57) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > The changes list is: > - Redid the hash function advertisements for CertificateRequest > and the client-side extension. They are now pairs of > hash/signature and the semantics are clearly defined for > all uses of signatures (hopefully). [Issue 41] > - Cleaned up certificate text in 7.4.2 and 7.4.6 [Issue 57] This looks pretty good. In Section 7.4.2, I think there's still some room for simplification. Currently it says: If no "signature_algorithms" extension is present, the end-entity certificate MUST be signed as follows: Key Exchange Alg. Signature Algorithm Used by Issuer RSA RSA (RSASSA-PKCS1-v1_5) DHE_RSA DH_RSA RSA_PSK ECDH_RSA ECDHE_RSA DHE_DSS DSA DH_DSS ECDH_ECDSA ECDSA ECDHE_ECDSA I think it would be simpler to specify the default behavior in one place, and not to make it ciphersuite-dependent. E.g. "if the client does not send signature_algorithms, behave as if rsa+sha1 had been sent". Or we could just require everyone to send signature_algorithms. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 14:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIG3-00082w-92; Wed, 31 Oct 2007 14:25:39 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InIG2-00082q-DO for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InIG2-00082i-3g for tls@ietf.org; Wed, 31 Oct 2007 14:25:38 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InIFw-0003jO-0F for tls@ietf.org; Wed, 31 Oct 2007 14:25:38 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 9869F153BB5 for ; Wed, 31 Oct 2007 14:24:55 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 67641153708 for ; Wed, 31 Oct 2007 14:24:55 -0400 (EDT) Message-ID: <4728C885.4000108@pobox.com> Date: Wed, 31 Oct 2007 11:25:09 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] DH group validation References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org It seems to me that the goal of this proposed change is to allow constrained clients to enjoy the benefits of forward secrecy without suffering a large performance hit. Trying to adjust Diffie-Hellman may not be the best option. On my Windows machine, here is a performance comparison of RSA and DH: 48-byte size RSA encrypt DH generate key DH compute secret 1536 0.00086 0.0691 0.0687 2048 0.00140 0.1547 0.1531 (The DH groups used are from RFC 3526 MODP.) Resurrecting the RSA_EXPORT key exchange mechanism and repackaging it as ephemeral RSA (and removing the key length restrictions) would solve this problem and there is already a body of existing code to do it. These constrained clients could even ditch all their Diffie-Hellman code, saving some memory. Using the above numbers, a 1536-bit ephemeral RSA exchange would require 0.86 milliseconds of cryptographic computation by the client, whereas with 1536-bit ephemeral Diffie-Hellman would require 138 ms, a factor of 160. A 2048-bit exchange takes 1.4 ms and 308 ms respectively, a factor of 220. (I don't know how much faster these DH computations would be if the q parameter was incorporated.) Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 15:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJ2L-0006s3-OD; Wed, 31 Oct 2007 15:15:33 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InJ2G-0006oB-9C for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 15:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJ2F-0006nr-RQ; Wed, 31 Oct 2007 15:15:27 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InJ2F-00067p-ER; Wed, 31 Oct 2007 15:15:27 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1D01A26E69; Wed, 31 Oct 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1InJ1q-0004Zc-0E; Wed, 31 Oct 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 31 Oct 2007 15:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-06.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --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 : The Transport Layer Security (TLS) Protocol Version 1.2 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc4346-bis-06.txt Pages : 99 Date : 2007-10-31 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc4346-bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-31142731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4346-bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-31142731.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Wed Oct 31 15:40:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJOn-00087J-IJ; Wed, 31 Oct 2007 15:38:45 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InJOm-00086X-BG for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 15:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJOm-00086J-1O for tls@ietf.org; Wed, 31 Oct 2007 15:38:44 -0400 Received: from smtpout1451.sc1.he.tucows.com ([64.97.157.151] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InJOf-0007rb-Qb for tls@ietf.org; Wed, 31 Oct 2007 15:38:44 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 470D104800460CBC; Wed, 31 Oct 2007 19:37:55 +0000 Message-ID: <4728D989.6090201@bolyard.com> Date: Wed, 31 Oct 2007 12:37:45 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9a9pre) Gecko/2007103002 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: Mike References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> In-Reply-To: <4728C885.4000108@pobox.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@ietf.org Subject: [TLS] Ephemeral RSA (was: DH group validation) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mike wrote: > Resurrecting the RSA_EXPORT key exchange mechanism and > repackaging it as ephemeral RSA (and removing the key length > restrictions) would solve this problem and there is already > a body of existing code to do it. I would support a proposal to do that. It would also address NIST/NSA's desire that signature keys never be used for encryption and vice-versa. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 16:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InKId-0005IE-4t; Wed, 31 Oct 2007 16:36:27 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InKIb-0005Fo-JH for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 16:36:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InKIb-00052r-87 for tls@ietf.org; Wed, 31 Oct 2007 16:36:25 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InKIL-0007Dw-Qx for tls@ietf.org; Wed, 31 Oct 2007 16:36:10 -0400 Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id l9VKa92x010235 for ; Wed, 31 Oct 2007 16:36:09 -0400 (EDT) X-AuditID: 90333308-00001478000006e8-aa-4728e7397d19 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 16:36:09 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 16:36:08 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] DH group validation Date: Wed, 31 Oct 2007 16:36:07 -0400 Message-ID: In-Reply-To: <4728C885.4000108@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DH group validation Thread-Index: Acgb7APh6/aGt8fQQYC7ubJZlFEQUQAD1LCw References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid><20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> From: "Kemp, David P." To: "Mike" , X-OriginalArrivalTime: 31 Oct 2007 20:36:08.0897 (UTC) FILETIME=[AAF5CB10:01C81BFD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Mike, Do you have comparable numbers for RSA decrypt (for constrained devices or machines requiring higher throughput) and for ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) key sizes? -----Original Message----- From: Mike [mailto:mike-list@pobox.com]=20 Sent: Wednesday, October 31, 2007 2:25 PM To: tls@ietf.org Subject: Re: [TLS] DH group validation It seems to me that the goal of this proposed change is to allow constrained clients to enjoy the benefits of forward secrecy without suffering a large performance hit. Trying to adjust Diffie-Hellman may not be the best option. On my Windows machine, here is a performance comparison of RSA and DH: 48-byte size RSA encrypt DH generate key DH compute secret 1536 0.00086 0.0691 0.0687 2048 0.00140 0.1547 0.1531 (The DH groups used are from RFC 3526 MODP.) Resurrecting the RSA_EXPORT key exchange mechanism and repackaging it as ephemeral RSA (and removing the key length restrictions) would solve this problem and there is already a body of existing code to do it. These constrained clients could even ditch all their Diffie-Hellman code, saving some memory. Using the above numbers, a 1536-bit ephemeral RSA exchange would require 0.86 milliseconds of cryptographic computation by the client, whereas with 1536-bit ephemeral Diffie-Hellman would require 138 ms, a factor of 160. A 2048-bit exchange takes 1.4 ms and 308 ms respectively, a factor of 220. (I don't know how much faster these DH computations would be if the q parameter was incorporated.) Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 16:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InKY8-0000xU-P9; Wed, 31 Oct 2007 16:52:28 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InKY7-0000v9-Dz for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 16:52:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InKY7-0000uX-2K for tls@ietf.org; Wed, 31 Oct 2007 16:52:27 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InKY5-0008B7-PA for tls@ietf.org; Wed, 31 Oct 2007 16:52:26 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6C6D333C21; Wed, 31 Oct 2007 13:47:51 -0700 (PDT) Date: Wed, 31 Oct 2007 13:47:50 -0700 From: Eric Rescorla To: "Kemp, David P." Subject: Re: [TLS] DH group validation In-Reply-To: References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071031204751.6C6D333C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Actually the relevant number is RSA key generation time, which is MUCH slower than DH key generation. On my laptop, RSA key generation is about 50x slower than RSA decryption, making it basically prohibitive to generate a new RSA key pair for each transaction, which is of course what is required for PFS. -Ekr At Wed, 31 Oct 2007 16:36:07 -0400, Kemp, David P. wrote: > > Mike, > > Do you have comparable numbers for RSA decrypt (for constrained > devices or machines requiring higher throughput) and for > ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) > key sizes? > > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com] > Sent: Wednesday, October 31, 2007 2:25 PM > To: tls@ietf.org > Subject: Re: [TLS] DH group validation > > It seems to me that the goal of this proposed change is to > allow constrained clients to enjoy the benefits of forward > secrecy without suffering a large performance hit. Trying > to adjust Diffie-Hellman may not be the best option. > > On my Windows machine, here is a performance comparison of > RSA and DH: > > 48-byte > size RSA encrypt DH generate key DH compute secret > 1536 0.00086 0.0691 0.0687 > 2048 0.00140 0.1547 0.1531 > > (The DH groups used are from RFC 3526 MODP.) > > Resurrecting the RSA_EXPORT key exchange mechanism and > repackaging it as ephemeral RSA (and removing the key length > restrictions) would solve this problem and there is already > a body of existing code to do it. These constrained clients > could even ditch all their Diffie-Hellman code, saving some > memory. > > Using the above numbers, a 1536-bit ephemeral RSA exchange > would require 0.86 milliseconds of cryptographic computation > by the client, whereas with 1536-bit ephemeral Diffie-Hellman > would require 138 ms, a factor of 160. A 2048-bit exchange > takes 1.4 ms and 308 ms respectively, a factor of 220. (I > don't know how much faster these DH computations would be if > the q parameter was incorporated.) > > Mike > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 17:58:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLY9-0002P2-OE; Wed, 31 Oct 2007 17:56:33 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InLY8-0002Nw-E9 for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 17:56:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLY8-0001Vw-2x for tls@ietf.org; Wed, 31 Oct 2007 17:56:32 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InLXg-00028n-7K for tls@ietf.org; Wed, 31 Oct 2007 17:56:04 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 801312FB for ; Wed, 31 Oct 2007 17:56:17 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 4F3B790C17 for ; Wed, 31 Oct 2007 17:56:17 -0400 (EDT) Message-ID: <4728FA0F.3020509@pobox.com> Date: Wed, 31 Oct 2007 14:56:31 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Ephemeral RSA (was Re: [TLS] DH group validation) References: <20071016154947.883D933C21@delta.rtfm.com><20071017073549.GA26553@tau.invalid><20071020192547.3BE1C33C28@delta.rtfm.com><20071029151458.GB10330@tau.invalid><20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Do you have comparable numbers for RSA decrypt (for constrained > devices or machines requiring higher throughput) and for > ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) > key sizes? I don't have access to any constrained devices to try this on, but these numbers are based on OpenSSL 0.9.8 on a 3.2GHz Windows XP machine. size RSA keygen encrypt decrypt DH keygen DH secret 1536 0.485 0.00084 0.020 0.0691 0.0691 2048 1.647 0.00138 0.047 0.1545 0.1534 The RSA key generation time is an average of generating 5 keys of each size, which on this machine is a factor of 7 to 11 slower than computing DH keys. The decrypt operation is more than 3 times as fast as computing the DH secret. I haven't implemented any elliptic curve code, so I can't produce any numbers for that. But for ephemeral RSA vs. ephemeral DH, there is a clear win for clients: size ephemeral Diffie-Hellman eph-RSA speedup 1536 0.0691 + 0.0691 = 0.1382 0.00084 160x 2048 0.1545 + 0.1534 = 0.3079 0.00138 220x The server takes a hit if it generates a new ephemeral key for every connection: size eph-DH ephemeral-RSA slowdown 1536 0.1382 0.485 + 0.020 = 0.505 3.6x 2048 0.3079 1.647 + 0.047 = 1.694 5.5x If the server reused ephemeral keys just 10 times, the numbers would be: size ephemeral-DH ephemeral-RSA 1536 0.00691 + 0.0691 = 0.076 0.0485 + 0.020 = 0.0685 2048 0.01545 + 0.1534 = 0.169 0.1647 + 0.047 = 0.2117 Reusing an ephemeral key 10 times achieves "almost" perfect forward secrecy with similar server performance, and a 160x to 220x increase in client performance. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 18:14:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLoq-0004bY-1M; Wed, 31 Oct 2007 18:13:48 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InLoo-0004as-Jb for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 18:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLoo-0004OR-9f for tls@ietf.org; Wed, 31 Oct 2007 18:13:46 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLob-0007Mk-A8 for tls@ietf.org; Wed, 31 Oct 2007 18:13:39 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id D1B2E153D8B for ; Wed, 31 Oct 2007 18:13:16 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id A0D00153795 for ; Wed, 31 Oct 2007 18:13:15 -0400 (EDT) Message-ID: <4728FE08.3020901@pobox.com> Date: Wed, 31 Oct 2007 15:13:28 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] DH group validation References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <20071031204751.6C6D333C21@delta.rtfm.com> In-Reply-To: <20071031204751.6C6D333C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > Actually the relevant number is RSA key generation time, which is > MUCH slower than DH key generation. On my laptop, RSA key > generation is about 50x slower than RSA decryption, making > it basically prohibitive to generate a new RSA key pair for > each transaction, which is of course what is required for PFS. Yes on the server end RSA key generation is the biggest factor, but the comparison is not RSA keygen vs. RSA decryption, but rather (RSA keygen + RSA decrypt) vs. (DH keygen + DH secret). As I noted in my last message, this is a factor of 4 to 6 times on my machine. However, if you reuse the ephemeral keys just 10 times, the performance is roughly the same. Of course reusing keys doesn't achieve -perfect- forward secrecy, but is very close. To attack a million sessions using simple RSA key exchange requires breaking one key, whereas you would need to break 100,000 ephemeral RSA keys to achieve the same result. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 19:05:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMb0-0007Aq-CK; Wed, 31 Oct 2007 19:03:34 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InMay-00078g-CH for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 19:03:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMay-00078J-0g for tls@ietf.org; Wed, 31 Oct 2007 19:03:32 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMax-0005L4-Kp for tls@ietf.org; Wed, 31 Oct 2007 19:03:31 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 76D1B33C21; Wed, 31 Oct 2007 15:58:57 -0700 (PDT) Date: Wed, 31 Oct 2007 15:58:56 -0700 From: Eric Rescorla To: Mike Subject: Re: Ephemeral RSA (was Re: [TLS] DH group validation) In-Reply-To: <4728FA0F.3020509@pobox.com> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <4728FA0F.3020509@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071031225857.76D1B33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Wed, 31 Oct 2007 14:56:31 -0700, Mike wrote: > > > Do you have comparable numbers for RSA decrypt (for constrained > > devices or machines requiring higher throughput) and for > > ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) > > key sizes? > > I don't have access to any constrained devices to try this on, > but these numbers are based on OpenSSL 0.9.8 on a 3.2GHz > Windows XP machine. > > size RSA keygen encrypt decrypt DH keygen DH secret > 1536 0.485 0.00084 0.020 0.0691 0.0691 > 2048 1.647 0.00138 0.047 0.1545 0.1534 > > The RSA key generation time is an average of generating 5 keys > of each size, which on this machine is a factor of 7 to 11 > slower than computing DH keys. The decrypt operation is more > than 3 times as fast as computing the DH secret. You're using full-length exponentials, right? Using short exponentials produces a pretty significant performance improvement. DH in a 1024-bit group with a 256-bit exponent is about 50% slower than RSA with a 1024-bit modulus. And remember that the server can get this edge without modifying the protocol. So, now you're looking at more like a factor of 30. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 19:05:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMbv-0000HN-CE; Wed, 31 Oct 2007 19:04:31 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InMbt-0000FU-DR for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 19:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMbs-0000Ei-C4 for tls@ietf.org; Wed, 31 Oct 2007 19:04:28 -0400 Received: from edge.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InMbf-0001sw-RG for tls@ietf.org; Wed, 31 Oct 2007 19:04:28 -0400 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 <0JQS00C6YTED4Y00@mail-mta.sfvic.sunlabs.com> for tls@ietf.org; Wed, 31 Oct 2007 16:03:49 -0700 (PDT) Received: from [129.146.75.205] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQS006T9TECZII0@mail.sunlabs.com> for tls@ietf.org; Wed, 31 Oct 2007 16:03:49 -0700 (PDT) Date: Wed, 31 Oct 2007 16:03:51 -0700 From: Vipul Gupta Subject: Re: Ephemeral RSA (was Re: [TLS] DH group validation) In-reply-to: <4728FA0F.3020509@pobox.com> To: Mike Message-id: <09B7476F-784A-4D3F-962D-8109367E165F@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <4728FA0F.3020509@pobox.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Oct 31, 2007, at 2:56 PM, Mike wrote: >> Do you have comparable numbers for RSA decrypt (for constrained >> devices or machines requiring higher throughput) and for >> ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) >> key sizes? > > I don't have access to any constrained devices to try this on, > but these numbers are based on OpenSSL 0.9.8 on a 3.2GHz > Windows XP machine. > > size RSA keygen encrypt decrypt DH keygen DH secret > 1536 0.485 0.00084 0.020 0.0691 0.0691 > 2048 1.647 0.00138 0.047 0.1545 0.1534 > > > I haven't implemented any elliptic curve code, so I can't > produce any numbers for that. Recent versions of OpenSSL (yours might qualify) have ECC built in. You can get timing information for secp192/secp224 as follows: % openssl speed ecdhp192 ecdhp224 ecdsap192 escdsap224 (Unlike RSA, ECC verification is slower than signing) vipul p.s. We have some papers with performance numbers on constrained devices at research.sun.com/projects/crypto (they are from a couple of years ago) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 19:05:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMb0-0007Aq-CK; Wed, 31 Oct 2007 19:03:34 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InMay-00078g-CH for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 19:03:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMay-00078J-0g for tls@ietf.org; Wed, 31 Oct 2007 19:03:32 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMax-0005L4-Kp for tls@ietf.org; Wed, 31 Oct 2007 19:03:31 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 76D1B33C21; Wed, 31 Oct 2007 15:58:57 -0700 (PDT) Date: Wed, 31 Oct 2007 15:58:56 -0700 From: Eric Rescorla To: Mike Subject: Re: Ephemeral RSA (was Re: [TLS] DH group validation) In-Reply-To: <4728FA0F.3020509@pobox.com> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <4728FA0F.3020509@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071031225857.76D1B33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Wed, 31 Oct 2007 14:56:31 -0700, Mike wrote: > > > Do you have comparable numbers for RSA decrypt (for constrained > > devices or machines requiring higher throughput) and for > > ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) > > key sizes? > > I don't have access to any constrained devices to try this on, > but these numbers are based on OpenSSL 0.9.8 on a 3.2GHz > Windows XP machine. > > size RSA keygen encrypt decrypt DH keygen DH secret > 1536 0.485 0.00084 0.020 0.0691 0.0691 > 2048 1.647 0.00138 0.047 0.1545 0.1534 > > The RSA key generation time is an average of generating 5 keys > of each size, which on this machine is a factor of 7 to 11 > slower than computing DH keys. The decrypt operation is more > than 3 times as fast as computing the DH secret. You're using full-length exponentials, right? Using short exponentials produces a pretty significant performance improvement. DH in a 1024-bit group with a 256-bit exponent is about 50% slower than RSA with a 1024-bit modulus. And remember that the server can get this edge without modifying the protocol. So, now you're looking at more like a factor of 30. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 19:05:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMbv-0000HN-CE; Wed, 31 Oct 2007 19:04:31 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InMbt-0000FU-DR for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 19:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMbs-0000Ei-C4 for tls@ietf.org; Wed, 31 Oct 2007 19:04:28 -0400 Received: from edge.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InMbf-0001sw-RG for tls@ietf.org; Wed, 31 Oct 2007 19:04:28 -0400 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 <0JQS00C6YTED4Y00@mail-mta.sfvic.sunlabs.com> for tls@ietf.org; Wed, 31 Oct 2007 16:03:49 -0700 (PDT) Received: from [129.146.75.205] ([192.18.43.225]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JQS006T9TECZII0@mail.sunlabs.com> for tls@ietf.org; Wed, 31 Oct 2007 16:03:49 -0700 (PDT) Date: Wed, 31 Oct 2007 16:03:51 -0700 From: Vipul Gupta Subject: Re: Ephemeral RSA (was Re: [TLS] DH group validation) In-reply-to: <4728FA0F.3020509@pobox.com> To: Mike Message-id: <09B7476F-784A-4D3F-962D-8109367E165F@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <4728FA0F.3020509@pobox.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Oct 31, 2007, at 2:56 PM, Mike wrote: >> Do you have comparable numbers for RSA decrypt (for constrained >> devices or machines requiring higher throughput) and for >> ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) >> key sizes? > > I don't have access to any constrained devices to try this on, > but these numbers are based on OpenSSL 0.9.8 on a 3.2GHz > Windows XP machine. > > size RSA keygen encrypt decrypt DH keygen DH secret > 1536 0.485 0.00084 0.020 0.0691 0.0691 > 2048 1.647 0.00138 0.047 0.1545 0.1534 > > > I haven't implemented any elliptic curve code, so I can't > produce any numbers for that. Recent versions of OpenSSL (yours might qualify) have ECC built in. You can get timing information for secp192/secp224 as follows: % openssl speed ecdhp192 ecdhp224 ecdsap192 escdsap224 (Unlike RSA, ECC verification is slower than signing) vipul p.s. We have some papers with performance numbers on constrained devices at research.sun.com/projects/crypto (they are from a couple of years ago) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 20:18:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InNk2-0000ac-B0; Wed, 31 Oct 2007 20:16:58 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InNk0-0000Yg-FG for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 20:16:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InNk0-0000Wt-23 for tls@ietf.org; Wed, 31 Oct 2007 20:16:56 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InNjz-0008Et-6C for tls@ietf.org; Wed, 31 Oct 2007 20:16:55 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9FD5533C21; Wed, 31 Oct 2007 17:12:20 -0700 (PDT) Date: Wed, 31 Oct 2007 17:12:19 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] DH group validation In-Reply-To: <4728FE08.3020901@pobox.com> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <20071031204751.6C6D333C21@delta.rtfm.com> <4728FE08.3020901@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20071101001220.9FD5533C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At Wed, 31 Oct 2007 15:13:28 -0700, Mike wrote: > Yes on the server end RSA key generation is the biggest factor, > but the comparison is not RSA keygen vs. RSA decryption, but > rather (RSA keygen + RSA decrypt) vs. (DH keygen + DH secret). > As I noted in my last message, this is a factor of 4 to 6 times > on my machine. However, if you reuse the ephemeral keys just > 10 times, the performance is roughly the same. > > Of course reusing keys doesn't achieve -perfect- forward secrecy, > but is very close. To attack a million sessions using simple > RSA key exchange requires breaking one key, whereas you would > need to break 100,000 ephemeral RSA keys to achieve the same > result. This isn't necessarily the threat model. I don't consider the major objective of PFS to protect against large scale computation attacks but against targeted attacks on specific data flows after the termination of those flows. E.g., the FBI subpenas the server sometime after your connection has occurred. The relevant issue then becomes not the number of times the key is used but rather the length of time during which it is used. These are of course somewhat related but not necessarily in a predictable way. To see this, consider a server such as Apache, which operates multiple independent processes. There are two ways to have an ephemeral key with a limited lifespan: have it shared across multiple processes or have one key per process. Obviously in the second model a key used for 100 transactions will have a much longer lifespan than the first. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 20:31:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InNxT-0004Jj-VB; Wed, 31 Oct 2007 20:30:51 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InNxS-0004Fv-K1 for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 20:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InNxS-0004Fn-AS for tls@ietf.org; Wed, 31 Oct 2007 20:30:50 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InNxN-00059d-5C for tls@ietf.org; Wed, 31 Oct 2007 20:30:50 -0400 Received: by machshav.com (Postfix, from userid 512) id E47244CC; Thu, 1 Nov 2007 00:30:32 +0000 (GMT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 79FDE162; Thu, 1 Nov 2007 00:30:32 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 8DE8676616D; Wed, 31 Oct 2007 20:30:31 -0400 (EDT) Date: Thu, 1 Nov 2007 00:30:31 +0000 From: "Steven M. Bellovin" To: Eric Rescorla Subject: Re: [TLS] DH group validation Message-ID: <20071101003031.6a51b269@cs.columbia.edu> In-Reply-To: <20071101001220.9FD5533C21@delta.rtfm.com> References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <20071031204751.6C6D333C21@delta.rtfm.com> <4728FE08.3020901@pobox.com> <20071101001220.9FD5533C21@delta.rtfm.com> Organization: Columbia University X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.0; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, 31 Oct 2007 17:12:19 -0700 Eric Rescorla wrote: > At Wed, 31 Oct 2007 15:13:28 -0700, > Mike wrote: > > Yes on the server end RSA key generation is the biggest factor, > > but the comparison is not RSA keygen vs. RSA decryption, but > > rather (RSA keygen + RSA decrypt) vs. (DH keygen + DH secret). > > As I noted in my last message, this is a factor of 4 to 6 times > > on my machine. However, if you reuse the ephemeral keys just > > 10 times, the performance is roughly the same. > > > > Of course reusing keys doesn't achieve -perfect- forward secrecy, > > but is very close. To attack a million sessions using simple > > RSA key exchange requires breaking one key, whereas you would > > need to break 100,000 ephemeral RSA keys to achieve the same > > result. > > This isn't necessarily the threat model. I don't consider the > major objective of PFS to protect against large scale computation > attacks but against targeted attacks on specific data flows after > the termination of those flows. E.g., the FBI subpenas the server > sometime after your connection has occurred. The relevant > issue then becomes not the number of times the key is used > but rather the length of time during which it is used. These > are of course somewhat related but not necessarily in a predictable > way. > Add an implementation note suggesting low priority, background generation of new keys, but only block waiting for one when the use count threshold is reached. (We suggested something very similar in the JFK drafts.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 31 23:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InRA7-0007He-Pd; Wed, 31 Oct 2007 23:56:07 -0400 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1InRA7-0007HO-1M for tls-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 23:56:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InRA6-0006iU-Li for tls@ietf.org; Wed, 31 Oct 2007 23:56:06 -0400 Received: from rune.pobox.com ([208.210.124.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InR9Z-0005ge-7H for tls@ietf.org; Wed, 31 Oct 2007 23:55:33 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id B608715406E for ; Wed, 31 Oct 2007 23:55:45 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 86ED51537D1 for ; Wed, 31 Oct 2007 23:55:45 -0400 (EDT) Message-ID: <47294E4C.800@pobox.com> Date: Wed, 31 Oct 2007 20:55:56 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: Ephemeral RSA (was Re: [TLS] DH group validation) References: <20071016154947.883D933C21@delta.rtfm.com> <20071017073549.GA26553@tau.invalid> <20071020192547.3BE1C33C28@delta.rtfm.com> <20071029151458.GB10330@tau.invalid> <20071029160923.24C5233C21@delta.rtfm.com> <4728C885.4000108@pobox.com> <4728FA0F.3020509@pobox.com> <20071031225857.76D1B33C21@delta.rtfm.com> In-Reply-To: <20071031225857.76D1B33C21@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>> Do you have comparable numbers for RSA decrypt (for constrained >>> devices or machines requiring higher throughput) and for >>> ECDHE_RSA or ECDHE_ECDSA with equivalent (secp192/secp224) >>> key sizes? >> I don't have access to any constrained devices to try this on, >> but these numbers are based on OpenSSL 0.9.8 on a 3.2GHz >> Windows XP machine. >> >> size RSA keygen encrypt decrypt DH keygen DH secret >> 1536 0.485 0.00084 0.020 0.0691 0.0691 >> 2048 1.647 0.00138 0.047 0.1545 0.1534 >> >> The RSA key generation time is an average of generating 5 keys >> of each size, which on this machine is a factor of 7 to 11 >> slower than computing DH keys. The decrypt operation is more >> than 3 times as fast as computing the DH secret. > > You're using full-length exponentials, right? Using short exponentials > produces a pretty significant performance improvement. DH in > a 1024-bit group with a 256-bit exponent is about 50% slower than > RSA with a 1024-bit modulus. And remember that the server can > get this edge without modifying the protocol. So, now you're > looking at more like a factor of 30. I don't know. For RSA, I use RSA_generate_key and RSA_blinding_on to create the keys, RSA_public_encrypt and RSA_private_decrypt. (With ephemeral RSA, maybe you don't need to turn blinding on?) For DH I use DH_generate_key and DH_compute_key. I don't know of a way to tell these functions to use a certain exponent, so they are using their defaults. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls