From ietfc@btconnect.com Tue Feb 1 02:46:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17DB3A6C04 for ; Tue, 1 Feb 2011 02:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMUIYhkquwfV for ; Tue, 1 Feb 2011 02:46:50 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id BBBD53A6C5B for ; Tue, 1 Feb 2011 02:46:49 -0800 (PST) Received: from host217-44-202-151.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.151]) by c2beaomr06.btconnect.com with SMTP id BUG32987; Tue, 01 Feb 2011 10:50:01 +0000 (GMT) Message-ID: <00d001cbc1f4$dcc0e080$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?Michael_T=FCxen?= References: <20110127114502.24680.73782.idtracker@localhost><874o8uplm4.fsf@latte.josefsson.org> <09E8BE99-3D69-4693-99DF-2DDD9D48B52B@lurchi.franken.de> Date: Tue, 1 Feb 2011 10:28:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D47E558.0062, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4D47E55D.014C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: tls@ietf.org Subject: [TLS] IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 10:46:50 -0000 Michael I think that the IANA considerations could do with more work. Dropping 'Heartbeat Modes' and 'Heartbeat Message Types' into the IANA website could cause them to be lost for ever. If they are specific to (D)TLS, then I would want to see that in the title, or else have them subordinate to something that does. Second, while I like starting with values with one, you leave zero open for the next person to use! I would suggest reserving zero and 255 in both registries. Tom Petch From ietfc@btconnect.com Tue Feb 1 02:46:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B2A3A6C04 for ; Tue, 1 Feb 2011 02:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0hcwC2NVelr for ; Tue, 1 Feb 2011 02:46:50 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id BBB6F3A6C19 for ; Tue, 1 Feb 2011 02:46:49 -0800 (PST) Received: from host217-44-202-151.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.151]) by c2beaomr06.btconnect.com with SMTP id BUG32985; Tue, 01 Feb 2011 10:50:00 +0000 (GMT) Message-ID: <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?Michael_T=FCxen?= , "Florian Weimer" References: <20110127114502.24680.73782.idtracker@localhost><8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> Date: Tue, 1 Feb 2011 10:23:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D47E558.0062, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4D47E559.00B2,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 10:46:51 -0000 ----- Original Message ----- From: "Michael Tüxen" To: "Florian Weimer" Cc: Sent: Thursday, January 27, 2011 2:49 PM On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote: >> This document describes the Heartbeat Extension for the Transport >> Layer Security (TLS) and Datagram Transport Layer Security (DTLS) >> protocol. > > I think this paragraph > > | There MUST NOT be more than one HeartbeatRequest message in flight > | at a time. > > should be changed to: > > | Retransmissions MUST use the same payload as the original > | HeartbeatRequest message. The intention of the sentence in the ID is that you can not send multiple HeartbeatRequest out. This could overload the network since DTLS uses transport layers which do not necessary provide a congestion control. That is why you can only have one request in flight. Please note that it is not in flight anymore if the corresponding HeartbeatReply has been received or the retransmission timer fires. Michael My experience of the IESG is that they will insist on a paragraph about Congestion Control (lack of) and mitigation thereof. At the same time, I find it very hard to know what words will satisfy them; my most recent experience was with RFC6012, albeit a more complex scenario. Tom Petch > > The original requirement seems to be pretty much unimplementable > because of transport layer characteristics. Not sure what problem you are thinking about. An implementation of the ID for OpenSSL is available at http://sctp.fh-muenster.de/dtls-patches.html Best regards Michael > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstraße 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Michael.Tuexen@lurchi.franken.de Tue Feb 1 05:34:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689843A6DEF for ; Tue, 1 Feb 2011 05:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMaFIloZ0idk for ; Tue, 1 Feb 2011 05:34:50 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 72E543A7091 for ; Tue, 1 Feb 2011 05:34:25 -0800 (PST) Received: from [192.168.1.113] (p508FB1D6.dip.t-dialin.net [80.143.177.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D7E081C0C0BED; Tue, 1 Feb 2011 14:37:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= X-Priority: 3 In-Reply-To: <00d001cbc1f4$dcc0e080$4001a8c0@gateway.2wire.net> Date: Tue, 1 Feb 2011 14:37:40 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20110127114502.24680.73782.idtracker@localhost><874o8uplm4.fsf@latte.josefsson.org> <09E8BE99-3D69-4693-99DF-2DDD9D48B52B@lurchi.franken.de> <00d001cbc1f4$dcc0e080$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:34:51 -0000 On Feb 1, 2011, at 10:28 AM, t.petch wrote: > Michael > > I think that the IANA considerations could do with more work. > > Dropping 'Heartbeat Modes' and 'Heartbeat Message Types' > into the IANA website could cause them to be lost for ever. If they are > specific to (D)TLS, then I would want to see that in the title, or else > have them subordinate to something that does. We can name them "DTLS and TLS Heartbeat Modes" and "DTLS and TLS Heartbeat Message Types" or "(D)TLS Heartbeat Modes" and "(D)TLS Heartbeat Message Types", whatever you prefer. Any opinion? > > Second, while I like starting with values with one, you leave zero > open for the next person to use! I would suggest reserving > zero and 255 in both registries. Good idea. Well do that in the next ref. Best regards Michael > > Tom Petch > From turners@ieca.com Tue Feb 1 06:27:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C2B3A6CDE for ; Tue, 1 Feb 2011 06:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO2DlsisPlMF for ; Tue, 1 Feb 2011 06:27:49 -0800 (PST) Received: from nm6.bullet.mail.ac4.yahoo.com (nm6.bullet.mail.ac4.yahoo.com [98.139.52.203]) by core3.amsl.com (Postfix) with SMTP id 2075F3A6BA3 for ; Tue, 1 Feb 2011 06:27:49 -0800 (PST) Received: from [98.139.52.194] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 01 Feb 2011 14:31:03 -0000 Received: from [98.139.52.176] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 01 Feb 2011 14:31:03 -0000 Received: from [127.0.0.1] by omp1059.mail.ac4.yahoo.com with NNFMP; 01 Feb 2011 14:31:03 -0000 X-Yahoo-Newman-Id: 634141.79106.bm@omp1059.mail.ac4.yahoo.com Received: (qmail 52329 invoked from network); 1 Feb 2011 14:31:03 -0000 Received: from thunderfish.local (turners@96.241.4.28 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 01 Feb 2011 06:31:03 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: io4DEQcVM1mtP4J.AJHG1QzTTodFLHeljwMof7HrWVeFkkR 5Lz_n4bOl7RT35xz7Jw5jXbQh38QO33SDjffWE9Xe224UBsMfDGI1P27MnAI hFmDIQms7Qvc4zIkwLtD6zn1mE58mfd_uxx5pnoVyWWT8zU9cRN5ktqNCQ.B Bpr5_TNJnWp7ygn35xanNuMoMeXv6emESRmFBLxOANVoI86b9BxhC_.CNmZS BJG3P6BELDTCdtJKUZcuyhBl5HXXe6dLcJ_lwZ73JesUUBaPIlT59Ps8MI9h JC_jhc7PtX_adf4XK0R7b7S2E1mdCdN1Nna7L X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D481926.6090409@ieca.com> Date: Tue, 01 Feb 2011 09:31:02 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <20110127114502.24680.73782.idtracker@localhost><8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> In-Reply-To: <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:27:50 -0000 On 2/1/11 4:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Michael Tüxen" > To: "Florian Weimer" > Cc: > Sent: Thursday, January 27, 2011 2:49 PM > > On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote: > >>> This document describes the Heartbeat Extension for the Transport >>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS) >>> protocol. >> >> I think this paragraph >> >> | There MUST NOT be more than one HeartbeatRequest message in flight >> | at a time. >> >> should be changed to: >> >> | Retransmissions MUST use the same payload as the original >> | HeartbeatRequest message. > The intention of the sentence in the ID is that you can not send > multiple HeartbeatRequest out. This could overload the network since > DTLS uses transport layers which do not necessary provide a congestion > control. That is why you can only have one request in flight. > Please note that it is not in flight anymore if the corresponding > HeartbeatReply has been received or the retransmission timer fires. > > Michael > > My experience of the IESG is that they will insist on a paragraph about > Congestion Control (lack of) and mitigation thereof. At the same time, > I find it very hard to know what words will satisfy them; my most recent > experience was with RFC6012, albeit a more complex scenario. > > Tom Petch I suspect that the transport ADs' interest will be piqued the minute they read the words: mtu ;) The best thing to do is to ask for an early review from tsv-dir@ietf.org. I'm willing to send it over if you'd like? This is my bad, because I haven't yet figured out what magic incantation needs to go in drafts to appease the transport (and probably internet area) ADs. spt >> >> The original requirement seems to be pretty much unimplementable >> because of transport layer characteristics. > Not sure what problem you are thinking about. > An implementation of the ID for OpenSSL is available at > http://sctp.fh-muenster.de/dtls-patches.html > > Best regards > Michael >> >> -- >> Florian Weimer >> BFK edv-consulting GmbH http://www.bfk.de/ >> Kriegsstraße 100 tel: +49-721-96201-1 >> D-76133 Karlsruhe fax: +49-721-96201-99 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Joshua.Davies@travelocity.com Tue Feb 1 06:44:05 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984253A6C11 for ; Tue, 1 Feb 2011 06:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mtd46f40ogXQ for ; Tue, 1 Feb 2011 06:44:04 -0800 (PST) Received: from sgtulmg02-out.sabre.com (sgtulmg02-out.sabre.com [151.193.220.19]) by core3.amsl.com (Postfix) with ESMTP id E70263A6BED for ; Tue, 1 Feb 2011 06:44:03 -0800 (PST) X-ExtLoop1: From 10.12.97.30 X-IronPort-AV: E=Sophos;i="4.60,410,1291615200"; d="scan'208";a="812697737" Received: from unknown (HELO SGTULMHP001.Global.ad.sabre.com) ([10.12.97.30]) by sgtulmg02-out.sabre.com with ESMTP/TLS/AES128-SHA; 01 Feb 2011 08:47:19 -0600 Received: from SGTULMMP004.Global.ad.sabre.com ([::1]) by SGTULMHP001.Global.ad.sabre.com ([::1]) with mapi; Tue, 1 Feb 2011 08:47:18 -0600 From: "Davies, Joshua" To: Xuelei Fan , Paul Hoffman Date: Tue, 1 Feb 2011 08:47:19 -0600 Thread-Topic: [TLS] TLS 1.2 test clients? Thread-Index: AcvByheIwPNLjPCmSbqkm4CXZXVCzwAU5+b9 Message-ID: References: <4D46E4D8.3090307@vpnc.org>,<4D478E3E.9050604@Oracle.COM> In-Reply-To: <4D478E3E.9050604@Oracle.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 test clients? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:44:05 -0000 I wrote a sample TLS 1.2 client as a companion to a book - you can download= the source from http://media.wiley.com/product_ancillary/16/04709204/DOWNL= OAD/920411%20implementing_ssl_gcc.zip . The TLS 1.2 client is in the "afte= r/ch9" directory; just run: $ make $ ./https https://whatever.com It's not especially robust (it will crash if you try to connect to a pre-TL= S 1.2 server, for example), but you might find it useful for experimentatio= n purposes if you want to change, for example, the PRF hash function or all= ow null cipher specs. ________________________________________ From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Xuelei Fan [= Xuelei.Fan@oracle.com] Sent: Monday, January 31, 2011 10:38 PM To: Paul Hoffman Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.2 test clients? The recent JDK 7 snapshot releases support TLS 1.2 (see http://download.java.net/jdk7/). You're able to get and run the very simple sample code for simple HTTPS connections from http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSS= ERefGuide.html#HTTPSSample. If you run Java with "-Djavax.net.debug=3Dall -Dhttps.protocols=3DTLSv1.2" options, you would be able to find the detailed debugging log for TLS/SSL handshaking. About the detained tech guides, please refer to http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSS= ERefGuide.html. Xuelei Fan Java Platform, Oracle On 2/1/2011 12:35 AM, Paul Hoffman wrote: > Greetings again. I would like to test how servers react to a TLS > client that only does TLS 1.2. There are two browsers that can be put > into this state (IE under Win 7, and Opera), but neither give very > good diagnostics when a failure occurs. Further, Wireshark doesn't > give good dumps for TLS 1.2. > > Thus, if anyone here has a TLS 1.2 client that has reasonable > debugging of the TLS handshake and can do trivial HTTP (just send a > "GET /" and receive the response would be fine) after setting up a > tunnel, I'd greatly appreciate it. Also, if anyone has a Wireshark > plugin (?) that brings its TLS decoding up to 1.2, that would be great > as well. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls= From ietfc@btconnect.com Tue Feb 1 07:51:21 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B16F3A6E27 for ; Tue, 1 Feb 2011 07:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqpd021B8g+a for ; Tue, 1 Feb 2011 07:51:20 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by core3.amsl.com (Postfix) with ESMTP id 89CC43A6AC9 for ; Tue, 1 Feb 2011 07:51:17 -0800 (PST) Received: from host217-44-202-151.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.151]) by c2bthomr09.btconnect.com with SMTP id BPD15816; Tue, 01 Feb 2011 15:54:33 +0000 (GMT) Message-ID: <022201cbc21f$67d0c120$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?Michael_T=FCxen?= References: <20110127114502.24680.73782.idtracker@localhost><874o8uplm4.fsf@latte.josefsson.org> <09E8BE99-3D69-4693-99DF-2DDD9D48B52B@lurchi.franken.de> <00d001cbc1f4$dcc0e080$4001a8c0@gateway.2wire.net> Date: Tue, 1 Feb 2011 15:50:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D482CB9.011C, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4D482CBA.0072,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: tls@ietf.org Subject: Re: [TLS] IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:51:21 -0000 ----- Original Message ----- From: "Michael Tüxen" To: "t.petch" Cc: Sent: Tuesday, February 01, 2011 2:37 PM > On Feb 1, 2011, at 10:28 AM, t.petch wrote: > > > Michael > > > > I think that the IANA considerations could do with more work. > > > > Dropping 'Heartbeat Modes' and 'Heartbeat Message Types' > > into the IANA website could cause them to be lost for ever. If they are > > specific to (D)TLS, then I would want to see that in the title, or else > > have them subordinate to something that does. > > We can name them "DTLS and TLS Heartbeat Modes" and > "DTLS and TLS Heartbeat Message Types" or "(D)TLS Heartbeat Modes" > and "(D)TLS Heartbeat Message Types", whatever you prefer. Any opinion? I would go for just TLS Heartbeat Modes, and TLS Heartbeat Message Types. DTLS is a delta to TLS and there is a statement that everything is expected to carry across unless otherwise stated, so for me, TLS implies DTLS. Tom Petch > > > > Second, while I like starting with values with one, you leave zero > > open for the next person to use! I would suggest reserving > > zero and 255 in both registries. > Good idea. Well do that in the next ref. > > Best regards > Michael > > > > Tom Petch > From Michael.Tuexen@lurchi.franken.de Tue Feb 1 12:17:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6543A6C6B for ; Tue, 1 Feb 2011 12:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs1HWJ5Yuhdq for ; Tue, 1 Feb 2011 12:16:59 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 3310B3A6C42 for ; Tue, 1 Feb 2011 12:16:58 -0800 (PST) Received: from [192.168.1.113] (p508FB1D6.dip.t-dialin.net [80.143.177.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 85E971C0B4612; Tue, 1 Feb 2011 21:20:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4D481926.6090409@ieca.com> Date: Tue, 1 Feb 2011 21:20:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110127114502.24680.73782.idtracker@localhost><8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> <4D481926.6090409@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:17:01 -0000 On Feb 1, 2011, at 3:31 PM, Sean Turner wrote: > On 2/1/11 4:23 AM, t.petch wrote: >> ----- Original Message ----- >> From: "Michael T=FCxen" >> To: "Florian Weimer" >> Cc: >> Sent: Thursday, January 27, 2011 2:49 PM >>=20 >> On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote: >>=20 >>>> This document describes the Heartbeat Extension for the Transport >>>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS) >>>> protocol. >>>=20 >>> I think this paragraph >>>=20 >>> | There MUST NOT be more than one HeartbeatRequest message in flight >>> | at a time. >>>=20 >>> should be changed to: >>>=20 >>> | Retransmissions MUST use the same payload as the original >>> | HeartbeatRequest message. >> The intention of the sentence in the ID is that you can not send >> multiple HeartbeatRequest out. This could overload the network since >> DTLS uses transport layers which do not necessary provide a = congestion >> control. That is why you can only have one request in flight. >> Please note that it is not in flight anymore if the corresponding >> HeartbeatReply has been received or the retransmission timer fires. >>=20 >> Michael >>=20 >> My experience of the IESG is that they will insist on a paragraph = about >> Congestion Control (lack of) and mitigation thereof. At the same = time, >> I find it very hard to know what words will satisfy them; my most = recent >> experience was with RFC6012, albeit a more complex scenario. >>=20 >> Tom Petch >=20 > I suspect that the transport ADs' interest will be piqued the minute = they read the words: mtu ;) The best thing to do is to ask for an early = review from tsv-dir@ietf.org. I'm willing to send it over if you'd = like? Hi Sean, yes, please send it over to them. Robin and myself are working on some minor text changes and it would be nice to address also the comments we get from the tsv-dir in the next revision. >=20 > This is my bad, because I haven't yet figured out what magic = incantation needs to go in drafts to appease the transport (and probably = internet area) ADs. Hmm. Regarding path MTU discovery we made references to RFC 4821, which should make them happy (I hope). But let us get their comments and improve the document. Best regards Michael >=20 > spt >=20 >>>=20 >>> The original requirement seems to be pretty much unimplementable >>> because of transport layer characteristics. >> Not sure what problem you are thinking about. >> An implementation of the ID for OpenSSL is available at >> http://sctp.fh-muenster.de/dtls-patches.html >>=20 >> Best regards >> Michael >>>=20 >>> -- >>> Florian Weimer >>> BFK edv-consulting GmbH http://www.bfk.de/ >>> Kriegsstra=DFe 100 tel: +49-721-96201-1 >>> D-76133 Karlsruhe fax: +49-721-96201-99 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 From n.mavrogiannopoulos@gmail.com Thu Feb 3 14:09:27 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07183A6B11 for ; Thu, 3 Feb 2011 14:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI0Zb1m6Ol6P for ; Thu, 3 Feb 2011 14:09:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C91AE3A6A00 for ; Thu, 3 Feb 2011 14:09:26 -0800 (PST) Received: by eyd10 with SMTP id 10so1076859eyd.31 for ; Thu, 03 Feb 2011 14:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=q2qrKm19E3dM4XoUh5iSHA/7gV3WI+Q5uhLpr+xiTdk=; b=T/XVwvX+FZ5uRTaNyqNhmyH/vTVd+rjUoW6ISRkDAy5uNE4oQYgb6cv6wSUEo372tK Sks82zTjttSkBTPrviS68rVmHmHrkqmlFA3AQu3CKkQqVme6q6qyT+A8Yu7kadvEh5gg 507gVmW/BjEcFgrhiI9cXQeKYF18qSdmnV8cc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=CmFHPtubwPcOg/wb6g7EhLB7ZE6GMhJZbnFhftIJq/qIDfWgX8r2JhPV4b0LWblwiX at0WtwqqiE1GUdHkCibplGbwMvW3nOrWNes84PfCrw9MfP6rAgQn78iocV8Qhak+cM9W 8qcyVK30fgkyW3ihJ24FsM/b7OfK/QEITABaE= Received: by 10.213.4.134 with SMTP id 6mr14160017ebr.14.1296771168930; Thu, 03 Feb 2011 14:12:48 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id b52sm19400eei.13.2011.02.03.14.12.47 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 14:12:48 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D4B285F.1090109@gnutls.org> Date: Thu, 03 Feb 2011 23:12:47 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Using OpenPGP Keys for Transport Layer Security (TLS) Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:09:27 -0000 FYI. > A new Request for Comments is now available in online RFC libraries. > > > RFC 6091 > > Title: Using OpenPGP Keys for Transport > Layer Security (TLS) Authentication > Author: N. Mavrogiannopoulos, D. Gillmor > Status: Informational > Stream: IETF > Date: February 2011 > Mailbox: nikos.mavrogiannopoulos@esat.kuleuven.be, > dkg@fifthhorseman.net > Pages: 9 > Characters: 18529 > Obsoletes: RFC5081 > > I-D Tag: draft-mavrogiannopoulos-rfc5081bis-09.txt > > URL: http://www.rfc-editor.org/rfc/rfc6091.txt > > This memo defines Transport Layer Security (TLS) extensions and > associated semantics that allow clients and servers to negotiate the > use of OpenPGP certificates for a TLS session, and specifies how to > transport OpenPGP certificates via TLS. It also defines the registry > for non-X.509 certificate types. This document is not an Internet > Standards Track specification; it is published for informational purposes. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. From kanno.satoru@po.ntts.co.jp Fri Feb 4 01:22:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263D63A68AD for ; Fri, 4 Feb 2011 01:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unSVVrzMSjbV for ; Fri, 4 Feb 2011 01:22:12 -0800 (PST) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by core3.amsl.com (Postfix) with ESMTP id 190C33A689B for ; Fri, 4 Feb 2011 01:22:11 -0800 (PST) Received: from sadoku33.silk.ntts.co.jp (sadoku33 [10.7.18.33]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id p149PWa7020012 for ; Fri, 4 Feb 2011 18:25:32 +0900 (JST) Received: (from root@localhost) by sadoku33.silk.ntts.co.jp (8.13.8/NTTSOFT) id p149PWeB010641 for tls@ietf.org; Fri, 4 Feb 2011 18:25:32 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku33.silk.ntts.co.jp with SMTP id UAA10640; Fri, 4 Feb 2011 18:25:32 +0900 Received: from mail137.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id p149PV5e023984; Fri, 4 Feb 2011 18:25:31 +0900 Received: from mail137.silk.ntts.co.jp (localhost [127.0.0.1]) by mail137.silk.ntts.co.jp (8.14.4/NTTSOFT) with ESMTP id p149PW4o017847; Fri, 4 Feb 2011 18:25:32 +0900 (JST) Received: from ccmds32 (ccmds32.silk.ntts.co.jp [10.107.0.32]) by mail137.silk.ntts.co.jp (8.14.4/NTTSOFT) with SMTP id p149PWBb017844; Fri, 4 Feb 2011 18:25:32 +0900 (JST) Message-ID: <4D4BC5F7.6040109@po.ntts.co.jp> Date: Fri, 04 Feb 2011 18:25:11 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Subject: [TLS] Request for review: Camellia cipher suites for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 09:22:13 -0000 Folks, I've submitted "draft-kanno-tls-camellia-00". URL: http://www.ietf.org/internet-drafts/draft-kanno-tls-camellia-00.txt We merged three drafts into one draft. We included all additional cipher suites in a single draft to make it easier on implementers. But the cipher suites with SHA-1 are not included in this draft. Existing three drafts: - draft-kanno-tls-camellia-ecc-sha - draft-kanno-tls-camellia-psk - draft-kanno-tls-camellia-gcm New draft includes features as a following: - SHA2 variants - ECDH(E) and ECDSA - Galois/Counter Mode - Pre-shared key Comments about our document would be welcome. We plan to make this draft to next step 'Publication Request' within two weeks. Regards, ---------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) Author(s) : S. Kanno, M. Kanda Filename : draft-kanno-tls-camellia-00.txt Pages : 11 Date : 2011-02-04 This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to additional support the Camellia encryption algorithm as a block cipher. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kanno-tls-camellia-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno.satoru@po.ntts.co.jp From simon@josefsson.org Fri Feb 4 05:01:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E233A6BBA for ; Fri, 4 Feb 2011 05:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+HmI7pjpHtZ for ; Fri, 4 Feb 2011 05:01:46 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 3B04B3A695F for ; Fri, 4 Feb 2011 05:01:45 -0800 (PST) Received: from latte.josefsson.org (host-78-79-131-198.mobileonline.telia.com [78.79.131.198]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p14D4v94012951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Feb 2011 14:05:01 +0100 From: Simon Josefsson To: Satoru Kanno References: <4D4BC5F7.6040109@po.ntts.co.jp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110204:tls@ietf.org::w/nQTZ8Hos+/ZDXa:7daD X-Hashcash: 1:22:110204:kanno.satoru@po.ntts.co.jp::z8j2M4+njg3NJ6Pr:DYNP Date: Fri, 04 Feb 2011 14:04:56 +0100 In-Reply-To: <4D4BC5F7.6040109@po.ntts.co.jp> (Satoru Kanno's message of "Fri, 04 Feb 2011 18:25:11 +0900") Message-ID: <8739o40x3b.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Request for review: Camellia cipher suites for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 13:01:47 -0000 Satoru Kanno writes: > Folks, > > I've submitted "draft-kanno-tls-camellia-00". > URL: http://www.ietf.org/internet-drafts/draft-kanno-tls-camellia-00.txt I cannot find an IPR statement when searching for that draft on the IETF IPR Disclosure search page: https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=21179 Since Camellia is patented by NTT, I believe you need to submit an IPR disclosure for this document. /Simon From turners@ieca.com Fri Feb 4 17:41:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0C73A69D8 for ; Fri, 4 Feb 2011 17:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZz64xI-UkyD for ; Fri, 4 Feb 2011 17:41:56 -0800 (PST) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by core3.amsl.com (Postfix) with SMTP id AA0383A68FF for ; Fri, 4 Feb 2011 17:41:56 -0800 (PST) Received: from [98.139.91.68] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2011 01:45:20 -0000 Received: from [98.139.91.33] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 05 Feb 2011 01:45:20 -0000 Received: from [127.0.0.1] by omp1033.mail.sp2.yahoo.com with NNFMP; 05 Feb 2011 01:45:20 -0000 X-Yahoo-Newman-Id: 860518.84718.bm@omp1033.mail.sp2.yahoo.com Received: (qmail 14098 invoked from network); 5 Feb 2011 01:45:20 -0000 Received: from thunderfish.local (turners@96.231.128.4 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 04 Feb 2011 17:45:20 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 5MwWw1YVM1mk_Mlz8rz27oYPjUpfbRlfJ4aYKHysrnkjgVG U_JXbFdprAMhPLzxEqylyrCqBBRxqT2ncFKj60lZgtwc0pbluIDNk0gLuoH8 6DMYqbvmUB3WnQfuCKrtmhnZ0vHzj2mmvFr91wqBaIMcigqBfozrCUNFCIjn jhcZkKd1yBuRVlNCwqCOb_UmgTaYTSnA5AHxZEVcnIGJLbSE4xKx6AOvdIBs razmo3QHyKPiQkN.SOnQEnbTaDgKGUpQrZ2wGrndLqSwcW.D8C5zx0M82dNq Tjn.78MkgUBaSyCr8crSinSRc3S3yyCIzfQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4CABAE.8070401@ieca.com> Date: Fri, 04 Feb 2011 20:45:18 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D4BC5F7.6040109@po.ntts.co.jp> <8739o40x3b.fsf@latte.josefsson.org> In-Reply-To: <8739o40x3b.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Request for review: Camellia cipher suites for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 01:41:57 -0000 On 2/4/11 8:04 AM, Simon Josefsson wrote: > Satoru Kanno writes: > >> Folks, >> >> I've submitted "draft-kanno-tls-camellia-00". >> URL: http://www.ietf.org/internet-drafts/draft-kanno-tls-camellia-00.txt > > I cannot find an IPR statement when searching for that draft on the IETF > IPR Disclosure search page: > > https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=21179 > > Since Camellia is patented by NTT, I believe you need to submit an IPR > disclosure for this document. There is this: https://datatracker.ietf.org/ipr/41/ spt From n.mavrogiannopoulos@gmail.com Sat Feb 5 00:02:05 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87173A67DF for ; Sat, 5 Feb 2011 00:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6yFghUkWsF2 for ; Sat, 5 Feb 2011 00:02:05 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D37023A67AD for ; Sat, 5 Feb 2011 00:02:04 -0800 (PST) Received: by ewy8 with SMTP id 8so1774196ewy.31 for ; Sat, 05 Feb 2011 00:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=8MBbkE6Gg4GYBKAV9BZW/7ogjP5S0K52eMsQMiAH+iI=; b=V9+WHrrmbyx09Z/wRBpuYl0zXh0sm8AxhRDiCwsBnP82sAfNkeXkb8xIczvDR4l1jz fARYOZOxMue1CaL/l6NrdS9i1XbqXdkHq0j0Cihk0Uq0HJj93ThALoBzERifu+YavMlk XdIoONHLnxIJpnAHJ44hgBl/WRNBSDi6YvtSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=g4lgoMhrMFGmiGEx/bB9TME9QIBMwMLZeUtUC/ccRyOYwH7qodbLg2kYU7yjSSxuzJ 4q4v5PHIVuAU7LlB6GyklY3VgMMacovfhBBBHOId8MpkGEtTMFUT1nQxivTgoABChr91 zPC/ZX333iACCftfVfsnCG3YOADVDrHfFQB+0= Received: by 10.213.7.65 with SMTP id c1mr16285972ebc.96.1296893130915; Sat, 05 Feb 2011 00:05:30 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id b52sm1203416eei.7.2011.02.05.00.05.29 (version=SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 00:05:29 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D4D04C8.1090307@gnutls.org> Date: Sat, 05 Feb 2011 09:05:28 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 08:02:05 -0000 Hello, Are there any public servers implementing the AES-GCM (RFC5288) ciphersuites for TLS? regards, Nikos From rwilliams@certicom.com Mon Feb 7 03:32:52 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59F13A6DCE for ; Mon, 7 Feb 2011 03:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABfAkAiec5cv for ; Mon, 7 Feb 2011 03:32:51 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id AE9E93A6D9C for ; Mon, 7 Feb 2011 03:32:50 -0800 (PST) X-AuditID: 0a401fcb-b7c02ae0000009e2-91-4d4fd8668318 Received: from XHT109CNC.rim.net ( [10.65.12.218]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 34.7C.02530.668DF4D4; Mon, 7 Feb 2011 06:32:54 -0500 (EST) Received: from XCH117CNC.rim.net ([fe80::b8df:541f:9d85:9909]) by XHT109CNC.rim.net ([fe80::8412:4d9e:eb55:2c7b%11]) with mapi; Mon, 7 Feb 2011 06:32:53 -0500 From: Rob P Williams To: Nikos Mavrogiannopoulos , "tls@ietf.org" Date: Mon, 7 Feb 2011 06:32:52 -0500 Thread-Topic: [TLS] AES-GCM implementation Thread-Index: AcvFC3jKAkcgiDibQZW7hcShkw4BAwBrzheg Message-ID: <7C6BDB4BD9974646856544650C016B820562B8D8@XCH117CNC.rim.net> References: <4D4D04C8.1090307@gnutls.org> In-Reply-To: <4D4D04C8.1090307@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAZEXVOHb Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 11:32:53 -0000 Hi, You can confirm interop against tls.secg.org Thanks. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nikos= Mavrogiannopoulos Sent: Saturday, February 05, 2011 3:05 AM To: tls@ietf.org Subject: [TLS] AES-GCM implementation Hello, Are there any public servers implementing the AES-GCM (RFC5288) ciphersuites for TLS? regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From n.mavrogiannopoulos@gmail.com Mon Feb 7 04:50:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA163A6DED for ; Mon, 7 Feb 2011 04:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmuvf1Yrvxij for ; Mon, 7 Feb 2011 04:50:42 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 205983A68C0 for ; Mon, 7 Feb 2011 04:50:41 -0800 (PST) Received: by qwi2 with SMTP id 2so3666820qwi.31 for ; Mon, 07 Feb 2011 04:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=g2YVpJLXJyBqANQRAveSORBuZA5GabBWyZsS16tHlvM=; b=TsUiFa3Ybri/3QgQQn9CxpA8dDZ+AUIxzNP4LO9uYhQFLZk6GsTFyHOXvQeq1s93f8 0LQx8TsjCY7qrafF9N94IKzRE/fxZrbxRfIgEEYaWd2i+4oT0u5Vd1Y5zw57nvWHxxPd 0SVdaVkfYtYPDJ1t/AEJQ7aJYNj3vXxMTHEXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=pYlkaUSaozXmZ9uLZgHFUCbAvtEMY53RXpgnlXw9T00gTiA5PwkmkImbeyLS3DFuCT 5Gsz2QduDijGQ2O69Ak2YNxDoF4LKNWqcTgDhBjqxjp6Y118eJ6x2UUD0C1B7D6Q72dR Nmn1POzeYBuHPr3ij8G+ANrXUahHpyL+Nd3qE= Received: by 10.224.37.2 with SMTP id v2mr14254642qad.92.1297083045677; Mon, 07 Feb 2011 04:50:45 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id nb15sm2826754qcb.38.2011.02.07.04.50.43 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 04:50:44 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D4FEAA3.4070702@gnutls.org> Date: Mon, 07 Feb 2011 13:50:43 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Rob P Williams References: <4D4D04C8.1090307@gnutls.org> <7C6BDB4BD9974646856544650C016B820562B8D8@XCH117CNC.rim.net> In-Reply-To: <7C6BDB4BD9974646856544650C016B820562B8D8@XCH117CNC.rim.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 12:50:45 -0000 On 02/07/2011 12:32 PM, Rob P Williams wrote: > Hi, > > You can confirm interop against tls.secg.org Thank you. It seems we interoperate. regards, Nikos From Ron.Williams@us.ibm.com Mon Feb 7 15:04:26 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C739F3A6FBD for ; Mon, 7 Feb 2011 15:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHIqqwGUrh-i for ; Mon, 7 Feb 2011 15:04:26 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id F12E63A6FB7 for ; Mon, 7 Feb 2011 15:04:25 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p17Mo6Sf003670 for ; Mon, 7 Feb 2011 15:50:06 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p17N4ODO090282 for ; Mon, 7 Feb 2011 16:04:24 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p17N4Okt003071 for ; Mon, 7 Feb 2011 16:04:24 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p17N4N8X003030 for ; Mon, 7 Feb 2011 16:04:24 -0700 Auto-Submitted: auto-generated From: Ron Williams To: tls@ietf.org Message-ID: Date: Mon, 7 Feb 2011 16:04:23 -0700 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 02/07/2011 16:04:23 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF2A3DFED38218f9e8a93df938690918c08BBF2A3DFED3821" Content-Disposition: inline Subject: [TLS] AUTO: Ron Williams is out of the office (returning 02/11/2011) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:04:26 -0000 --0__=08BBF2A3DFED38218f9e8a93df938690918c08BBF2A3DFED3821 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 02/11/2011. Note: This is an automated response to your message "TLS Digest, Vol 7= 9, Issue 5" sent on 2/7/11 13:00:32. This is the only notification you will receive while this person is awa= y.= --0__=08BBF2A3DFED38218f9e8a93df938690918c08BBF2A3DFED3821 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 02/11/2011.




Note: This is an automated re= sponse to your message "TLS Digest, Vo= l 79, Issue 5" sent = on 2/7/11 13:00:32.

This is the only notification= you will receive while this person is away.= --0__=08BBF2A3DFED38218f9e8a93df938690918c08BBF2A3DFED3821-- From peter.robinson@rsa.com Mon Feb 7 17:57:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71ECC3A6FEF for ; Mon, 7 Feb 2011 17:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ox1Tt9TXnMy for ; Mon, 7 Feb 2011 17:57:30 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 36EE13A6FEE for ; Mon, 7 Feb 2011 17:57:29 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p181vYgx022158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 20:57:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 7 Feb 2011 20:57:26 -0500 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.221.56.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p181v2Dj006323; Mon, 7 Feb 2011 20:57:03 -0500 Received: from mx18a.corp.emc.com ([169.254.1.125]) by mxhub15.corp.emc.com ([128.221.56.104]) with mapi; Mon, 7 Feb 2011 20:57:02 -0500 From: To: , Date: Mon, 7 Feb 2011 20:57:00 -0500 Thread-Topic: [TLS] TLS 1.2 test clients? Thread-Index: AcvBZQgwm9Xbu67XRs6eHiDlEDowbQFzf4Xw Message-ID: References: <4D46E4D8.3090307@vpnc.org> In-Reply-To: <4D46E4D8.3090307@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [TLS] TLS 1.2 test clients? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 01:57:31 -0000 RSA BSAFE Share for JavaTM Platform supports TLS 1.2. You can download the = toolkit and samples from here: https://community.emc.com/docs/DOC-4741 The= re is a sample to show you how to create a TLS client which only support ce= rtain protocol versions. Peter ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUST= RALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul = Hoffman Sent: Tuesday, 1 February 2011 2:36 AM To: tls@ietf.org Subject: [TLS] TLS 1.2 test clients? Greetings again. I would like to test how servers react to a TLS client=20 that only does TLS 1.2. There are two browsers that can be put into this=20 state (IE under Win 7, and Opera), but neither give very good=20 diagnostics when a failure occurs. Further, Wireshark doesn't give good=20 dumps for TLS 1.2. Thus, if anyone here has a TLS 1.2 client that has reasonable debugging=20 of the TLS handshake and can do trivial HTTP (just send a "GET /" and=20 receive the response would be fine) after setting up a tunnel, I'd=20 greatly appreciate it. Also, if anyone has a Wireshark plugin (?) that=20 brings its TLS decoding up to 1.2, that would be great as well. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From ekr@rtfm.com Tue Feb 8 12:58:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CD43A6857; Tue, 8 Feb 2011 12:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwX5-+4TBvBO; Tue, 8 Feb 2011 12:58:32 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 79D503A684C; Tue, 8 Feb 2011 12:58:32 -0800 (PST) Received: by yie19 with SMTP id 19so2791594yie.31 for ; Tue, 08 Feb 2011 12:58:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.68.4 with SMTP id q4mr460212aga.54.1297198719438; Tue, 08 Feb 2011 12:58:39 -0800 (PST) Received: by 10.90.117.9 with HTTP; Tue, 8 Feb 2011 12:58:39 -0800 (PST) In-Reply-To: References: <20101130132359.32419.3777.idtracker@localhost> Date: Tue, 8 Feb 2011 12:58:39 -0800 Message-ID: From: Eric Rescorla To: =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, ietf@ietf.org, Pekka Savola , tls-chairs@tools.ietf.org, draft-ietf-tls-rfc4347-bis@tools.ietf.org Subject: Re: [TLS] Last Call: (Datagram Transport Layer Security version 1.2) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:58:33 -0000 On Mon, Dec 20, 2010 at 11:01 AM, Juho V=E4h=E4-Herttua wro= te: > On 20.12.2010, at 15.15, Pekka Savola wrote: >> 3.2.3. Message Size >> >> =A0 TLS and DTLS handshake messages can be quite large (in theory up to >> =A0 2^24-1 bytes, in practice many kilobytes). =A0By contrast, UDP >> =A0 datagrams are often limited to <1500 bytes if fragmentation is not >> =A0 desired. =A0In order to compensate for this limitation, each DTLS >> =A0 handshake message may be fragmented over several DTLS records. =A0Ea= ch >> =A0 DTLS handshake message contains both a fragment offset and a fragmen= t >> =A0 length. >> >> 4.1.1. Transport Layer Mapping >> >> =A0 Each DTLS record MUST fit within a single datagram. =A0In order to >> =A0 avoid fragmentation, clients of the DTLS record layer SHOULD attempt >> =A0 to size records so that they fit within any PMTU estimates obtained >> =A0 from the record layer. >> >> ... these seem somewhat contradictory. =A0Maybe I'm missing something. = =A0The >> latter seems to be saying that DTLS implementations should try to avoid = IP >> fragmentation, but the former seems to imply that it's de-facto mode of >> operation. > > These are not contradictory. If a handshake message size and record heade= r don't fit inside single datagram, it should be fragmented into several sm= all handshake messages and each of these is put into a separate DTLS record= . The resulting DTLS record after encryption should not exceed the maximum = UDP (or DCCP or whatever) datagram size and therefore doesn't need IP level= fragmentation. > > I think what you "missed" was simply the difference of IP level fragmenta= tion and DTLS handshake protocol level fragmentation. I think that is a lot of the issue here. We probably don't distinguish these clearly. Given that I don't want to change terminology now I suggest we just say "DTLS fragmentation" and "IP fragmentation". It's clunky but serviceable. WRT to the ICMP issue, my take on this is that ICMP Isn't reliable both because of filtering and that it implies connected sockets. So, the application needs to be able to determine PMTU even if it never gets any kind of error indication. However, I agree that if the stack does get an explicit error it MUST adjust. The rest of Pekka's suggestions make sense and I should be able to implement them. -Ekr From turners@ieca.com Tue Feb 8 13:42:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8FD3A689F for ; Tue, 8 Feb 2011 13:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5c2GkDofSZH for ; Tue, 8 Feb 2011 13:42:38 -0800 (PST) Received: from nm13.bullet.mail.sp2.yahoo.com (nm13.bullet.mail.sp2.yahoo.com [98.139.91.83]) by core3.amsl.com (Postfix) with SMTP id 8BB623A6875 for ; Tue, 8 Feb 2011 13:42:37 -0800 (PST) Received: from [98.139.91.66] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 08 Feb 2011 21:42:43 -0000 Received: from [98.139.91.23] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 08 Feb 2011 21:42:43 -0000 Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 08 Feb 2011 21:42:43 -0000 X-Yahoo-Newman-Id: 149241.81735.bm@omp1023.mail.sp2.yahoo.com Received: (qmail 17064 invoked from network); 8 Feb 2011 21:42:43 -0000 Received: from thunderfish.local (turners@71.191.10.60 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 08 Feb 2011 13:42:42 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: OWwwJecVM1mxSjm7NIiHlylLosqbUHy0t6MakSIKrYegDz6 aUXDXKE.kcYmmOdGpe90F31U.mx8QVg_o49qkAzxVgi5UWh5mIQqC1LqbzjO zeTPQmbfVFlqqJ3j9_fkfVDd0DusKnDoggjN8Xjx1P25ubGGZR5FYe6vE.EU Bpvhfzw9wLmLabYxDLT5DJtvfxoFY3Mg6eB1s6UGkWEKKqrF1eggOfreYN2n F1Sj0DiGzCFTMTaFopkMsYPXiiUYJRw7XT0iZWqHZBIg7of3E2887n0y1VBp _uChB8aH3yiNPYJz.TdXnKEuDZxdnwvOYPQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D51B8D1.4090209@ieca.com> Date: Tue, 08 Feb 2011 16:42:41 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] Fwd: Additional Last Call: (Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:42:38 -0000 Please note the following last call. spt -------- Original Message -------- Subject: Additional Last Call: (Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)) to Informational RFC Date: Tue, 08 Feb 2011 13:40:53 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)' as an Informational RFC Last calls were earlier issued on version -01 of this document and this document was approved by the IESG on 2011-01-25. Subsequently, the authors noted that the draft should have included the following two cipher suites: TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384 This Last Call requests comments on the addition of these two suites to this draft. The intent is to aid implementers by keeping all the aria cipher suites in one document. 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 2011-03-08. 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://datatracker.ietf.org/doc/draft-nsri-tls-aria/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-nsri-tls-aria/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From fweimer@bfk.de Wed Feb 9 00:33:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3D03A6941 for ; Wed, 9 Feb 2011 00:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TPQayYK7Y1x for ; Wed, 9 Feb 2011 00:32:58 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id BDFFD3A6885 for ; Wed, 9 Feb 2011 00:32:57 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pn5Tz-0007lU-2S; Wed, 09 Feb 2011 08:33:03 +0000 Received: by bfk.de with local id 1Pn5Ty-00027Y-VK; Wed, 09 Feb 2011 08:33:02 +0000 To: "t.petch" References: <20110127114502.24680.73782.idtracker@localhost> <8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> From: Florian Weimer Date: Wed, 09 Feb 2011 08:33:02 +0000 In-Reply-To: <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> (t. petch's message of "Tue\, 1 Feb 2011 10\:23\:25 +0100") Message-ID: <82wrl9zjy9.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 08:33:00 -0000 * t. petch: > The intention of the sentence in the ID is that you can not send > multiple HeartbeatRequest out. But you actually can because the transport layer may duplicate datagrams. In particular, recipients MUST be prepared to deal with such duplicates. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Michael.Tuexen@lurchi.franken.de Wed Feb 9 03:01:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CD93A67DF for ; Wed, 9 Feb 2011 03:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBsAz3luaZnR for ; Wed, 9 Feb 2011 03:01:30 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id E8A9E3A6980 for ; Wed, 9 Feb 2011 03:01:29 -0800 (PST) Received: from [212.201.127.66] (unknown [212.201.127.66]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1452D1C0C0BCE; Wed, 9 Feb 2011 12:01:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <82wrl9zjy9.fsf@mid.bfk.de> Date: Wed, 9 Feb 2011 12:01:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FF8EA81-FDC9-48A2-BE2B-2937095CF5C7@lurchi.franken.de> References: <20110127114502.24680.73782.idtracker@localhost> <8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> <82wrl9zjy9.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 11:01:31 -0000 On Feb 9, 2011, at 9:33 AM, Florian Weimer wrote: > * t. petch: >=20 >> The intention of the sentence in the ID is that you can not send >> multiple HeartbeatRequest out. >=20 > But you actually can because the transport layer may duplicate > datagrams. In particular, recipients MUST be prepared to deal with > such duplicates. If the transport layer does (like TCP or SCTP), it has a CC. The intention of allowing only one outstanding HeartbeatRequest is a very simple form of CC. Best regards Michael >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 >=20 From fweimer@bfk.de Wed Feb 9 03:03:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9469A3A6981 for ; Wed, 9 Feb 2011 03:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgk5GK74166f for ; Wed, 9 Feb 2011 03:03:28 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id CF0533A697A for ; Wed, 9 Feb 2011 03:03:26 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pn7pe-0006Dq-1X; Wed, 09 Feb 2011 11:03:34 +0000 Received: by bfk.de with local id 1Pn7pd-0003K6-TG; Wed, 09 Feb 2011 11:03:33 +0000 To: Michael =?iso-8859-1?Q?T=FCxen?= References: <20110127114502.24680.73782.idtracker@localhost> <8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> <82wrl9zjy9.fsf@mid.bfk.de> <0FF8EA81-FDC9-48A2-BE2B-2937095CF5C7@lurchi.franken.de> From: Florian Weimer Date: Wed, 09 Feb 2011 11:03:33 +0000 In-Reply-To: <0FF8EA81-FDC9-48A2-BE2B-2937095CF5C7@lurchi.franken.de> ("Michael =?iso-8859-1?Q?T=FCxen=22's?= message of "Wed\, 9 Feb 2011 12\:01\:36 +0100") Message-ID: <82sjvxxyey.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 11:03:28 -0000 * Michael T=FCxen: > On Feb 9, 2011, at 9:33 AM, Florian Weimer wrote: > >> * t. petch: >>=20 >>> The intention of the sentence in the ID is that you can not send >>> multiple HeartbeatRequest out. >>=20 >> But you actually can because the transport layer may duplicate >> datagrams. In particular, recipients MUST be prepared to deal with >> such duplicates. > If the transport layer does (like TCP or SCTP), it has a CC. Duplicates can result from other phenomena, not just deliberate retransmission. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon@josefsson.org Wed Feb 9 12:46:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3709A3A672E for ; Wed, 9 Feb 2011 12:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YgDAakWG24w for ; Wed, 9 Feb 2011 12:45:58 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 0383C3A67AA for ; Wed, 9 Feb 2011 12:45:57 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p19Kk19u028311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 9 Feb 2011 21:46:02 +0100 X-Hashcash: 1:22:110209:tls@ietf.org::E46tBxnWkmGMwhY1:DP0s From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 09 Feb 2011 21:46:01 +0100 Message-ID: <87r5bhvsvq.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Subject: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:46:02 -0000 All, I have been updating the following Wikipedia article with information on different TLS implementations and their features. Finding the information by looking at source code is time-consuming (and error prone), but I think it is alreadyinteresting in the way that it shows that no TLS implementation supports all protocol features. If you are so inclined, please help to improve the page with useful information. And by all means, fix any mistakes on it. http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations /Simon From Michael.Tuexen@lurchi.franken.de Wed Feb 9 14:54:12 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B883A67F3 for ; Wed, 9 Feb 2011 14:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWEitmNyd9gX for ; Wed, 9 Feb 2011 14:54:10 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id A2DCB3A672E for ; Wed, 9 Feb 2011 14:54:09 -0800 (PST) Received: from [192.168.1.113] (p508FA862.dip.t-dialin.net [80.143.168.98]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 309F81C0C0BD8; Wed, 9 Feb 2011 23:54:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <82sjvxxyey.fsf@mid.bfk.de> Date: Wed, 9 Feb 2011 23:54:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110127114502.24680.73782.idtracker@localhost> <8239oeqz6c.fsf@mid.bfk.de> <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> <00cf01cbc1f4$dc962700$4001a8c0@gateway.2wire.net> <82wrl9zjy9.fsf@mid.bfk.de> <0FF8EA81-FDC9-48A2-BE2B-2937095CF5C7@lurchi.franken.de> <82sjvxxyey.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:54:13 -0000 On Feb 9, 2011, at 12:03 PM, Florian Weimer wrote: > * Michael T=FCxen: >=20 >> On Feb 9, 2011, at 9:33 AM, Florian Weimer wrote: >>=20 >>> * t. petch: >>>=20 >>>> The intention of the sentence in the ID is that you can not send >>>> multiple HeartbeatRequest out. >>>=20 >>> But you actually can because the transport layer may duplicate >>> datagrams. In particular, recipients MUST be prepared to deal with >>> such duplicates. >=20 >> If the transport layer does (like TCP or SCTP), it has a CC. >=20 > Duplicates can result from other phenomena, not just deliberate > retransmission. What is the point here? The rule is to protect the network. The receiver has to handle any kind of duplication, but that is not the point here. I'm not sure what you are suggesting. Best regards Michael >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 >=20 From chris.newman@oracle.com Wed Feb 9 18:12:15 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DBD3A682D; Wed, 9 Feb 2011 18:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.05 X-Spam-Level: X-Spam-Status: No, score=-104.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVW+bn-t9ZdI; Wed, 9 Feb 2011 18:12:14 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 5756C3A6826; Wed, 9 Feb 2011 18:12:14 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p1A2CNED010121; Thu, 10 Feb 2011 02:12:24 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id p1A2CNAY002395; Wed, 9 Feb 2011 18:12:23 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPSA id <0LGD00C4NQ4JD700@gotmail.sfbay.sun.com>; Wed, 09 Feb 2011 18:12:22 -0800 (PST) Date: Wed, 09 Feb 2011 18:12:18 -0800 From: Chris Newman To: Magnus Westerlund , tls@ietf.org Message-id: In-reply-to: <4CD76B1B.5030308@ericsson.com> References: <4CD76B1B.5030308@ericsson.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-transfer-encoding: quoted-printable Cc: tsvwg , Paul Hoffman Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:12:15 -0000 I know I'm very late on this topic, but my position differs from others so=20 I'll comment. I can not deny that separate-port for SSL is simpler to implement on the=20 server side (having done both). Since the odds of security bugs increases=20 with the amount of code, I must conclude that separate-port SSL is more=20 secure for _implementers_ and _implementations_ for that reason alone. However, I believe STARTTLS is more secure for _operators_ and=20 _administrators_. The separate port model creates an illusion that there is = a "secure" and "insecure" variant of the protocol and that a single=20 firewall setting magically makes the application secure. In general, this=20 is not true. Most servers have several security settings and the default=20 settings have to compromise between common practice, secure-by-default=20 practice, deployability, management complexity and usability. There is, in=20 general, no way to make a server installation secure for a given site other = than to understand the security settings that server provides and set them=20 properly. A protocol that uses STARTTLS thus has the advantage of forcing the=20 administrator/operator to look at the server's security settings to make=20 the installation secure, thus increasing the odds of success relative to=20 the separate-port model where an administrator might falsely assume they're = done after blocking the non-SSL port. While I think the judgment call is close for separate-port-SSL-vs-STARTTLS, = I prefer STARTTLS weighing all the factors. And for the record I'm responsible for TLS integration into a server=20 product and maintain all the relevant code and find STARTTLS maintenance=20 annoying. I'm also author of RFC 2595, so perhaps that balances out my bias = as an implementer. ;-) It's also my opinion that a high quality client should use a "latched"=20 model by default. If the client ever sees "STARTTLS" advertised and=20 negotiates it successfully, the client records the fact in a local=20 operations file that it used STARTTLS with server X. Subsequent to that it=20 will require STARTTLS with server X and not back off. I will note that=20 implementation strategy is simpler with the STARTTLS model than with the=20 separate port model. As an aside, there is no interoperable specification for use of TLS client=20 certificate authentication with the "pops" protocol (does it start in=20 not-authenticated state and require an AUTH EXTERNAL, or does it start in=20 authenticated state -- no way to distinguish the two cases). However, use=20 of TLS client certificate authentication with POP+STLS according to written = rules in RFC 2595 does interoperate. - Chris --On November 8, 2010 11:14:35 +0800 Magnus Westerlund=20 wrote: > TLS experts, > > There currently a WG last call ongoing in on the IANA Procedures for the > Management of the Service Name and Transport Protocol Port Number > Registry update document. > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ > > A WG last call comment on this document was raised by Paul Hoffman: > http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html > > My summary of that comment is that STARTTLS for SMTP (RFC 3207) has > shown to have some security issues, be complexer to implement than using > two ports and thus less popular. Thus the registration rules should be > less restrictive in assigning an additional port for TLS version of > services/applications/protocols. > > The downside of less restrictive port allocation rules is that the port > space will be consumed at a higher rate. Thus there is need to determine > what is the most suitable trade-off here. > > Clearly if the security issues are serious when one multiplex TLS and > non-secured version of the protocol on the same port we must allow such > port allocations. However if the issues are minor and the primarily > issue is implementation complexity then saving the limited port space is > probably more important. > > Your input into these questions would be very appreciated. > > Thanks > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nico@cryptonector.com Wed Feb 9 18:25:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23BE3A680C; Wed, 9 Feb 2011 18:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM+HQMHYv3XJ; Wed, 9 Feb 2011 18:25:32 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id EA9963A67FA; Wed, 9 Feb 2011 18:25:31 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 8E0736B0073; Wed, 9 Feb 2011 18:25:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=AeFtmH35WiEtK2PJpAsLy 3YXsRltHaXRR5BqRZdkb8g8njR9iFcj+5k8ezhMRcOpE9A2F1I39sQBGr66mwSUF lz5SBfW0NH48Ju7A/NbWRKFwU8IeQh2FafoCsoGLlhnPxVTQjGRTAb/9qjP5cqNp 2SmRZ+vwEJvN0Z9q7ZlOII= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vDkjkl0kvw1VKvuxPiX3 S346h/g=; b=VvNWTDtbVTTTzY99Wa0yRarmCZGr28lQR9j9cJmO4HHOLD/ub/tH 15UTE40gza4P4amsyfjd2mWTrxWDV8DNJpIEBpq3i6jFN7u1RDRThYP14RUcDkmW vJtXdi9jezqzamNIjAvRXKSmbRsN4iboEBUXeE3fyQ+xtQCmBcbaERE= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 55B736B0070; Wed, 9 Feb 2011 18:25:42 -0800 (PST) Received: by gxk27 with SMTP id 27so416189gxk.31 for ; Wed, 09 Feb 2011 18:25:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.32.16 with SMTP id f16mr2083595agf.202.1297304741429; Wed, 09 Feb 2011 18:25:41 -0800 (PST) Received: by 10.90.103.11 with HTTP; Wed, 9 Feb 2011 18:25:41 -0800 (PST) In-Reply-To: References: <4CD76B1B.5030308@ericsson.com> Date: Wed, 9 Feb 2011 20:25:41 -0600 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , tls@ietf.org, tsvwg Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:25:32 -0000 On Wed, Feb 9, 2011 at 8:12 PM, Chris Newman wrote: > I know I'm very late on this topic, but my position differs from others so > I'll comment. +1 But I'll also add that it's not necessarily harder for implementers to manage StartTLS with isolation. I realize that implementers have screwed this up in the past, but there is hope that we can learn, and even develop institutional memory -- if not we have other problems. Nico -- From demoss.matt@gmail.com Wed Feb 9 19:35:49 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D770A3A681A; Wed, 9 Feb 2011 19:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FIqncw6V2zk; Wed, 9 Feb 2011 19:35:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8B2FB3A680C; Wed, 9 Feb 2011 19:35:48 -0800 (PST) Received: by fxm9 with SMTP id 9so1023294fxm.31 for ; Wed, 09 Feb 2011 19:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MlAPwYKSyklW3vhixBNic+syWZ2m22ql6WBme7VJxsM=; b=NvMQQvqvS8ZOiMxZnarlkFH1D74k01sD6vPZBpeRBGJDXaWIbw3PQ8VJU1TABt+OWf hnIX1oUgeCzocgV/O0vLDxSNrTDnk0mE9cCDEU80WVq4OvSipPW8LyhMQ36BqgDdGfmg c5FXR6eg6pmnZaMsdmoHiRMgTz0A50SYjGY1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kAtJYV9VPJyV2PP2hgEvqmd2t48YfybqXytevqu8xMz5v7OIApGClSGW3wW3ajYmR0 gvT852xckqv++IaiTlTJx7qLVPZRVsq/f+Wx6fYkzaRFtxNEme43FhJK5whqmfZZL/4R 9ma5Kk1r1jnPkKqQ96aqIybyBKaA335oogLVY= MIME-Version: 1.0 Received: by 10.223.93.139 with SMTP id v11mr7347101fam.132.1297308959118; Wed, 09 Feb 2011 19:35:59 -0800 (PST) Received: by 10.223.37.218 with HTTP; Wed, 9 Feb 2011 19:35:59 -0800 (PST) In-Reply-To: References: <4CD76B1B.5030308@ericsson.com> Date: Wed, 9 Feb 2011 22:35:59 -0500 Message-ID: From: Matt DeMoss To: Chris Newman Content-Type: multipart/alternative; boundary=20cf3054a541ac1662049be54709 Cc: tls@ietf.org, tsvwg Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 03:35:50 -0000 --20cf3054a541ac1662049be54709 Content-Type: text/plain; charset=ISO-8859-1 > > > I can not deny that separate-port for SSL is simpler to implement on the > server side (having done both). Since the odds of security bugs increases > with the amount of code, I must conclude that separate-port SSL is more > secure for _implementers_ and _implementations_ for that reason alone. > [...] > As an aside, there is no interoperable specification for use of TLS client > certificate authentication with the "pops" protocol (does it start in > not-authenticated state and require an AUTH EXTERNAL, or does it start in > authenticated state -- no way to distinguish the two cases). However, use of > TLS client certificate authentication with POP+STLS according to written > rules in RFC 2595 does interoperate. > > I think the argument for protecting complex code paths from exposure is much stronger in the case of required client certificate authentication where unauthorized users may be able to exercise fewer paths. There are also some cases where it seems like you get client-cert-auth 'for free' as a side effect of sitting on top of a TLS implementation that supports client auth. MS Outlook seems to like this with LDAPS: I doubt it was a conscious choice on their part to include that mode of authentication. The separate port model also makes it easier to terminate the TLS tunnel at a simple load balancing or TLS accelerating device that knows nothing of the underlying protocol. --20cf3054a541ac1662049be54709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I can not deny that separate-port for SSL is simpler to implement on the se= rver side (having done both). Since the odds of security bugs increases wit= h the amount of code, I must conclude that separate-port SSL is more secure= for _implementers_ and _implementations_ for that reason alone.
=A0[...]
As an aside= , there is no interoperable specification for use of TLS client certificate= authentication with the "pops" protocol (does it start in not-au= thenticated state and require an AUTH EXTERNAL, or does it start in authent= icated state -- no way to distinguish the two cases). However, use of TLS c= lient certificate authentication with POP+STLS according to written rules i= n RFC 2595 does interoperate.


I think the argument for protecting co= mplex code paths from exposure is much stronger in the case of required cli= ent certificate authentication where unauthorized users may be able to exer= cise fewer paths.

There are also some cases where it seems like you get c= lient-cert-auth 'for free' as a side effect of sitting on top of a = TLS implementation that supports client auth. MS Outlook seems to like this= with LDAPS: I doubt it was a=A0conscious=A0choice on their part to include= that mode of authentication.

The=A0separate=A0port model also makes it easier to ter= minate the TLS tunnel at a simple load balancing or TLS accelerating device= that knows nothing of the underlying protocol.
--20cf3054a541ac1662049be54709-- From ynir@checkpoint.com Wed Feb 9 23:19:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFDA3A68C5; Wed, 9 Feb 2011 23:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo+th-pbLZOG; Wed, 9 Feb 2011 23:19:09 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 974673A68A9; Wed, 9 Feb 2011 23:19:08 -0800 (PST) X-CheckPoint: {4D539177-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1A7JINS006850; Thu, 10 Feb 2011 09:19:18 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Feb 2011 09:19:18 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 10 Feb 2011 09:19:18 +0200 From: Yoav Nir To: Chris Newman Date: Thu, 10 Feb 2011 09:19:15 +0200 Thread-Topic: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) Thread-Index: AcvI8tQluol13oALTNiL9FBwZWuVOQ== Message-ID: References: <4CD76B1B.5030308@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "tls@ietf.org" , tsvwg Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:19:10 -0000 I have to disagree with this. On Feb 10, 2011, at 4:12 AM, Chris Newman wrote: > I know I'm very late on this topic, but my position differs from others s= o=20 > I'll comment. >=20 > I can not deny that separate-port for SSL is simpler to implement on the= =20 > server side (having done both). Since the odds of security bugs increases= =20 > with the amount of code, I must conclude that separate-port SSL is more=20 > secure for _implementers_ and _implementations_ for that reason alone. >=20 > However, I believe STARTTLS is more secure for _operators_ and=20 > _administrators_. The separate port model creates an illusion that there = is=20 > a "secure" and "insecure" variant of the protocol and that a single=20 > firewall setting magically makes the application secure. In general, this= =20 > is not true. Most servers have several security settings and the default= =20 > settings have to compromise between common practice, secure-by-default=20 > practice, deployability, management complexity and usability. There is, i= n=20 > general, no way to make a server installation secure for a given site oth= er=20 > than to understand the security settings that server provides and set the= m=20 > properly. >=20 > A protocol that uses STARTTLS thus has the advantage of forcing the=20 > administrator/operator to look at the server's security settings to make= =20 > the installation secure, thus increasing the odds of success relative to= =20 > the separate-port model where an administrator might falsely assume they'= re=20 > done after blocking the non-SSL port. I think this is a recipe for failure. What you're saying here, is that by u= sing separate ports, you cannot use the firewall to prevent non-secure conn= ections and this forces the administrator to configure the server properly. There are several things wrong with this: 1. It does not force the administrator to configure the server properly. At= best, it forces them to find the "force SSL" checkbox and check it. That h= as pretty much the same effect as forcing this on the firewall. Some admini= strators will use any opportunity to configure the server wrong. 2. You underestimate firewalls. Modern firewalls can examine connections an= d cut them off if STARTTLS is not initiated in time. So the administrator s= till has the option of "fixing it in the firewall". In short, you can't force administrators to do the right thing. Ever.=20 From n.mavrogiannopoulos@gmail.com Thu Feb 10 00:11:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C993A69B7 for ; Thu, 10 Feb 2011 00:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqEazni7lgQg for ; Thu, 10 Feb 2011 00:11:44 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id F36D73A697C for ; Thu, 10 Feb 2011 00:11:43 -0800 (PST) Received: by wwi17 with SMTP id 17so2744286wwi.1 for ; Thu, 10 Feb 2011 00:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=WkF3V4+c0S49ALylZc2mvTAd6asHSf2BKrOYiACbDMw=; b=ZDxeAh4QEi2W0pOVv5UwOmBh/kMkzLLjNCXXKD//a8jDaHTc1XgNjNZ0wqTqLvJXd/ 2jPo8PFEETSz/f+TQ/RE7paU6rh9vZaNua41Wo/tgAxm8jVR6U9NpDs5ozbeKdblqVmc vw5tokrq/K4QNHO+XZ9n/3U14aBGff1GpIXkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Tevw9nNMOKPNhtq795VszgE3XH028yg5g5OuZvtjQs9LIE3slgTVyALxO18k++aI2i EJw29D+DhKsO2F7aKfM11jQWi1yewjs8itJN7+rgiQz2WG/sdCefJlAxed6asqH686m2 +DblYeTeJgTlqPP34onIeCuiDrpHHkTREq2Qc= Received: by 10.227.141.201 with SMTP id n9mr3968858wbu.33.1297325514909; Thu, 10 Feb 2011 00:11:54 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id u9sm1027070wbg.6.2011.02.10.00.11.53 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Feb 2011 00:11:53 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D539DC8.9070106@gnutls.org> Date: Thu, 10 Feb 2011 09:11:52 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:11:45 -0000 Hello, According to FIPS-186-3 the DSA algorithm might be used with hashes other than SHA-1. Moreover it mentions: "A hash function that provides a lower security strength than the (L, N) pair ordinarily should not be used, since this would reduce the security strength of the digital signature process to a level no greater than that provided by the hash function." So what I understand from that is for the parameters discussed in the document the SHA variants allowed are: L = 1024, N = 160: SHA-1 or better L = 2048, N = 224: SHA-224 or better L = 2048, N = 256: SHA-256 or better L = 3072, N = 256: SHA-256 or better How does this apply to TLS 1.0 and 1.1 messages "Server Key Exchange" and "Certificate verify" that sign the handshake data? How is the peer going to understand which hash is being used? For TLS 1.2 I suppose that the hash being negotiated by the signature algorithm extension will be used, and if it is larger than N, then it will be truncated. So is my understanding of TLS 1.2 negotiation for DSA correct? How do you solved the issue in TLS < 1.2? regards, Nikos From ynir@checkpoint.com Thu Feb 10 01:33:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6483A69F7 for ; Thu, 10 Feb 2011 01:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-WoN-fVsnQh for ; Thu, 10 Feb 2011 01:33:39 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 5B3203A6966 for ; Thu, 10 Feb 2011 01:33:39 -0800 (PST) X-CheckPoint: {4D53B0FE-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1A9XnwT027370; Thu, 10 Feb 2011 11:33:49 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Feb 2011 11:33:49 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 10 Feb 2011 11:33:49 +0200 From: Yoav Nir To: Simon Josefsson Date: Thu, 10 Feb 2011 11:33:51 +0200 Thread-Topic: [TLS] Wikipedia TLS Comparison page Thread-Index: AcvJBZ7Bc5lGqrnkQmqrE4s6Tl8GcQ== Message-ID: <5D2E8B79-1ABF-42A2-BCBD-941DB48365F7@checkpoint.com> References: <87r5bhvsvq.fsf@latte.josefsson.org> In-Reply-To: <87r5bhvsvq.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 09:33:41 -0000 Nice.=20 I've added some of the data about Microsoft's library; I called it SChannel= , because that's what it says in MSDN. Hopefully, somebody who knows better= will update the page with the missing info. On Feb 9, 2011, at 10:46 PM, Simon Josefsson wrote: > All, >=20 > I have been updating the following Wikipedia article with information on > different TLS implementations and their features. Finding the > information by looking at source code is time-consuming (and error > prone), but I think it is alreadyinteresting in the way that it shows > that no TLS implementation supports all protocol features. If you are > so inclined, please help to improve the page with useful information. > And by all means, fix any mistakes on it. >=20 > http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations >=20 > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From mrex@sap.com Thu Feb 10 05:56:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E866E3A6997 for ; Thu, 10 Feb 2011 05:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tmqQ3NYOejH for ; Thu, 10 Feb 2011 05:56:22 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id DC20C3A69AA for ; Thu, 10 Feb 2011 05:56:21 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1ADuQtF021886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 14:56:31 +0100 (MET) From: Martin Rex Message-Id: <201102101356.p1ADuPOp010592@fs4113.wdf.sap.corp> To: Michael.Tuexen@lurchi.franken.de (=?iso-8859-1?Q?Michael_T=FCxen?=) Date: Thu, 10 Feb 2011 14:56:25 +0100 (MET) In-Reply-To: from "=?iso-8859-1?Q?Michael_T=FCxen?=" at Feb 9, 11 11:54:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:56:23 -0000 =?iso-8859-1?Q?Michael_T=FCxen?= wrote: > > >>> > >>>> The intention of the sentence in the ID is that you can not send > >>>> multiple HeartbeatRequest out. > > > > Duplicates can result from other phenomena, not just deliberate > > retransmission. > > What is the point here? The rule is to protect the network. > The receiver has to handle any kind of duplication, but that > is not the point here. An over-simplified statement like There MUST NOT be more than one HeartbeatRequest message in flight at a time. is inappropiate for the stated purpose. This single statement does not differentiate between compliant behaviour for the sender and compliant behaviour for the receiver. If it is necessary for the _receiver_ to handle duplicates gracefully then this _must_ be spelled out seperately. As it is, the wording of the spec implies that the receiver of duplicated HeartbeatRequest messages needs to abort the connection with a fatal error in order to comply with the specification. -Martin From mrex@sap.com Thu Feb 10 06:03:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFC03A6983 for ; Thu, 10 Feb 2011 06:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTd9nF0O6hWf for ; Thu, 10 Feb 2011 06:03:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 16D8E3A694F for ; Thu, 10 Feb 2011 06:03:39 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1AE3dds022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 15:03:39 +0100 (MET) From: Martin Rex Message-Id: <201102101403.p1AE3dBn010841@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Feb 2011 15:03:39 +0100 (MET) In-Reply-To: <4D539DC8.9070106@gnutls.org> from "Nikos Mavrogiannopoulos" at Feb 10, 11 09:11:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 14:03:41 -0000 Nikos Mavrogiannopoulos wrote: > > According to FIPS-186-3 the DSA algorithm might > be used with hashes other than SHA-1. Moreover > it mentions: > "A hash function that provides a lower security strength than the (L, N) > pair ordinarily should not be used, since this would reduce the > security strength of the digital signature process to a level no greater > than that provided by the hash function." > > So what I understand from that is for the parameters > discussed in the document the SHA variants allowed are: > > L = 1024, N = 160: SHA-1 or better > L = 2048, N = 224: SHA-224 or better > L = 2048, N = 256: SHA-256 or better > L = 3072, N = 256: SHA-256 or better > > How does this apply to TLS 1.0 and 1.1 messages > "Server Key Exchange" and "Certificate verify" > that sign the handshake data? How is the peer > going to understand which hash is being used? By looking at the AlgId parameters of the DSA public key that is involved in the signature operation. The public prime q, whose length (in bits) is described by the Parameter N above, is part of the AlgId Parameters of that DSA public key. (The L refers to the length (in bits) of the public prime p, also part of the AlgId Parameters). -Martin From fweimer@bfk.de Thu Feb 10 07:02:55 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A144B3A6969 for ; Thu, 10 Feb 2011 07:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p+fh4QuK9Ne for ; Thu, 10 Feb 2011 07:02:54 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 94F743A68D4 for ; Thu, 10 Feb 2011 07:02:53 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PnY2x-0008BO-9H; Thu, 10 Feb 2011 15:03:03 +0000 Received: by bfk.de with local id 1PnXcZ-00043D-9X; Thu, 10 Feb 2011 14:35:49 +0000 To: mrex@sap.com References: <201102101356.p1ADuPOp010592@fs4113.wdf.sap.corp> From: Florian Weimer Date: Thu, 10 Feb 2011 14:35:45 +0000 In-Reply-To: <201102101356.p1ADuPOp010592@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu\, 10 Feb 2011 14\:56\:25 +0100 \(MET\)") Message-ID: <82wrl8rm7y.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:02:55 -0000 * Martin Rex: > This single statement does not differentiate between compliant behaviour > for the sender and compliant behaviour for the receiver. > If it is necessary for the _receiver_ to handle duplicates gracefully > then this _must_ be spelled out seperately. > > As it is, the wording of the spec implies that the receiver of duplicated > HeartbeatRequest messages needs to abort the connection with a > fatal error in order to comply with the specification. Thanks. This is my concern as well. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From n.mavrogiannopoulos@gmail.com Thu Feb 10 07:03:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB1D3A69C5 for ; Thu, 10 Feb 2011 07:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDTusnwyzb09 for ; Thu, 10 Feb 2011 07:03:12 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id EF1053A69DC for ; Thu, 10 Feb 2011 07:03:11 -0800 (PST) Received: by qyj19 with SMTP id 19so1135841qyj.10 for ; Thu, 10 Feb 2011 07:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gAUhUqaXAm0kGxykHxLe54mcpOfHTaCTvA6qrin5/Yo=; b=nt+WNtxUczQmlBmWxe44jiGiZvuCRbjW07x/7qWdst1+8P6bO39PJ7uhSkpS1HkyC4 ugzXh4SREQYgcbZ8wi1Brrs+QYmh7wzFEdE4ohWYE02C2sjW1cRq9TPN5DKJH9QH0lH/ EU0UW8plrDtHhA8CXhc1MJoVYzx8zoNYNoUKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=KWq2sRIfKZPySfmbqQhV2zUbnftKkXin24ebjYJqwgqbUN4vmcefLmTaZXdaCbZssk U3hHI7eJVskIfIbn9IpEA0xBQAy3SeAgj5KKz7Y97H8DPOUn+AoSNFre5iVOdjQjHiCS 62LW+/4+Y15IAhFIPTYqi+KtveObgii7drfLk= MIME-Version: 1.0 Received: by 10.224.67.142 with SMTP id r14mr17454187qai.166.1297350203860; Thu, 10 Feb 2011 07:03:23 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 10 Feb 2011 07:03:23 -0800 (PST) In-Reply-To: <201102101403.p1AE3dBn010841@fs4113.wdf.sap.corp> References: <4D539DC8.9070106@gnutls.org> <201102101403.p1AE3dBn010841@fs4113.wdf.sap.corp> Date: Thu, 10 Feb 2011 16:03:23 +0100 X-Google-Sender-Auth: oVLL8cuZ9_Rb3SS77uCbGnSg_8Q Message-ID: From: Nikos Mavrogiannopoulos To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:03:13 -0000 On Thu, Feb 10, 2011 at 3:03 PM, Martin Rex wrote: >> "A hash function that provides a lower security strength than the (L, N) >> pair ordinarily should not be used, since this would reduce the >> security strength of the digital signature process to a level no greater >> than that provided by the hash function." [...] >> L =3D 1024, N =3D 160: SHA-1 or better >> L =3D 2048, N =3D 224: SHA-224 or better >> L =3D 2048, N =3D 256: SHA-256 or better >> L =3D 3072, N =3D 256: SHA-256 or better >> How does this apply to TLS 1.0 and 1.1 messages >> "Server Key Exchange" and "Certificate verify" >> that sign the handshake data? How is the peer >> going to understand which hash is being used? > By looking at the AlgId parameters of the DSA public key that > is involved in the signature operation. =C2=A0The public prime q, whose > length (in bits) is described by the Parameter N above, is part of the > AlgId Parameters of that DSA public key. =C2=A0(The L refers to the lengt= h > (in bits) of the public prime p, also part of the AlgId Parameters). The problem is that FIPS-186-3 says you can use SHA-224 if N=3D224, or SHA-256 and truncate it to 224 bit. So the algorithm needs to be explicit here... regards, Nikos From n.mavrogiannopoulos@gmail.com Thu Feb 10 07:05:05 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CBD3A697F for ; Thu, 10 Feb 2011 07:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRoVPIHc1zch for ; Thu, 10 Feb 2011 07:05:03 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A0F0A3A6969 for ; Thu, 10 Feb 2011 07:05:03 -0800 (PST) Received: by qyk34 with SMTP id 34so2315823qyk.10 for ; Thu, 10 Feb 2011 07:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nZ1KmgHa80+mrghUv/cqN7dYYbr0EhHYriv/uCvx42Q=; b=l3Sx4R+OkOx2GwTvR0k9a2E11/vPdVqf7NNwcNDUMjTiMrQG1q0ONdUKtY9ummldnb xPPfbV3kXFcRqG8vozW35zxWtNItuf8FV9hxbfAFQ1uf8x7W7QJ2ev9LTWsPxXN3mHvg QqpRXXvQOQXldszu62o1Nchceed3TD1bNS+5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RGqR2PyruUDxPM6lnuxFu54h3jVrVvvtUufizNv2dVsz+3Bs2LwoVsUcv/6SYR4r9J V04wi7NbBZ6vRAbbUMIorIzKB969kghDAW6A+gstRBn0WUmknobIIcfy3CjNvBNqLm8l IHeY73gb8i6syasF8eX/c72wGwgyeEDl2+5t0= MIME-Version: 1.0 Received: by 10.224.11.75 with SMTP id s11mr17287359qas.16.1297350315648; Thu, 10 Feb 2011 07:05:15 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 10 Feb 2011 07:05:15 -0800 (PST) In-Reply-To: References: <4D539DC8.9070106@gnutls.org> Date: Thu, 10 Feb 2011 16:05:15 +0100 X-Google-Sender-Auth: tu25xVqhwhCgFyuUX-6D1CVWkZw Message-ID: From: Nikos Mavrogiannopoulos To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:05:05 -0000 On Thu, Feb 10, 2011 at 10:49 AM, Peter Gutmann wrote: >>How does this apply to TLS 1.0 and 1.1 messages "Server Key Exchange" and >>"Certificate verify" that sign the handshake data? How is the peer going to >>understand which hash is being used? > It's always SHA-1. So here there is a choice either to violate FIPS-186-3 or TLS 1.0. If you use SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0 that requires 20 bytes of SHA-1... Quite some situation :) regards, Nikos From lists@drh-consultancy.demon.co.uk Thu Feb 10 07:08:29 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B883A67AC for ; Thu, 10 Feb 2011 07:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ71hBOu0dTQ for ; Thu, 10 Feb 2011 07:08:28 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by core3.amsl.com (Postfix) with ESMTP id B11B33A6973 for ; Thu, 10 Feb 2011 07:08:28 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50050 helo=[192.168.7.8]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10587) with esmtpa (authdaemon_plain:drh) id 1PnY8N-0007iE-58 for tls@ietf.org (return-path ); Thu, 10 Feb 2011 15:08:39 +0000 Message-ID: <4D53FF79.8020104@drh-consultancy.demon.co.uk> Date: Thu, 10 Feb 2011 15:08:41 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <4D539DC8.9070106@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:08:30 -0000 On 10/02/2011 15:05, Nikos Mavrogiannopoulos wrote: > On Thu, Feb 10, 2011 at 10:49 AM, Peter Gutmann > wrote: > >>> How does this apply to TLS 1.0 and 1.1 messages "Server Key Exchange" and >>> "Certificate verify" that sign the handshake data? How is the peer going to >>> understand which hash is being used? >> It's always SHA-1. > > So here there is a choice either to violate FIPS-186-3 or TLS 1.0. If you use > SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0 > that requires 20 bytes of SHA-1... Quite some situation :) > FIPS 186-3 also makes comments about RSA too, you can have just as much fun with those. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From Michael.Tuexen@lurchi.franken.de Thu Feb 10 07:56:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8445A3A69C8 for ; Thu, 10 Feb 2011 07:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz0pC60GTes1 for ; Thu, 10 Feb 2011 07:56:12 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 715B53A6886 for ; Thu, 10 Feb 2011 07:56:12 -0800 (PST) Received: from [192.168.1.113] (p508FA7CA.dip.t-dialin.net [80.143.167.202]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F0CF11C0B4619; Thu, 10 Feb 2011 16:56:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <201102101356.p1ADuPOp010592@fs4113.wdf.sap.corp> Date: Thu, 10 Feb 2011 16:56:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <334B4C17-7752-421F-9D5B-E0FD6DCD29E7@lurchi.franken.de> References: <201102101356.p1ADuPOp010592@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:56:13 -0000 On Feb 10, 2011, at 2:56 PM, Martin Rex wrote: > =?iso-8859-1?Q?Michael_T=FCxen?= wrote: >> >>>>> >>>>>> The intention of the sentence in the ID is that you can not send >>>>>> multiple HeartbeatRequest out. >>> >>> Duplicates can result from other phenomena, not just deliberate >>> retransmission. >> >> What is the point here? The rule is to protect the network. >> The receiver has to handle any kind of duplication, but that >> is not the point here. > > > An over-simplified statement like > > > There MUST NOT be more than one HeartbeatRequest message in flight at > a time. > > is inappropiate for the stated purpose. > > This single statement does not differentiate between compliant behaviour > for the sender and compliant behaviour for the receiver. > If it is necessary for the _receiver_ to handle duplicates gracefully > then this _must_ be spelled out seperately. > > As it is, the wording of the spec implies that the receiver of duplicated > HeartbeatRequest messages needs to abort the connection with a > fatal error in order to comply with the specification. But that is not written anywere. The ID states clearly: When a HeartbeatRequest message is received, a corresponding HeartbeatResponse message MUST be sent carrying an exact copy of the payload of the HeartbeatRequest. The padding of the received HeartbeatRequest message MUST be ignored. It MUST NOT be included in the HeartbeatResponse message, i.e. the padding field of the HeartbeatResponse message MUST have a length of zero. In general it is a bad idea to send a fatal error when you receive any DTLS packet twice. Best regards Michael > > > -Martin > From Michael.Tuexen@lurchi.franken.de Thu Feb 10 07:57:24 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C3A3A67B1 for ; Thu, 10 Feb 2011 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FediEF4cCso3 for ; Thu, 10 Feb 2011 07:57:23 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id F0BE33A6778 for ; Thu, 10 Feb 2011 07:57:22 -0800 (PST) Received: from [192.168.1.113] (p508FA7CA.dip.t-dialin.net [80.143.167.202]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AFACC1C0C0BD8; Thu, 10 Feb 2011 16:57:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <82wrl8rm7y.fsf@mid.bfk.de> Date: Thu, 10 Feb 2011 16:57:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A95873D-F163-470F-BC92-057DC663B8CC@lurchi.franken.de> References: <201102101356.p1ADuPOp010592@fs4113.wdf.sap.corp> <82wrl8rm7y.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:57:24 -0000 On Feb 10, 2011, at 3:35 PM, Florian Weimer wrote: > * Martin Rex: >=20 >> This single statement does not differentiate between compliant = behaviour >> for the sender and compliant behaviour for the receiver. >> If it is necessary for the _receiver_ to handle duplicates gracefully >> then this _must_ be spelled out seperately. >>=20 >> As it is, the wording of the spec implies that the receiver of = duplicated >> HeartbeatRequest messages needs to abort the connection with a >> fatal error in order to comply with the specification. >=20 > Thanks. This is my concern as well. Ahh, I see what you mean. But the procedures for the receiver are clearly specified. Best regards Michael >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 >=20 From n.mavrogiannopoulos@gmail.com Thu Feb 10 08:05:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A26D3A69FA for ; Thu, 10 Feb 2011 08:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIN7llyCmOFg for ; Thu, 10 Feb 2011 08:05:47 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 27F6B3A69C8 for ; Thu, 10 Feb 2011 08:05:47 -0800 (PST) Received: by qyj19 with SMTP id 19so1201372qyj.10 for ; Thu, 10 Feb 2011 08:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JgjDhrtZOP9WOXMsOfjd5cB2krtbuvMzOe5qlzJVXG4=; b=pNtnnPkR+OrojjlmBGuc7ezr9E+LnHNMt7WOLOol3W52qnWVGFjPNWwlLqgKFbj342 qBxk5XxBI3Tw5UKAZeKMUbiB094wLJewIIt0St46SSIIwaZ3p44+vsm2KkO8Ic8HYal5 2nBw09KVwkIlRAa5lDHIP3d55FS4l9c6w+tsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IkqO9fFOqltiCNjQkyRPms4nhQoUSN35OEXcnOecHk73S0ocwwfIqJgT3rNxuAqhk5 JrcweagjvZy9eJrck0WDVE0tpRbDaNGMDSxe25IZcvo2ml4ZObabYRU8t1vJ6n3xstnz U6D4dm8CcjJzxdrWZXBtTVH967SSpD2/DWXjU= MIME-Version: 1.0 Received: by 10.224.11.75 with SMTP id s11mr17345627qas.16.1297353959296; Thu, 10 Feb 2011 08:05:59 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 10 Feb 2011 08:05:59 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Feb 2011 17:05:59 +0100 X-Google-Sender-Auth: YxDUHgv-Ukd1ZtTADwQu1--Hfrg Message-ID: From: Nikos Mavrogiannopoulos To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:05:48 -0000 On Thu, Feb 10, 2011 at 4:46 PM, Peter Gutmann wrote: >>So here there is a choice either to violate FIPS-186-3 or TLS 1.0. If you= use >>SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0 th= at >>requires 20 bytes of SHA-1... Quite some situation :) > Not really, use of DSA server certs is practically nonexistent (anyone wa= nt to > trawl through the EFF cert database to count them?) and use of "DSA2" (i.= e. > > 1 kbit key) certs AFAIK *is* nonexistent, so it's nothing to worry about.= =C2=A0To > look at it another way, worrying about this is like worrying about what c= olour > unicorns are. Well, it is chicken and egg problem. If they cannot be used in practice wit= h any application because the spec is not clear, no-one will use them. If the spe= c was clear, and interoperable implementations could be made then, someone could apply for a certificate with a DSA key. But anyway since it's supposed to be supported by TLS, it should be clarified, otherwise it's better to drop = it completely... regards, Nikos From n.mavrogiannopoulos@gmail.com Thu Feb 10 08:49:35 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31833A676A for ; Thu, 10 Feb 2011 08:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvo3uVZ0G-Zq for ; Thu, 10 Feb 2011 08:49:34 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 9D0873A659B for ; Thu, 10 Feb 2011 08:49:34 -0800 (PST) Received: by qyj19 with SMTP id 19so1247395qyj.10 for ; Thu, 10 Feb 2011 08:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cKQC70HmMJKQxIom4NG0eeFsBy9BwaxpKpwJI6kvP6c=; b=EoqSvRlDj17WBq21XoikNIotb1AjYEtkMos/AGcFJirxQ9/32557lEsLN7eaw4X95E FW4JIA7Bl2QtIMBT2V53OQZpslDErA7AgP/FuoMkWVM0j4vcJlhEdUqGuSLWE8mQTCTv vVSe+TBlfnCDcrzqAFVZ0FKG35a7ihzPvM5hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=IEd9kO+FHekJcX60KJbYexlk73cmOJq8WYDA3oM0EDl3JCyByU1VzilmtExZfZ8LM+ c2AsHbODFPizBdes5eOlCcNofziazlsW5t8O9uKN/3RKpyhcNChpQIeqeIjnn0PREyDM tljnUe3dB8NV8CTTu+Ew1ALMwQPK2utEDi/oA= MIME-Version: 1.0 Received: by 10.224.11.75 with SMTP id s11mr17388454qas.16.1297356586813; Thu, 10 Feb 2011 08:49:46 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 10 Feb 2011 08:49:46 -0800 (PST) In-Reply-To: <4D539DC8.9070106@gnutls.org> References: <4D539DC8.9070106@gnutls.org> Date: Thu, 10 Feb 2011 17:49:46 +0100 X-Google-Sender-Auth: obctnvzlWt3B2QScreOgqzgW-Ks Message-ID: From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:49:35 -0000 On Thu, Feb 10, 2011 at 9:11 AM, Nikos Mavrogiannopoulos wrote: > Hello, > =C2=A0According to FIPS-186-3 the DSA algorithm might > be used with hashes other than SHA-1. Moreover > it mentions: > "A hash function that provides a lower security strength than the (L, N) > pair ordinarily should not be used, since this would reduce the > security strength of the digital signature process to a level no greater > than that provided by the hash function." [...] > For TLS 1.2 I suppose that the hash being negotiated > by the signature algorithm extension will be used, > and if it is larger than N, then it will be truncated. I've tried to clarify a bit the issues and make a "best current practice text": http://homes.esat.kuleuven.be/~nikos/draft-mavrogiannopoulos-tls-dss.txt Does this clarification match with what other implementations have done in supporting DSA? (in gnutls for example we didn't truncate the hash, if a larger hash was available to be selected, but rather use the next available...), Would be better if truncation be avoided at all? regards, Nikos From mrex@sap.com Thu Feb 10 09:08:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59013A6A45 for ; Thu, 10 Feb 2011 09:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9sXqRKDVqCz for ; Thu, 10 Feb 2011 09:08:05 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 6AEEF3A6A4C for ; Thu, 10 Feb 2011 09:08:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1AH7tTq001671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 18:07:55 +0100 (MET) From: Martin Rex Message-Id: <201102101707.p1AH7rjf020640@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Feb 2011 18:07:53 +0100 (MET) In-Reply-To: from "Nikos Mavrogiannopoulos" at Feb 10, 11 04:05:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:08:06 -0000 Nikos Mavrogiannopoulos wrote: > > On Thu, Feb 10, 2011 at 10:49 AM, Peter Gutmann > wrote: > > >>How does this apply to TLS 1.0 and 1.1 messages "Server Key Exchange" and > >>"Certificate verify" that sign the handshake data? How is the peer going to > >>understand which hash is being used? > > It's always SHA-1. > > So here there is a choice either to violate FIPS-186-3 or TLS 1.0. If you use > SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0 > that requires 20 bytes of SHA-1... Quite some situation :) Honestly I don't know how DSA signatures work in TLS, but a quick glance looks confusing. http://tools.ietf.org/html/rfc2246#section-4.7 In DSS, the 20 bytes of the SHA hash are run directly through the Digital Signing Algorithm with no additional hashing. This produces two values, r and s. The DSS signature is an opaque vector, as above, the contents of which are the DER encoding of: Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } The Dss-Sig-Value looks like the varying-size ASN.1 blob used in X.509 certs and PKCS#7 (rather than the fixed octet string DSA signature blobs that are used e.g. in XMLdsig). Both values r and s are the result of a modulo (prime q) operation, so their size depends on the size of the (prime q) parameter of the DSA key rather than the hash algorithm. Since ASN.1 DER encoding suppresses leading zero octets may add a an octet for a positive sign, the resulting size of this Dss-Sig-Value varies slightly. The description "In DSS, the 20 bytes of the SHA[-1] hash are run directly through the Digital Signing Algorithm with no additional hashing." is limited to using (L=1024,N=160) DSA keypairs. A reasonable and straight-forward approach to allowing the other three DSA key sizes from FIPS 186-3 (L=2048,N=224), (L=2048,N=256), (L=3072,N=256) with protocol version SSLv3 {0x03,0x00}, TLSv1.0 {0x03,0x01} and TLSv1.1 {0x03,0x02} would be to use the respective smallest hash (SHA-224, SHA-256, SHA-256) for calculating the hash in the underlying Signature struct defined here http://tools.ietf.org/html/rfc4346#page-44 This seems to be what the ECC cipher suite spec (rfc4492) for TLSv1.0/v1.1 appears to suggest doing, so it seems reasonable to do just the same for the DSA key sizes >1024 bit from FIPS 186-3. http://tools.ietf.org/html/rfc4492#page-20 enum { ecdsa } SignatureAlgorithm; select (SignatureAlgorithm) { case ecdsa: digitally-signed struct { opaque sha_hash[sha_size]; }; } Signature; ServerKeyExchange.signed_params.sha_hash SHA(ClientHello.random + ServerHello.random + ServerKeyExchange.params); NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange algorithm and "anonymous" for ECDH_anon. These cases are defined in TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA signatures are generated and verified as described in Section 5.10, and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature consists of a pair of integers, r and s. The digitally- signed element is encoded as an opaque vector <0..2^16-1>, the contents of which are the DER encoding [9] corresponding to the following ASN.1 notation [8]. -Martin From matt@mattmccutchen.net Thu Feb 10 09:49:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198243A6A67 for ; Thu, 10 Feb 2011 09:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPPKBxu037G5 for ; Thu, 10 Feb 2011 09:49:05 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 0CB1E3A69DA for ; Thu, 10 Feb 2011 09:49:05 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id CD922280071 for ; Thu, 10 Feb 2011 09:49:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=CkpQwPm lyYHvo6TihmrVm6QkhvU6pe3omomHgjNljyjuEbTQ26w2NsdFkqZnbWDyuBdQGvb BqbKIuMxjA79d+ddaESompOkK1be2TpeG1HdLGhYr0J5DncWojP9QIgtm7xdtmB1 /fvuTi2gqOEmd98RXbDLs14r8E39KluShHCo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=vd/byc1l/CVSy A7arUm4BUJlhF4=; b=u2h+QD/O7/mhyRc4nqRp/7hXBBubHabqgV47+I1JioAk1 BmUb3SdGwTCm2QEPFCq0eR5ZsXT3Foy6w4SZZN8N16xp5SN6DaIym6zkw05bUGk1 jMN7V9j/1NibRhy0edYOrfa7192d8oafKRotO4pRmLcMEHFd+I0TFaZnsbrdpc= Received: from [129.2.142.129] (unknown [129.2.142.129]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 97B37280062 for ; Thu, 10 Feb 2011 09:49:17 -0800 (PST) From: Matt McCutchen To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 12:49:16 -0500 Message-ID: <1297360156.1820.4.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:49:06 -0000 Here's an issue that might be worth adding as a security consideration in the next version of the DTLS specification. It may affect IPsec too; I haven't looked into that. Thoughts? DTLS does not prevent an attacker from dropping or reordering records. Datagram applications are generally designed to tolerate random packet loss and reordering, but care must be taken to ensure that adversarial loss and reordering cannot break the desired higher-level security properties. For example, one popular email client, when the user adds an account, attempts to test whether the server accepts TLS connections and configures the account to use TLS or plaintext connections accordingly. Of course, this setup process is vulnerable to downgrade if an attacker can block the test TLS connection, so the user might choose to perform it over a simple DTLS-based VPN that encapsulates each IP packet in a DTLS record. However, the attacker can still cause a downgrade if he can determine which encrypted DTLS records carry the test TLS connection and drop those records. -- Matt From mrex@sap.com Thu Feb 10 11:17:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0113A67D1 for ; Thu, 10 Feb 2011 11:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.795 X-Spam-Level: X-Spam-Status: No, score=-9.795 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_CODEINE=0.833] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAjnyHCw4jb9 for ; Thu, 10 Feb 2011 11:17:45 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 97DD13A67A4 for ; Thu, 10 Feb 2011 11:17:45 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1AJCq9L023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 20:12:52 +0100 (MET) From: Martin Rex Message-Id: <201102101912.p1AJCqPZ027499@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Thu, 10 Feb 2011 20:12:52 +0100 (MET) In-Reply-To: <5D2E8B79-1ABF-42A2-BCBD-941DB48365F7@checkpoint.com> from "Yoav Nir" at Feb 10, 11 11:33:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:17:46 -0000 Yoav Nir wrote: > > I've added some of the data about Microsoft's library; > I called it SChannel, because that's what it says in MSDN. > Hopefully, somebody who knows better will update the page > with the missing info. While it would be helpful to have an overview of the features of Microsoft SChannel available somewhere, I doubt such a description fits into this particular list. The original stated goal is offering a comparison to facilitate a _choice_. With Microsoft SChannel, there is _no_ choice. Windows 7 SChannel is available only on Windows 7. Other windows plattforms (of which there are plenty, e.g. XP,2003,CE) have their own SChannel implementations with significantly differing capabilities and defaults. Correctly describing the features of implementations is also pretty difficult, because these implementations may have several independently maintained codelines, with differing features and differing default bevhaviour. It may also not be immediately obvious whether a feature is not supported (aka not implemented), only defaults to off, or is buggy (and not being fixed). For Windows7 SChannel, TLSv1.2 and HMAC-256 seems off by default, SSLv2, RSA_EXPORT and RC4-40 are available, but off by default, at least for the client. Since we recently submitted a document for deprecating SSLv2 support-- it would be interesting to know which implementations support the SSL 2.0 CLIENT-HELLO at the beginning of an SSLv3 or TLSv1.x handshake, and the default max. TLS version propsed by the client. The still is a HUGE installed base of TLS that sends SSL 2.0 CLIENT-HELLO. Basically all of MSIE (6,7,8) on Windows XP appears to be sending it, because XP originally shipped with SSLv2 enabled. Those doing business for https:-based browser frontends to customers _really_ want their servers to accept SSL 2.0 CLIENT-HELLO as the first handshake message, -Martin From paul.hoffman@vpnc.org Thu Feb 10 11:31:44 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6293A69E4 for ; Thu, 10 Feb 2011 11:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.396 X-Spam-Level: X-Spam-Status: No, score=-101.396 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N-Cud937o5F for ; Thu, 10 Feb 2011 11:31:43 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 985F83A686A for ; Thu, 10 Feb 2011 11:31:43 -0800 (PST) Received: from MacBook-08.local (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1AJVtol049957 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 12:31:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D543D2B.1000802@vpnc.org> Date: Thu, 10 Feb 2011 11:31:55 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <1297360156.1820.4.camel@mattlaptop2.local> In-Reply-To: <1297360156.1820.4.camel@mattlaptop2.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:31:44 -0000 On 2/10/11 9:49 AM, Matt McCutchen wrote: > Here's an issue that might be worth adding as a security consideration > in the next version of the DTLS specification. It may affect IPsec too; > I haven't looked into that. Thoughts? I disagree with this suggestion, at least as it is proposed. > DTLS does not prevent an attacker from dropping or reordering records. > Datagram applications are generally designed to tolerate random packet > loss and reordering, but care must be taken to ensure that adversarial > loss and reordering cannot break the desired higher-level security > properties. That "care" sounds like it is care in the DTLS-using protocol, but no suggestion is given how such a protocol can show care. This makes the suggestion little more than "be careful", which is not useful. > For example, one popular email client, when the user adds > an account, attempts to test whether the server accepts TLS connections > and configures the account to use TLS or plaintext connections > accordingly. Of course, this setup process is vulnerable to downgrade > if an attacker can block the test TLS connection, so the user might > choose to perform it over a simple DTLS-based VPN that encapsulates each > IP packet in a DTLS record. However, the attacker can still cause a > downgrade if he can determine which encrypted DTLS records carry the > test TLS connection and drop those records. The user has no control over this application, and there are no email-over-DTLS protocols, so this example doesn't make sense. Is there a better, real-world example that might be used here? From wtc@google.com Thu Feb 10 11:50:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AEC3A67B3 for ; Thu, 10 Feb 2011 11:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbA2ulQIyctf for ; Thu, 10 Feb 2011 11:50:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1E9D23A69CA for ; Thu, 10 Feb 2011 11:50:42 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p1AJos49032551 for ; Thu, 10 Feb 2011 11:50:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297367455; bh=sYY9QMNtSE9Vj3SovzZIJv5PV2U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Hc66Y+VVI7VVw02w5DREmOA/FnBT49mj/ahF8x8tMga9pIdzTB7khhBrvDM3/PAzV ViH5dAiXfbJtuXmWSOMhw== Received: from wyb42 (wyb42.prod.google.com [10.241.225.106]) by kpbe17.cbf.corp.google.com with ESMTP id p1AJoq8l025230 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 10 Feb 2011 11:50:53 -0800 Received: by wyb42 with SMTP id 42so1807606wyb.23 for ; Thu, 10 Feb 2011 11:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/rFWk5l0oqOyeugquSAJwnorF2Tj2OGnRv/B/AMOzAw=; b=GEfogzOyY5RjcB4fgGoBG73+yhKdKPaw+06jnQi6uj+AvUdEK+OelfH+mw+1KU1PuR 2Yb40YZPBVNUgFVjmKrg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pu1QVkoaOwuleN54+7PexQmkAftkC2Lz2VP/szHebeq8ypwF4wBA70uiuI6n3vOEW+ TN7tHcwzfjltNnsMeXbQ== MIME-Version: 1.0 Received: by 10.216.183.209 with SMTP id q59mr19023070wem.17.1297367451855; Thu, 10 Feb 2011 11:50:51 -0800 (PST) Received: by 10.216.6.81 with HTTP; Thu, 10 Feb 2011 11:50:51 -0800 (PST) In-Reply-To: <87r5bhvsvq.fsf@latte.josefsson.org> References: <87r5bhvsvq.fsf@latte.josefsson.org> Date: Thu, 10 Feb 2011 11:50:51 -0800 Message-ID: From: Wan-Teh Chang To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:50:45 -0000 On Wed, Feb 9, 2011 at 12:46 PM, Simon Josefsson wrot= e: > All, > > I have been updating the following Wikipedia article with information on > different TLS implementations and their features. =A0Finding the > information by looking at source code is time-consuming (and error > prone), but I think it is alreadyinteresting in the way that it shows > that no TLS implementation supports all protocol features. =A0If you are > so inclined, please help to improve the page with useful information. > And by all means, fix any mistakes on it. > > http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations Thank you for creating this page. Bob Relyea and I have updated the NSS in= fo. Some of the info is biased. For example, obscure TLS extensions, including truncated HMAC that no SSL library implements, are listed, but the certificate status request extension (aka OCSP stapling) is not listed. You may want to omit the support for US "export" grade crypto (RSA-EXPORT and RC4-40) to save space. Nobody should evaluate an SSL library based on that today. Wan-Teh Chang From ekr@rtfm.com Thu Feb 10 12:02:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1BD3A67B3 for ; Thu, 10 Feb 2011 12:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UutCo5ri6gKN for ; Thu, 10 Feb 2011 12:02:51 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C21D43A6838 for ; Thu, 10 Feb 2011 12:02:51 -0800 (PST) Received: by yxt33 with SMTP id 33so847553yxt.31 for ; Thu, 10 Feb 2011 12:03:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.52.3 with SMTP id z3mr3168145agz.189.1297368184279; Thu, 10 Feb 2011 12:03:04 -0800 (PST) Received: by 10.90.117.9 with HTTP; Thu, 10 Feb 2011 12:03:03 -0800 (PST) In-Reply-To: <4D543D2B.1000802@vpnc.org> References: <1297360156.1820.4.camel@mattlaptop2.local> <4D543D2B.1000802@vpnc.org> Date: Thu, 10 Feb 2011 12:03:03 -0800 Message-ID: From: Eric Rescorla To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:02:53 -0000 On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman wrot= e: > On 2/10/11 9:49 AM, Matt McCutchen wrote: >> >> Here's an issue that might be worth adding as a security consideration >> in the next version of the DTLS specification. =A0It may affect IPsec to= o; >> I haven't looked into that. =A0Thoughts? > > I disagree with this suggestion, at least as it is proposed. > >> DTLS does not prevent an attacker from dropping or reordering records. >> Datagram applications are generally designed to tolerate random packet >> loss and reordering, but care must be taken to ensure that adversarial >> loss and reordering cannot break the desired higher-level security >> properties. > > That "care" sounds like it is care in the DTLS-using protocol, but no > suggestion is given how such a protocol can show care. This makes the > suggestion little more than "be careful", which is not useful. DTLS does deliver order information, of course. It just doesn't impose reordering. Perhaps the take-home for DTLS itself is that it would be nice if packets came with their sequence numbers attached. -Ekr >> For example, one popular email client, when the user adds >> an account, attempts to test whether the server accepts TLS connections >> and configures the account to use TLS or plaintext connections >> accordingly. =A0Of course, this setup process is vulnerable to downgrade >> if an attacker can block the test TLS connection, so the user might >> choose to perform it over a simple DTLS-based VPN that encapsulates each >> IP packet in a DTLS record. =A0However, the attacker can still cause a >> downgrade if he can determine which encrypted DTLS records carry the >> test TLS connection and drop those records. > > The user has no control over this application, and there are no > email-over-DTLS protocols, so this example doesn't make sense. Is there a > better, real-world example that might be used here? > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ekr@rtfm.com Thu Feb 10 12:03:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6513A69E4 for ; Thu, 10 Feb 2011 12:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPo--GzBYeuJ for ; Thu, 10 Feb 2011 12:03:09 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7CDF53A69CA for ; Thu, 10 Feb 2011 12:03:09 -0800 (PST) Received: by gyd12 with SMTP id 12so846526gyd.31 for ; Thu, 10 Feb 2011 12:03:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.52.3 with SMTP id z3mr3168467agz.189.1297368201959; Thu, 10 Feb 2011 12:03:21 -0800 (PST) Received: by 10.90.117.9 with HTTP; Thu, 10 Feb 2011 12:03:21 -0800 (PST) In-Reply-To: References: <1297360156.1820.4.camel@mattlaptop2.local> <4D543D2B.1000802@vpnc.org> Date: Thu, 10 Feb 2011 12:03:21 -0800 Message-ID: From: Eric Rescorla To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:03:10 -0000 On Thu, Feb 10, 2011 at 12:03 PM, Eric Rescorla wrote: > On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman wr= ote: >> On 2/10/11 9:49 AM, Matt McCutchen wrote: >>> >>> Here's an issue that might be worth adding as a security consideration >>> in the next version of the DTLS specification. =A0It may affect IPsec t= oo; >>> I haven't looked into that. =A0Thoughts? >> >> I disagree with this suggestion, at least as it is proposed. >> >>> DTLS does not prevent an attacker from dropping or reordering records. >>> Datagram applications are generally designed to tolerate random packet >>> loss and reordering, but care must be taken to ensure that adversarial >>> loss and reordering cannot break the desired higher-level security >>> properties. >> >> That "care" sounds like it is care in the DTLS-using protocol, but no >> suggestion is given how such a protocol can show care. This makes the >> suggestion little more than "be careful", which is not useful. > > DTLS does deliver order information, of course. It just doesn't impose > reordering. > > Perhaps the take-home for DTLS itself is that it would be nice if > packets came with > their sequence numbers attached. > In the API, I mean. -Ekr From dkg@fifthhorseman.net Thu Feb 10 12:03:12 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179C53A69E4 for ; Thu, 10 Feb 2011 12:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3Rfl2dP-WHO for ; Thu, 10 Feb 2011 12:03:11 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by core3.amsl.com (Postfix) with ESMTP id 2C3CE3A69CA for ; Thu, 10 Feb 2011 12:03:11 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 01D1EF970; Thu, 10 Feb 2011 15:03:20 -0500 (EST) Message-ID: <4D54447D.4050606@fifthhorseman.net> Date: Thu, 10 Feb 2011 15:03:09 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: Wan-Teh Chang References: <87r5bhvsvq.fsf@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCEA45ADA997DD10420F5DD3A" Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:03:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEA45ADA997DD10420F5DD3A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/10/2011 02:50 PM, Wan-Teh Chang wrote: > Thank you for creating this page. =20 Yes, thank you Simon! > Bob Relyea and I have updated the NSS info. Thanks to both of you for that. > Some of the info is biased. For example, obscure TLS extensions, > including truncated HMAC that no SSL library implements, are listed, > but the certificate status request extension (aka OCSP stapling) is > not listed. Adding a column for OCSP stapling would be a nice improvement to the page. Please do it! --dkg --------------enigCEA45ADA997DD10420F5DD3A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNVER9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpLNUP+wU+uDcChpSZUFRDgIVLjLAp Lwh/Wzq7Z6i/PIu6MW/l1SDe71CJpUw1EEo/44AcV37BgltYW2S4GyE3E2yHGQ4j iDPINRqwx2j/ldMb1yFjKdfsGIj3+R8+asWFhLBSM1lXnPnsEI4wlIqOazQNwSxt TBcD5IrxJLRwclL7GBiujaet2gfGxl3z4vW7JYYUvccbK0NUqKS2XC399T5MZqlp dzAfFL+jU1R4bjPvGyHMwEs6Vdg0fo4/9HBHLeJHnQi3OxVXVF3Idj219e82BUgO suHa6xH7YemwflPAZiGfoPdX0WfS0s9rs1wkkK55W0lsb7p4s47AlTeydAp3NV0v yPVzbFS4giQU8S9/28IUNmQRcUSrsfXca8BHMLASSh4VkBW9rsD1wg8fxw7dnlFy 34DLegf6NQSD0VJXM6mcsof9hPGLJ7e+r1FrgCpshaOc+U9sWFC3B7gG4hPli7TM EkDkYUKR1tF7koXhFoyAXsX0NaR/avfnJFJ0kyGQA3GeLRJ6hI9f9xPm91yI+mph +Pn9eTX7ftMGQ7sTAXVbpSB0sCd7R7K1hP27qlcfP60FKnlKUMrDZ05LjzcmgZXJ YlgURYMS351JjNSkYmlLmQpOTd0a8f/HNPXphfewg3a9wDRJ+pzxXIkPlVHyq+Uz NzhXeLl9cq2pyI6YLkfb =knEV -----END PGP SIGNATURE----- --------------enigCEA45ADA997DD10420F5DD3A-- From n.mavrogiannopoulos@gmail.com Thu Feb 10 12:18:15 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4CA3A67D1 for ; Thu, 10 Feb 2011 12:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ONt8BZyx+e5 for ; Thu, 10 Feb 2011 12:18:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7AA5D3A67B3 for ; Thu, 10 Feb 2011 12:18:14 -0800 (PST) Received: by eyd10 with SMTP id 10so1104477eyd.31 for ; Thu, 10 Feb 2011 12:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=zYA7b/DlEmRh6oV+sZRJp7GL5uTnZXi4yVmWeHg1cPQ=; b=R/PY0I++NV7PWrxBiH0HsDLnrmdL58HatZKpmne1XV9GApnXWKiQMLeF2fP2ybfF0X BjYXRpp99buDsBnttzJwU/GsJEt50tAU3ww2ExNtDAMC9Mwl6gcaKI1czLwBDwraEZOB vHRTMwysTBzGTTJTHEOTdsAIxupZviTuHhtuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=n6+b4YLYXiKlnxS19wgOo7GoddB51MbYORxAffNTj1XRp+9679DD3H89lCnVZ++yV3 eqKA9L0EMoj7pMJzmCpPLXR3junkt3IS7e5k1DwPUJTUacYlVb1+OEuy6/v10y71TaSb vtpVU+VT9ARIOmnUvRP4E8CRrWIrGoGDzDpuk= Received: by 10.14.45.75 with SMTP id o51mr4420811eeb.49.1297369106714; Thu, 10 Feb 2011 12:18:26 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id b52sm514eei.13.2011.02.10.12.18.25 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 12:18:25 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D544810.7010000@gnutls.org> Date: Thu, 10 Feb 2011 21:18:24 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Wan-Teh Chang References: <87r5bhvsvq.fsf@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:18:15 -0000 On 02/10/2011 08:50 PM, Wan-Teh Chang wrote: > Some of the info is biased. For example, obscure TLS extensions, > including truncated HMAC that no SSL library implements, are listed, [...] To me it still serves a purpose... We wouldn't know that no-one implemented that if that page wasn't there :) > You may want to omit the support for US "export" grade crypto > (RSA-EXPORT and RC4-40) to save space. Nobody should evaluate an > SSL library based on that today. Indeed, but it is a way for someone to see that they are still in existence. regards, Nikos From ynir@checkpoint.com Thu Feb 10 12:58:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C5A3A69E5 for ; Thu, 10 Feb 2011 12:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_CODEINE=0.833] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gILsGk6nUUmd for ; Thu, 10 Feb 2011 12:58:32 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 1E88F3A6833 for ; Thu, 10 Feb 2011 12:58:31 -0800 (PST) X-CheckPoint: {4D545184-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1AKwisO012840; Thu, 10 Feb 2011 22:58:44 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Feb 2011 22:58:43 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 10 Feb 2011 22:58:43 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Thu, 10 Feb 2011 22:58:42 +0200 Thread-Topic: [TLS] Wikipedia TLS Comparison page Thread-Index: AcvJZUy+fNBPP89uSyKc7/MJFcnDag== Message-ID: <4E32D2BB-A871-4BD9-B5E3-137F4D819289@checkpoint.com> References: <201102101912.p1AJCqPZ027499@fs4113.wdf.sap.corp> In-Reply-To: <201102101912.p1AJCqPZ027499@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "simon@josefsson.org" , "tls@ietf.org" Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:58:33 -0000 On Feb 10, 2011, at 9:12 PM, Martin Rex wrote: > Yoav Nir wrote: >>=20 >> I've added some of the data about Microsoft's library; >> I called it SChannel, because that's what it says in MSDN. >> Hopefully, somebody who knows better will update the page >> with the missing info. >=20 > While it would be helpful to have an overview of the features > of Microsoft SChannel available somewhere, I doubt such a description > fits into this particular list. I think that depends on your situation. When we (my company) wanted to writ= e an SSL-based client for Windows, we had a choice of using OpenSSL, SChann= el, rolling our own, or licensing one of those that are available for licen= sing. SChannel was clearly a viable choice, and finally it was chosen, beca= use that made the binary smaller (the SSL library was already there). > The original stated goal is offering a comparison to facilitate a _choice= _. > With Microsoft SChannel, there is _no_ choice. Windows 7 SChannel is > available only on Windows 7. Other windows plattforms (of which there > are plenty, e.g. XP,2003,CE) have their own SChannel implementations > with significantly differing capabilities and defaults. Sure, and what works on Windows XP, will work the same way on Windows Vista= , 7, 2003, and 2008, and pretty much the same on CE or whatever they call i= t these days. If you want newer features, you need the newer operating system. If I had a= lot of time on my hands, I would split that table to Schannel-XP, SChannel= -Vista and SChannel-7. As it is, I wrote what I know about Windows 7. But I= agree that it's much easier to migrate to the latest OpenSSL, than to forc= e your users to migrate to Windows 7.=20 >=20 >=20 > Correctly describing the features of implementations is also pretty > difficult, because these implementations may have several independently > maintained codelines, with differing features and differing default > bevhaviour. It may also not be immediately obvious whether a > feature is not supported (aka not implemented), only defaults to off, > or is buggy (and not being fixed). As far as I found it (I only invested 10-15 minutes in this) I used packet = capture and MSDN >=20 > For Windows7 SChannel, TLSv1.2 and HMAC-256 seems off by default, > SSLv2, RSA_EXPORT and RC4-40 are available, but off by default, at least > for the client. I think you're conflating SChannel with Internet Explorer. IE does have TLS= v1.2 and 1.1 off by default, but when programming your own application, it'= s all up to the parameters you configure. >=20 >=20 > Since we recently submitted a document for deprecating SSLv2 support-- > it would be interesting to know which implementations support the > SSL 2.0 CLIENT-HELLO at the beginning of an SSLv3 or TLSv1.x handshake, > and the default max. TLS version propsed by the client. >=20 > The still is a HUGE installed base of TLS that sends SSL 2.0 CLIENT-HELLO= . > Basically all of MSIE (6,7,8) on Windows XP appears to be sending it, > because XP originally shipped with SSLv2 enabled. Those doing business > for https:-based browser frontends to customers _really_ want their > servers to accept SSL 2.0 CLIENT-HELLO as the first handshake message, I agree. You can easily run a client today without SSLv2 at all, but now a = web server. Even our proprietary TLS library (which I didn't list because i= t's not available) supports SSLv2 client hellos. Last data I've seen is the= IE6 is still 20% of the web, and XP is still huge. Are you sure about IE7= /8 offering SSLv2 by default on XP? I thought that was gone. Yoav= From matt@mattmccutchen.net Thu Feb 10 13:07:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4573A6817 for ; Thu, 10 Feb 2011 13:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX2dhIwze0JX for ; Thu, 10 Feb 2011 13:07:36 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id C9EC43A67B8 for ; Thu, 10 Feb 2011 13:07:36 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id DF198280073; Thu, 10 Feb 2011 13:07:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=OOTaXXlRI2Fh9JQtkCdtFNg7YprYoNtfRSHnwd1e4my fkCnnJqNS0uw6eDgbFdMwnD+zXQH3uouGvyC0fn9oQ5z1Js/B31xGdkOiXC/Q97+ 6bXDF89Ghw4RZZUDe52mNc2n6w9BjPWzeHN2V3T4F6p7dDwPk3i4S+4ClVKidJSk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=ybUZDyg7S8UvYARoZT+W/oGAXeQ=; b=eqWNaNhnGt WaTd+pVrLKy7S56gSY1zDLxuYTmId/swWjCOERX8K5xwvKos5PHWZWBKJqQavMxs FgjUegHu8BoAsd7rCYIIBGLiq8dY1xaNAOGie0Qn4P3DhW3KJIq0tobB++E8TgSc y24kG19AX/8Id8v22eY/H31O8f+ViTKbM= Received: from [129.2.142.129] (unknown [129.2.142.129]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 7EB3D280062; Thu, 10 Feb 2011 13:07:49 -0800 (PST) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <4D543D2B.1000802@vpnc.org> References: <1297360156.1820.4.camel@mattlaptop2.local> <4D543D2B.1000802@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 16:07:48 -0500 Message-ID: <1297372068.1820.32.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 21:07:38 -0000 On Thu, 2011-02-10 at 11:31 -0800, Paul Hoffman wrote: > On 2/10/11 9:49 AM, Matt McCutchen wrote: > > DTLS does not prevent an attacker from dropping or reordering records. > > Datagram applications are generally designed to tolerate random packet > > loss and reordering, but care must be taken to ensure that adversarial > > loss and reordering cannot break the desired higher-level security > > properties. > > That "care" sounds like it is care in the DTLS-using protocol, but no > suggestion is given how such a protocol can show care. This makes the > suggestion little more than "be careful", which is not useful. Maybe the wording can be improved. The point is to make the designers of DTLS-based protocols aware of the issue. Its implications will, of course, depend on the protocol. For some protocols, adversarial loss may not be a big deal. Other protocols may need to take steps to ensure that important records are received so that one side does not do something bad on the basis of not having received them. For tunneling protocols like my hypothetical VPN, the possibility of adversarial loss becomes an important characteristic of the resulting tunnel abstraction that may make it unsuitable for some uses. E.g., users often imagine a VPN connection to be the equivalent, for as long as it stays up, of a direct wired connection that suffers only random packet loss, but this may not be true. > > For example, one popular email client, when the user adds > > an account, attempts to test whether the server accepts TLS connections > > and configures the account to use TLS or plaintext connections > > accordingly. Of course, this setup process is vulnerable to downgrade > > if an attacker can block the test TLS connection, so the user might > > choose to perform it over a simple DTLS-based VPN that encapsulates each > > IP packet in a DTLS record. However, the attacker can still cause a > > downgrade if he can determine which encrypted DTLS records carry the > > test TLS connection and drop those records. > > The user has no control over this application, I don't follow. If you're saying the user should configure the application manually, I agree, but it's worth noting that such applications exist. > and there are no > email-over-DTLS protocols, In the example, the IP packets of the (say) IMAP TLS connection are tunneled inside DTLS records. -- Matt From matt@mattmccutchen.net Thu Feb 10 13:10:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CEA3A6A0B for ; Thu, 10 Feb 2011 13:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgKh0D98W6Xl for ; Thu, 10 Feb 2011 13:10:37 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 8C8BD3A684E for ; Thu, 10 Feb 2011 13:10:37 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 9F2F270406E; Thu, 10 Feb 2011 13:10:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=XYSq/SWfRoc7h82WFTL+OGuh3QoSOYRnJWF8d1nZsmA aoCl8ulTgi6zLec6WtvM9f2hNHzzJfoVEhdiCmaCTfjqdydZ9PTJMC+ZegrV1aRD EFkzbtpO2NqpGmyCyHdQpeQb11mt6tHRi3CZkaH1ZyaCFP6Z6QwUfiRXn1gueYrE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=KCaDm5xdicmR82Ykhz8BhoEo3Dk=; b=Vhr4aS3HFa WI4iKWB+B4fQjwRUyeTk9DSE8jaRVOPNTeLO8Jk8KJ+Azup8OISi7Ld5F5T05BqX 8JAm305dXHpRnIHE067uHDRSYdlG6Pxi4/9iQyvBCfoKwnGWt8+R99plDk9cPZkS Hy+2A0a+0hfSKAHwVE5WxSiRz/fCvlTSo= Received: from [129.2.142.129] (unknown [129.2.142.129]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id 3FAD870406A; Thu, 10 Feb 2011 13:10:50 -0800 (PST) From: Matt McCutchen To: Eric Rescorla In-Reply-To: References: <1297360156.1820.4.camel@mattlaptop2.local> <4D543D2B.1000802@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 16:10:49 -0500 Message-ID: <1297372249.1820.35.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 21:10:38 -0000 On Thu, 2011-02-10 at 12:03 -0800, Eric Rescorla wrote: > On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman wrote: > > On 2/10/11 9:49 AM, Matt McCutchen wrote: > >> DTLS does not prevent an attacker from dropping or reordering records. > >> Datagram applications are generally designed to tolerate random packet > >> loss and reordering, but care must be taken to ensure that adversarial > >> loss and reordering cannot break the desired higher-level security > >> properties. [...] > DTLS does deliver order information, of course. It just doesn't impose > reordering. > > Perhaps the take-home for DTLS itself is that it would be nice if > packets came with > their sequence numbers attached. Good point. Though, I mentioned reordering mainly for completeness; I can't think of a realistic attack based on reordering. -- Matt From Xuelei.Fan@Oracle.COM Thu Feb 10 15:36:58 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD2F3A6B0E for ; Thu, 10 Feb 2011 15:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_CODEINE=0.833] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfNvJKQBrqGR for ; Thu, 10 Feb 2011 15:36:57 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 10DC83A6B10 for ; Thu, 10 Feb 2011 15:36:57 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1ANaupD032532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 23:36:58 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1ANatg8014080; Thu, 10 Feb 2011 23:36:55 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 1043525671297380987; Thu, 10 Feb 2011 15:36:27 -0800 Received: from [10.159.219.240] (/10.159.219.240) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Feb 2011 15:36:27 -0800 Message-ID: <4D547675.7010109@Oracle.COM> Date: Fri, 11 Feb 2011 07:36:21 +0800 From: Xuelei Fan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mrex@sap.com, simon@josefsson.org References: <201102101912.p1AJCqPZ027499@fs4113.wdf.sap.corp> In-Reply-To: <201102101912.p1AJCqPZ027499@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D547698.0094:SCFMA4539814,ss=1,fgs=0 Cc: tls@ietf.org Subject: Re: [TLS] Wikipedia TLS Comparison page X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:36:58 -0000 Thank you Simon for creating this page. > For Windows7 SChannel, TLSv1.2 and HMAC-256 seems off by default, > SSLv2, RSA_EXPORT and RC4-40 are available, but off by default, > at least for the client. It maybe helpful to list what are the default and supported protocols and cipher suites for client and server. Except the TLS specification, some other features, for example Certificate status (CRL/OCSP) checking, cryptographic strength(supported key size and default key size), may be also the aspects need to consider. However, these points may be more suitable in the wiki of the back-end crypto implementation. Thanks, Xuelei On 2/11/2011 3:12 AM, Martin Rex wrote: > Yoav Nir wrote: >> I've added some of the data about Microsoft's library; >> I called it SChannel, because that's what it says in MSDN. >> Hopefully, somebody who knows better will update the page >> with the missing info. > While it would be helpful to have an overview of the features > of Microsoft SChannel available somewhere, I doubt such a description > fits into this particular list. > The original stated goal is offering a comparison to facilitate a _choice_. > With Microsoft SChannel, there is _no_ choice. Windows 7 SChannel is > available only on Windows 7. Other windows plattforms (of which there > are plenty, e.g. XP,2003,CE) have their own SChannel implementations > with significantly differing capabilities and defaults. > > > Correctly describing the features of implementations is also pretty > difficult, because these implementations may have several independently > maintained codelines, with differing features and differing default > bevhaviour. It may also not be immediately obvious whether a > feature is not supported (aka not implemented), only defaults to off, > or is buggy (and not being fixed). > > For Windows7 SChannel, TLSv1.2 and HMAC-256 seems off by default, > SSLv2, RSA_EXPORT and RC4-40 are available, but off by default, at least > for the client. > > > Since we recently submitted a document for deprecating SSLv2 support-- > it would be interesting to know which implementations support the > SSL 2.0 CLIENT-HELLO at the beginning of an SSLv3 or TLSv1.x handshake, > and the default max. TLS version propsed by the client. > > The still is a HUGE installed base of TLS that sends SSL 2.0 CLIENT-HELLO. > Basically all of MSIE (6,7,8) on Windows XP appears to be sending it, > because XP originally shipped with SSLv2 enabled. Those doing business > for https:-based browser frontends to customers _really_ want their > servers to accept SSL 2.0 CLIENT-HELLO as the first handshake message, > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From smb@cs.columbia.edu Thu Feb 10 16:50:59 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F293A6B18 for ; Thu, 10 Feb 2011 16:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjtdmPEm8RNN for ; Thu, 10 Feb 2011 16:50:58 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 8921B3A6823 for ; Thu, 10 Feb 2011 16:50:58 -0800 (PST) Received: from mallet-extra.cs.columbia.edu (mallet-extra.cs.columbia.edu [128.59.21.117]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p1B0p8Cs004558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Feb 2011 19:51:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Thu, 10 Feb 2011 19:51:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1297360156.1820.4.camel@mattlaptop2.local> <4D543D2B.1000802@vpnc.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:50:59 -0000 On Feb 10, 2011, at 3:03 21PM, Eric Rescorla wrote: > On Thu, Feb 10, 2011 at 12:03 PM, Eric Rescorla wrote: >> On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman = wrote: >>> On 2/10/11 9:49 AM, Matt McCutchen wrote: >>>>=20 >>>> Here's an issue that might be worth adding as a security = consideration >>>> in the next version of the DTLS specification. It may affect IPsec = too; >>>> I haven't looked into that. Thoughts? >>>=20 >>> I disagree with this suggestion, at least as it is proposed. >>>=20 >>>> DTLS does not prevent an attacker from dropping or reordering = records. >>>> Datagram applications are generally designed to tolerate random = packet >>>> loss and reordering, but care must be taken to ensure that = adversarial >>>> loss and reordering cannot break the desired higher-level security >>>> properties. >>>=20 >>> That "care" sounds like it is care in the DTLS-using protocol, but = no >>> suggestion is given how such a protocol can show care. This makes = the >>> suggestion little more than "be careful", which is not useful. >>=20 >> DTLS does deliver order information, of course. It just doesn't = impose >> reordering. >>=20 >> Perhaps the take-home for DTLS itself is that it would be nice if >> packets came with >> their sequence numbers attached. >>=20 >=20 > In the API, I mean. >=20 Given the importance of sequence numbers for IPsec, I very much agree. --Steve Bellovin, http://www.cs.columbia.edu/~smb From n.mavrogiannopoulos@gmail.com Fri Feb 11 00:18:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31C93A6A5D for ; Fri, 11 Feb 2011 00:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS5rIiIxmsEZ for ; Fri, 11 Feb 2011 00:18:21 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9BE043A681D for ; Fri, 11 Feb 2011 00:18:21 -0800 (PST) Received: by wyf23 with SMTP id 23so2354972wyf.31 for ; Fri, 11 Feb 2011 00:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=7AdViqpcIXoRESpKFi1lahydp9dd7kvmOD+hQdWn4d8=; b=acLSVd2bRehASHH6Qw0v4hpoUD28bbMReMGEVcNv6CAEMPUscI9I2Tb9PHYB+87H4H 7vfatAUUsqDNol5ZvS1jNnXnSLhAFD86r3fBlmInW1ItLriYCj/nFK0pj4UxDxJx79f7 jGH+gnw7puh2neRE6RSnwLDhbzvw5AureCKxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=bq0oM56qKSChLWXVAYNGC6wHN2qbJw8BvlZ4F+a5sPQ2QyxIxN+1xMpc+zieGiYanM zK4i0rvey8JOK8OrRA3/9cH8rtjw9i72ge2CRKKIOTmgoixlLk+vVBA4QJSVSUYm5cme RIrtIByT3BpQePJIihUF0c/6m84OlpyP3brL0= Received: by 10.216.181.141 with SMTP id l13mr180667wem.22.1297412314126; Fri, 11 Feb 2011 00:18:34 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id b54sm194408wer.21.2011.02.11.00.18.32 (version=SSLv3 cipher=OTHER); Fri, 11 Feb 2011 00:18:33 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D54F0D7.4040205@gnutls.org> Date: Fri, 11 Feb 2011 09:18:31 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 08:18:22 -0000 Hello, After some discussion with Sean Turner, I've decided to try re-shaping the old draft-ietf-tls-ssl-version3 draft to be publish it as a historic rfc. The draft I came up with is at: http://tools.ietf.org/html/draft-mavrogiannopoulos-ssl-version3-00 I've converted the original document to xml format so some formatting might not be exactly the same. Apart from that other changes to the original are: * stray references to documents [IP],[SSL-2] were defined. * stray reference to RC4 was replaced with RSADSI. * Appendix A.1.1 was renumbered as A.2 as it was not a subsection of A.1. * Section that discussed patents was removed (all patents discussed are expired). Do you think this draft should be adopted by the WG and be published as historic? regards, Nikos From simon@josefsson.org Fri Feb 11 00:35:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D883A6BD3 for ; Fri, 11 Feb 2011 00:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c0T4RSKhc9F for ; Fri, 11 Feb 2011 00:35:36 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 035503A69C0 for ; Fri, 11 Feb 2011 00:35:32 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1B8ZgLe013522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 11 Feb 2011 09:35:43 +0100 From: Simon Josefsson To: "tls\@ietf.org" References: <4D54F0D7.4040205@gnutls.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110211:nmav@gnutls.org::CptEkS3NVukK983U:42Xm X-Hashcash: 1:22:110211:tls@ietf.org::IebhhdNU81ZgTN5o:HEpU Date: Fri, 11 Feb 2011 09:35:41 +0100 In-Reply-To: <4D54F0D7.4040205@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 11 Feb 2011 09:18:31 +0100") Message-ID: <87r5bf55pe.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 08:35:37 -0000 Nikos Mavrogiannopoulos writes: > Do you think this draft should be adopted by the WG and be published as > historic? I support this. /Simon From ynir@checkpoint.com Fri Feb 11 02:03:15 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2483A688F for ; Fri, 11 Feb 2011 02:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uh-NYC2mBny for ; Fri, 11 Feb 2011 02:03:14 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 2C4CA3A683D for ; Fri, 11 Feb 2011 02:03:13 -0800 (PST) X-CheckPoint: {4D55096F-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1BA3Fb2029442; Fri, 11 Feb 2011 12:03:15 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 11 Feb 2011 12:03:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 11 Feb 2011 12:03:14 +0200 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Fri, 11 Feb 2011 12:03:13 +0200 Thread-Topic: [TLS] publishing SSL 3.0 as historic Thread-Index: AcvJ0uV94TsyHcaZTti/DmbZMz698g== Message-ID: <1C86570D-2738-456C-8881-EC52966635B4@checkpoint.com> References: <4D54F0D7.4040205@gnutls.org> In-Reply-To: <4D54F0D7.4040205@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:03:15 -0000 On Feb 11, 2011, at 10:18 AM, Nikos Mavrogiannopoulos wrote: >=20 > Do you think this draft should be adopted by the WG and be published as > historic? I think it should be published, but why does it need the working group? SS= Lv3 is by now set in stone, or rather, set in the code of the browsers that= support it. From n.mavrogiannopoulos@gmail.com Fri Feb 11 02:49:58 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1203A69FF for ; Fri, 11 Feb 2011 02:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SDXnyynVFTA for ; Fri, 11 Feb 2011 02:49:57 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 132533A6964 for ; Fri, 11 Feb 2011 02:49:56 -0800 (PST) Received: by qyj19 with SMTP id 19so1837289qyj.10 for ; Fri, 11 Feb 2011 02:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g6kBxJ0umdF5ej0jaCqjipGa4gqqxzc7J+65uc7+r2o=; b=s572OCN0595a1GnQCAE5blv4Dk62I9Ab6Gx6KIesxjdmjvPsdvrScaxYoVcEusb3Jv 5J5LX7bq1KdibhbkbNeEwXxOlMGMt0guHkPzpyE6Xnh7PauAzFeVuaqwHAZzACCSLzRT NChNze9FxPAK6GUSy/sKg54nbb5X7tZXBUlO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CUME9HcR4ZuNMvdhn1gMfSDm6u2XoYFPng809CwJj83y1NSIStjdkJDf4rb3FKu6LV an4m8TuF8yOzBTUgZWUJtoWafstK+Sqc3lm7yYx+Ng5zLW4sQSJPstS9e55yW8fqeLV/ WOy/4N7bUyCipUOu8WjzRtWauKsOkwzv9nBR0= MIME-Version: 1.0 Received: by 10.229.183.142 with SMTP id cg14mr370019qcb.90.1297421411052; Fri, 11 Feb 2011 02:50:11 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Fri, 11 Feb 2011 02:50:11 -0800 (PST) In-Reply-To: <1C86570D-2738-456C-8881-EC52966635B4@checkpoint.com> References: <4D54F0D7.4040205@gnutls.org> <1C86570D-2738-456C-8881-EC52966635B4@checkpoint.com> Date: Fri, 11 Feb 2011 11:50:11 +0100 X-Google-Sender-Auth: o4CPo_bSFmTERuWXOHV-G__SxEU Message-ID: From: Nikos Mavrogiannopoulos To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:49:58 -0000 On Fri, Feb 11, 2011 at 11:03 AM, Yoav Nir wrote: >> Do you think this draft should be adopted by the WG and be published as >> historic? > I think it should be published, but why does it need the working group? = =C2=A0SSLv3 is by now set in stone, or rather, set in the code of the brows= ers that support it. Because draft-ietf-tls-ssl-version3 was this working group's item. regards, Nikos From noskov@microsoft.com Fri Feb 11 10:30:12 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C333A696E for ; Fri, 11 Feb 2011 10:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1faydySiWosz for ; Fri, 11 Feb 2011 10:30:11 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 248633A69D2 for ; Fri, 11 Feb 2011 10:30:11 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Feb 2011 10:30:25 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 11 Feb 2011 10:30:26 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.252]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 11 Feb 2011 10:30:24 -0800 From: Nasko Oskov To: Nikos Mavrogiannopoulos , "tls@ietf.org" Thread-Topic: [TLS] AES-GCM implementation Thread-Index: AQHLxQuI1si9KPc040aByqJoYfxugZP8qPLw Date: Fri, 11 Feb 2011 18:29:39 +0000 Deferred-Delivery: Fri, 11 Feb 2011 18:30:00 +0000 Message-ID: <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4D4D04C8.1090307@gnutls.org> In-Reply-To: <4D4D04C8.1090307@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 18:30:12 -0000 >-----Original Message----- >From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Niko= s Mavrogiannopoulos >Sent: Saturday, February 05, 2011 12:05 AM >To: tls@ietf.org >Subject: [TLS] AES-GCM implementation > >Hello, > Are there any public servers implementing the AES-GCM (RFC5288) >ciphersuites for TLS? > >regards, >Nikos The interop server we have at Microsoft supports AES-GCM. The address is tl= s.woodgrovebank.com. Let me know if you have any troubles trying to interop. Thanks, Nasko Oskov From Joshua.Davies@travelocity.com Fri Feb 11 11:14:01 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402C63A6A01 for ; Fri, 11 Feb 2011 11:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKe00GUHATuy for ; Fri, 11 Feb 2011 11:14:00 -0800 (PST) Received: from sgtulmg02-out.sabre.com (sgtulmg02-out.sabre.com [151.193.220.19]) by core3.amsl.com (Postfix) with ESMTP id 389303A69FF for ; Fri, 11 Feb 2011 11:13:59 -0800 (PST) X-ExtLoop1: From 10.12.97.30 X-IronPort-AV: E=Sophos;i="4.60,456,1291615200"; d="scan'208";a="823846562" Received: from unknown (HELO SGTULMHP001.Global.ad.sabre.com) ([10.12.97.30]) by sgtulmg02-out.sabre.com with ESMTP/TLS/AES128-SHA; 11 Feb 2011 13:14:14 -0600 Received: from SGTULMMP004.Global.ad.sabre.com ([::1]) by SGTULMHP001.Global.ad.sabre.com ([::1]) with mapi; Fri, 11 Feb 2011 13:14:14 -0600 From: "Davies, Joshua" To: Nasko Oskov , Nikos Mavrogiannopoulos , "tls@ietf.org" Date: Fri, 11 Feb 2011 13:14:08 -0600 Thread-Topic: [TLS] AES-GCM implementation Thread-Index: AQHLxQuI1si9KPc040aByqJoYfxugZP8qPLwgAAKBrA= Message-ID: References: <4D4D04C8.1090307@gnutls.org> <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 19:14:01 -0000 Which cipher suites? I just sent a client hello with TLS_RSA_WITH_AES_128_= GCM_SHA256 (0x009C) and tls.woodgrovebank.com terminated the connection wit= hout responding with a server hello. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nasko= Oskov Sent: Friday, February 11, 2011 12:30 PM To: Nikos Mavrogiannopoulos; tls@ietf.org Subject: Re: [TLS] AES-GCM implementation >-----Original Message----- >From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Niko= s Mavrogiannopoulos >Sent: Saturday, February 05, 2011 12:05 AM >To: tls@ietf.org >Subject: [TLS] AES-GCM implementation > >Hello, > Are there any public servers implementing the AES-GCM (RFC5288) >ciphersuites for TLS? > >regards, >Nikos The interop server we have at Microsoft supports AES-GCM. The address is tl= s.woodgrovebank.com. Let me know if you have any troubles trying to interop. Thanks, Nasko Oskov _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From wtc@google.com Fri Feb 11 11:48:56 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9DB3A6B10 for ; Fri, 11 Feb 2011 11:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctI46aOiGJXS for ; Fri, 11 Feb 2011 11:48:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2FE203A6AFA for ; Fri, 11 Feb 2011 11:48:55 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p1BJnAFH020003 for ; Fri, 11 Feb 2011 11:49:10 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297453750; bh=FDyIoD5+d1sDSScBOq47coYJ3Jw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=cL8jfDRKggiC/rN9HU2WFIkxDSVO08NVrUJG6hL4V3n5zughYJAk2gRK1+XpQAgAy 21C9y3iheDuR3y1HXC1zQ== Received: from wwi18 (wwi18.prod.google.com [10.241.243.18]) by hpaq1.eem.corp.google.com with ESMTP id p1BJm5Rx025396 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 11 Feb 2011 11:48:58 -0800 Received: by wwi18 with SMTP id 18so4639558wwi.2 for ; Fri, 11 Feb 2011 11:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=33Q1fvRoKmBVBFcb9MK/29JQRN/RbU9rt9nh/RsO5BA=; b=LBWLu2xyukXBylxqjk87e+4PnoDYNM/vWveFZt2skbgROmWS9UiKWuaYgymChhHyWd GGwHEQwY5fU+oBl04wxw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jsqCe9/ucvqx04lWDVCBbDusbsY8CGNBJGj8xX8epwr5bEhfs+kvNWMk2dcKHy7US+ eKqGn794TunXYMp/3wnA== MIME-Version: 1.0 Received: by 10.216.8.141 with SMTP id 13mr895263wer.47.1297453736713; Fri, 11 Feb 2011 11:48:56 -0800 (PST) Received: by 10.216.6.81 with HTTP; Fri, 11 Feb 2011 11:48:56 -0800 (PST) In-Reply-To: References: <4D4D04C8.1090307@gnutls.org> <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 11 Feb 2011 11:48:56 -0800 Message-ID: From: Wan-Teh Chang To: "Davies, Joshua" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 19:48:56 -0000 On Fri, Feb 11, 2011 at 11:14 AM, Davies, Joshua wrote: > Which cipher suites? =A0I just sent a client hello with > TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C) and tls.woodgrovebank.com > terminated the connection without responding with a server hello. Since Internet Explorer advertises support for only the two ECDHE-ECDSA AES-GCM cipher suites (apparently for Suite B compliance), the Microsoft interop test server is unlikely to support TLS_RSA_WITH_AES_128_GCM_SHA256. Wan-Teh Chang From yaronf.ietf@gmail.com Fri Feb 11 13:05:29 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708173A69DA; Fri, 11 Feb 2011 13:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taCXQUAjwWZV; Fri, 11 Feb 2011 13:05:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B788E3A67B3; Fri, 11 Feb 2011 13:05:27 -0800 (PST) Received: by fxm9 with SMTP id 9so3613508fxm.31 for ; Fri, 11 Feb 2011 13:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cvNl19M/srth74vU+IiEN8T3f05h9dm03sFzhihjTbE=; b=lYBiR5WzODbVoM3Prelh7NqwIEljsgv8/tyTlP29362Ae29AZ2BrUl9nMfsk8aOuwh keGX/DQ3r8cBUEUpSSna4WxnK+ZcXHHpuEHHzFc//ywq3QjCYslHtTWCLDAS76E44cSF H91tpa4IikzsRiEICMgW8uzYqKJsj3ckhoXBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wcDsi3NFepjRZCZDy9MOj2cpiAD/ZZjSlQYXjvWllrlV3kN3vS4hLhjxkfW+SXDm4x YyaE6I0GlmaCjqhzwiy223bZFyJLkNWa3sl+YYjALf3G4ZxwIB8j56DNYU7Sm6JPa05B nkYb4X/7PTjoVvo8nOLQ9xrg1m1UOUzzQANSc= Received: by 10.223.79.1 with SMTP id n1mr1017147fak.36.1297458341988; Fri, 11 Feb 2011 13:05:41 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id e6sm620418fav.8.2011.02.11.13.05.40 (version=SSLv3 cipher=OTHER); Fri, 11 Feb 2011 13:05:41 -0800 (PST) Message-ID: <4D55A4A2.7020900@gmail.com> Date: Fri, 11 Feb 2011 23:05:38 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 21:05:29 -0000 Hi Steve, [Cross-posted to ipsecme] I have always wondered about these sequence numbers, and the concept of anti-replay in IPsec. - IPsec is architecturally a "plug-in replacement" for IP. And IP allows for arbitrary packet deletion, duplication and reordering. - Anti-replay counters are giving us no end of trouble in clustered environments (e.g. http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/). - IPsec (unfortunately) does not have an application API, at least in most implementations. Such an API might indeed have put this feature to good use. - And lastly, IPsec anti-replay is optional, which signifies to me that it's always been an iffy feature. I have looked at RFC 4301 again (the IPsec architecture), and it provides only weak justification for this feature. Can you please point me to a more convincing reasoning? Thanks, Yaron > ------------------------------ > > Message: 2 > Date: Thu, 10 Feb 2011 19:51:08 -0500 > From: Steven Bellovin > Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet > loss/reordering > To: Eric Rescorla > Cc: Paul Hoffman, tls@ietf.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On Feb 10, 2011, at 3:03 21PM, Eric Rescorla wrote: > >> On Thu, Feb 10, 2011 at 12:03 PM, Eric Rescorla wrote: >>> On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman wrote: >>>> On 2/10/11 9:49 AM, Matt McCutchen wrote: >>>>> >>>>> Here's an issue that might be worth adding as a security consideration >>>>> in the next version of the DTLS specification. It may affect IPsec too; >>>>> I haven't looked into that. Thoughts? >>>> >>>> I disagree with this suggestion, at least as it is proposed. >>>> >>>>> DTLS does not prevent an attacker from dropping or reordering records. >>>>> Datagram applications are generally designed to tolerate random packet >>>>> loss and reordering, but care must be taken to ensure that adversarial >>>>> loss and reordering cannot break the desired higher-level security >>>>> properties. >>>> >>>> That "care" sounds like it is care in the DTLS-using protocol, but no >>>> suggestion is given how such a protocol can show care. This makes the >>>> suggestion little more than "be careful", which is not useful. >>> >>> DTLS does deliver order information, of course. It just doesn't impose >>> reordering. >>> >>> Perhaps the take-home for DTLS itself is that it would be nice if >>> packets came with >>> their sequence numbers attached. >>> >> >> In the API, I mean. >> > Given the importance of sequence numbers for IPsec, I very much agree. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From geoffk@geoffk.org Fri Feb 11 13:45:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8733A6A4F for ; Fri, 11 Feb 2011 13:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1+ZOm-Veubz for ; Fri, 11 Feb 2011 13:45:44 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id C91E13A6A1A for ; Fri, 11 Feb 2011 13:45:44 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 6903F33D17A; Fri, 11 Feb 2011 21:45:59 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Nikos Mavrogiannopoulos References: <4D54F0D7.4040205@gnutls.org> From: Geoffrey Keating Date: 11 Feb 2011 13:45:59 -0800 In-Reply-To: <4D54F0D7.4040205@gnutls.org> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org" Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 21:45:46 -0000 Nikos Mavrogiannopoulos writes: > Hello, > After some discussion with Sean Turner, I've decided to > try re-shaping the old draft-ietf-tls-ssl-version3 draft to > be publish it as a historic rfc. The draft I came up with is at: > http://tools.ietf.org/html/draft-mavrogiannopoulos-ssl-version3-00 > > I've converted the original document to xml format so some > formatting might not be exactly the same. Apart from that > other changes to the original are: > * stray references to documents [IP],[SSL-2] were defined. > * stray reference to RC4 was replaced with RSADSI. > * Appendix A.1.1 was renumbered as A.2 as it was not a subsection of > A.1. > * Section that discussed patents was removed (all patents discussed > are expired). > > Do you think this draft should be adopted by the WG and be published as > historic? I support this, but would suggest that there should be something warning readers that SSLv3 has known security issues and so should not be used by new implementations. From geoffk@geoffk.org Fri Feb 11 13:49:05 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A693A699F for ; Fri, 11 Feb 2011 13:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1BK87RiStHl for ; Fri, 11 Feb 2011 13:49:04 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 897873A69DA for ; Fri, 11 Feb 2011 13:49:04 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B4F3633D17A; Fri, 11 Feb 2011 21:49:18 +0000 (UTC) Sender: geoffk@localhost.localdomain To: "Davies, Joshua" References: <4D4D04C8.1090307@gnutls.org> <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> From: Geoffrey Keating Date: 11 Feb 2011 13:49:18 -0800 In-Reply-To: Message-ID: Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org" Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 21:49:05 -0000 "Davies, Joshua" writes: > Which cipher suites? I just sent a client hello with > TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C) and tls.woodgrovebank.com > terminated the connection without responding with a server hello. If you connect to https://tls.woodgrovebank.com/Cipersuites.htm, it tells you which cipher suites it supports. It appears to support GCM only with ECDSA. From agl@google.com Fri Feb 11 14:45:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD373A69F0 for ; Fri, 11 Feb 2011 14:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUwVA2iO9v-R for ; Fri, 11 Feb 2011 14:45:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E8E9B3A67B8 for ; Fri, 11 Feb 2011 14:45:12 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p1BMjSqJ009208 for ; Fri, 11 Feb 2011 14:45:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297464328; bh=aMKj6+P3tS/RJng6GK0NKW5PmlM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=QHjrNtcLN3wTu4ziiyshguSKUAyC6OpZZRO5emR81V8M4xo+wt1eFRnzJO+kfxYQl UTjjPWg6g2sycRuybHIuQ== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by wpaz13.hot.corp.google.com with ESMTP id p1BMj5ib017967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 11 Feb 2011 14:45:27 -0800 Received: by yxt33 with SMTP id 33so1903578yxt.15 for ; Fri, 11 Feb 2011 14:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=thHbsQgvV/gEv2eLsTpbaKFymuf8j9lpXrKSQ4LH4SM=; b=fDUsABIakGC2eD3sMOl4mAnV+D9J9k/hk5waYsdvjKk1Gs/thmlfProLUy/CoO59mI lAgxK4lUaVgIUGZ18Xwg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KDlZ2O5ecf8lQl6u84ZZhhu8mPffVWg71niIO9LmyxCkmuet0puqjtAZBbOHJHBB/0 jAK4RoxRQcYXQKxdyOfQ== MIME-Version: 1.0 Received: by 10.150.95.17 with SMTP id s17mr1222604ybb.39.1297464326062; Fri, 11 Feb 2011 14:45:26 -0800 (PST) Received: by 10.151.153.7 with HTTP; Fri, 11 Feb 2011 14:45:25 -0800 (PST) In-Reply-To: References: <4D4D04C8.1090307@gnutls.org> <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 11 Feb 2011 17:45:25 -0500 Message-ID: From: Adam Langley To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Davies, Joshua" , "tls@ietf.org" Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 22:45:15 -0000 On Fri, Feb 11, 2011 at 4:49 PM, Geoffrey Keating wrote= : > If you connect to https://tls.woodgrovebank.com/Cipersuites.htm, it > tells you which cipher suites it supports. =C2=A0It appears to support GC= M > only with ECDSA. Although the certificate has expired: "Not After : Jan 26 00:29:01 2011 GMT= " AGL From mrex@sap.com Fri Feb 11 15:31:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EB73A69DC for ; Fri, 11 Feb 2011 15:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ossTGuFYbo9 for ; Fri, 11 Feb 2011 15:31:39 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6BA7E3A6838 for ; Fri, 11 Feb 2011 15:31:39 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1BNVbIp029413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Feb 2011 00:31:37 +0100 (MET) From: Martin Rex Message-Id: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Sat, 12 Feb 2011 00:31:35 +0100 (MET) In-Reply-To: from "Geoffrey Keating" at Feb 11, 11 01:45:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 23:31:40 -0000 Geoffrey Keating wrote: > > > > Do you think this draft should be adopted by the WG and be published as > > historic? I would consider it counter-productive to make such a document a WG item (I assume the WG would have to re-charter for it). There is not that much "to fix" about this document anyway, so an individual submission should be just fine. In my understanding "historic" is a classification, not a document type. --the document type ("track") would be Informational. Considering that a non-marginal fraction of the TLS protected communication actually negotiates protocol version {0x03,0x00}, there is not reason for a classification of "historic". > > I support this, but would suggest that there should be something > warning readers that SSLv3 has known security issues and so should not > be used by new implementations. Consider me highly confused. What specific security issues do you have in mind that are not either implementation (rather than protocol) issues other than the overly detailed alert codes that enabled timing attacks (Bleichebacher,Vaudeney) ? The latter would be easy to address with an implementation note. -Martin From touch@isi.edu Fri Feb 11 15:48:49 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AD43A69D1; Fri, 11 Feb 2011 15:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.832 X-Spam-Level: X-Spam-Status: No, score=-104.832 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R999rtvbCs87; Fri, 11 Feb 2011 15:48:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 902CD3A6838; Fri, 11 Feb 2011 15:48:48 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p1BNmRUY005939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 11 Feb 2011 15:48:27 -0800 (PST) Message-ID: <4D55CACB.6020306@isi.edu> Date: Fri, 11 Feb 2011 15:48:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Chris Newman References: <4CD76B1B.5030308@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Fri, 11 Feb 2011 15:54:28 -0800 Cc: Paul Hoffman , tls@ietf.org, tsvwg Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 23:48:50 -0000 FWIW, we have removed the text on this recommendation from this draft (a version will appear later today). However, I'd still appreciate resolving this issue, or at least clarifying the two different positions in detail, as part of a different draft that focuses on advise to how ports are used: http://tools.ietf.org/html/draft-touch-tsvwg-port-use-00 That doc will be updated in the next few days with more than just placeholders, and I'll include space for this debate there as well. FYI. Joe On 2/9/2011 6:12 PM, Chris Newman wrote: > I know I'm very late on this topic, but my position differs from others > so I'll comment. > > I can not deny that separate-port for SSL is simpler to implement on the > server side (having done both). Since the odds of security bugs > increases with the amount of code, I must conclude that separate-port > SSL is more secure for _implementers_ and _implementations_ for that > reason alone. > > However, I believe STARTTLS is more secure for _operators_ and > _administrators_. The separate port model creates an illusion that there > is a "secure" and "insecure" variant of the protocol and that a single > firewall setting magically makes the application secure. In general, > this is not true. Most servers have several security settings and the > default settings have to compromise between common practice, > secure-by-default practice, deployability, management complexity and > usability. There is, in general, no way to make a server installation > secure for a given site other than to understand the security settings > that server provides and set them properly. > > A protocol that uses STARTTLS thus has the advantage of forcing the > administrator/operator to look at the server's security settings to make > the installation secure, thus increasing the odds of success relative to > the separate-port model where an administrator might falsely assume > they're done after blocking the non-SSL port. > > While I think the judgment call is close for > separate-port-SSL-vs-STARTTLS, I prefer STARTTLS weighing all the factors. > > And for the record I'm responsible for TLS integration into a server > product and maintain all the relevant code and find STARTTLS maintenance > annoying. I'm also author of RFC 2595, so perhaps that balances out my > bias as an implementer. ;-) > > It's also my opinion that a high quality client should use a "latched" > model by default. If the client ever sees "STARTTLS" advertised and > negotiates it successfully, the client records the fact in a local > operations file that it used STARTTLS with server X. Subsequent to that > it will require STARTTLS with server X and not back off. I will note > that implementation strategy is simpler with the STARTTLS model than > with the separate port model. > > As an aside, there is no interoperable specification for use of TLS > client certificate authentication with the "pops" protocol (does it > start in not-authenticated state and require an AUTH EXTERNAL, or does > it start in authenticated state -- no way to distinguish the two cases). > However, use of TLS client certificate authentication with POP+STLS > according to written rules in RFC 2595 does interoperate. > > - Chris > > --On November 8, 2010 11:14:35 +0800 Magnus Westerlund > wrote: > >> TLS experts, >> >> There currently a WG last call ongoing in on the IANA Procedures for the >> Management of the Service Name and Transport Protocol Port Number >> Registry update document. >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ >> >> A WG last call comment on this document was raised by Paul Hoffman: >> http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html >> >> My summary of that comment is that STARTTLS for SMTP (RFC 3207) has >> shown to have some security issues, be complexer to implement than using >> two ports and thus less popular. Thus the registration rules should be >> less restrictive in assigning an additional port for TLS version of >> services/applications/protocols. >> >> The downside of less restrictive port allocation rules is that the port >> space will be consumed at a higher rate. Thus there is need to determine >> what is the most suitable trade-off here. >> >> Clearly if the security issues are serious when one multiplex TLS and >> non-secured version of the protocol on the same port we must allow such >> port allocations. However if the issues are minor and the primarily >> issue is implementation complexity then saving the limited port space is >> probably more important. >> >> Your input into these questions would be very appreciated. >> >> Thanks >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > From geoffk@geoffk.org Fri Feb 11 16:32:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B1C3A6A21 for ; Fri, 11 Feb 2011 16:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS2t9oc8ZeeD for ; Fri, 11 Feb 2011 16:32:35 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id EE04E3A69D1 for ; Fri, 11 Feb 2011 16:32:35 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id F3EAC33D17A; Sat, 12 Feb 2011 00:32:50 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 11 Feb 2011 16:32:50 -0800 In-Reply-To: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> Message-ID: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:32:36 -0000 Martin Rex writes: > Geoffrey Keating wrote: > > > > > > Do you think this draft should be adopted by the WG and be published as > > > historic? > > I would consider it counter-productive to make such a document a > WG item (I assume the WG would have to re-charter for it). > > There is not that much "to fix" about this document anyway, so > an individual submission should be just fine. > > In my understanding "historic" is a classification, not a document type. > --the document type ("track") would be Informational. > > Considering that a non-marginal fraction of the TLS protected communication > actually negotiates protocol version {0x03,0x00}, there is not reason for > a classification of "historic". > > > > > > I support this, but would suggest that there should be something > > warning readers that SSLv3 has known security issues and so should not > > be used by new implementations. > > Consider me highly confused. > > What specific security issues do you have in mind that are not either > implementation (rather than protocol) issues other than the overly > detailed alert codes that enabled timing attacks (Bleichebacher,Vaudeney) ? Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1. There are a number of other things that are questionable but not flaws as such, like the 'should' for SSLv2, and the export cipher suites. I guess use of MD5 and SHA-1 also counts as 'questionable' nowadays. > The latter would be easy to address with an implementation note. Writing such a note might get quite complex and probably deserves a RFC of its own... I was thinking of something simpler, just noting that this protocol has known flaws which are addressed in current versions. I'm good with either approach. Since I'm looking at the document, I'd also suggest removing this paragraph: Note: Additional cipher suites will be considered for implementation only with submission of notarized letters from two independent entities. Netscape Communications Corp. will act as an interim registration office, until a public standards body assumes control of SSL. and also remove or update the 'Reserved port assignments' section. From mrex@sap.com Fri Feb 11 16:34:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEA73A69D1 for ; Fri, 11 Feb 2011 16:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.155 X-Spam-Level: X-Spam-Status: No, score=-10.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6lKybBNZ-z8 for ; Fri, 11 Feb 2011 16:34:01 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EC7D63A6839 for ; Fri, 11 Feb 2011 16:34:00 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1C0Y8Qf006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Feb 2011 01:34:13 +0100 (MET) From: Martin Rex Message-Id: <201102120034.p1C0Y8r8018017@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Sat, 12 Feb 2011 01:34:08 +0100 (MET) In-Reply-To: from "Geoffrey Keating" at Feb 11, 11 01:49:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: Joshua.Davies@travelocity.com, tls@ietf.org Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:34:02 -0000 Geoffrey Keating wrote: > > "Davies, Joshua" writes: > > > Which cipher suites? I just sent a client hello with > > TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C) and tls.woodgrovebank.com > > terminated the connection without responding with a server hello. > > If you connect to https://tls.woodgrovebank.com/Cipersuites.htm, it > tells you which cipher suites it supports. It appears to support GCM > only with ECDSA. The information at https://tls.woodgrovebank.com/Ciphersuites.htm seems to contain errors (but otherwise align with productive SChannel): It says: TLS_RSA_WITH_AES_128_CBC_SHA 0x002F All Supported but as previously discussed, SChannel unnecessarily aborts when receiving only this ciphersuite along with ClientHello.client_version = {0x03,0x00} TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x000a works with client_version {0x03,0x00} -Martin From mrex@sap.com Fri Feb 11 17:26:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88E03A6A72 for ; Fri, 11 Feb 2011 17:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.168 X-Spam-Level: X-Spam-Status: No, score=-10.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO-5It897HZM for ; Fri, 11 Feb 2011 17:26:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 8D9D93A6A21 for ; Fri, 11 Feb 2011 17:26:40 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1C1Qqol004926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Feb 2011 02:26:52 +0100 (MET) From: Martin Rex Message-Id: <201102120126.p1C1QpmH021132@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Sat, 12 Feb 2011 02:26:51 +0100 (MET) In-Reply-To: from "Geoffrey Keating" at Feb 11, 11 04:32:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 01:26:41 -0000 Geoffrey Keating wrote: > > > > > > > > I support this, but would suggest that there should be something > > > warning readers that SSLv3 has known security issues and so should not > > > be used by new implementations. > > > > Consider me highly confused. > > > > What specific security issues do you have in mind that are not either > > implementation (rather than protocol) issues other than the overly > > detailed alert codes that enabled timing attacks (Bleichebacher,Vaudeney) ? > > Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1. Padding? Does the MAC include the _entire_ padding in any TLS version? MAC-ing only the payload and not MAC-ing the padding may leak information about the size of the padding. A possible solution is to hash the payload, copy the hash context, hash the padding and finalize only the copied context of the hash over the payload. I don't remember any TLS specs hinting about this. > > There are a number of other things that are questionable but not flaws > as such, like the 'should' for SSLv2, and the export cipher suites. I > guess use of MD5 and SHA-1 also counts as 'questionable' nowadays. There is a difference between "could have done better" and "flawed". I'm not aware of anything that would make me sleep bad. I'm actually wondering why TLSv1.2 still truncates the finished messages to 12 octets, instead of truncating to 20 octets. > > > The latter would be easy to address with an implementation note. > > Writing such a note might get quite complex and probably deserves a > RFC of its own... I think it would be simple. If there are pitfalls that can be avoided, a few implementation hints should be perfectly sufficient. > > I was thinking of something simpler, just noting > that this protocol has known flaws which are addressed in current > versions. I'm good with either approach. A brief "this protocol has known flaws which are addressed in current versions" statement, without listing the issues and possible mitigations, looks somewhat like FUD to me. I would prefer to spend time on re-publication of the SSLv3 spec as an informational RFC only if it adds value for the community. -Martin From geoffk@geoffk.org Fri Feb 11 17:37:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00DA3A6A50 for ; Fri, 11 Feb 2011 17:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HejDTGr-Kzl for ; Fri, 11 Feb 2011 17:37:30 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 7E1923A6A21 for ; Fri, 11 Feb 2011 17:37:30 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 8481B33D17A; Sat, 12 Feb 2011 01:37:45 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <201102120126.p1C1QpmH021132@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 11 Feb 2011 17:37:45 -0800 In-Reply-To: <201102120126.p1C1QpmH021132@fs4113.wdf.sap.corp> Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 01:37:32 -0000 Martin Rex writes: > Geoffrey Keating wrote: > > > > > > > > > > > I support this, but would suggest that there should be something > > > > warning readers that SSLv3 has known security issues and so should not > > > > be used by new implementations. > > > > > > Consider me highly confused. > > > > > > What specific security issues do you have in mind that are not either > > > implementation (rather than protocol) issues other than the overly > > > detailed alert codes that enabled timing attacks (Bleichebacher,Vaudeney) ? > > > > Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1. > > Padding? Does the MAC include the _entire_ padding in any TLS version? > MAC-ing only the payload and not MAC-ing the padding may leak information > about the size of the padding. These, from RFC4346: - The implicit Initialization Vector (IV) is replaced with an explicit IV to protect against CBC attacks [CBCATT]. - Handling of padding errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks. From n.mavrogiannopoulos@gmail.com Sat Feb 12 01:00:26 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AF03A688D for ; Sat, 12 Feb 2011 01:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTMMoxeAZ-0z for ; Sat, 12 Feb 2011 01:00:25 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5DD303A68F4 for ; Sat, 12 Feb 2011 01:00:25 -0800 (PST) Received: by eyd10 with SMTP id 10so1848866eyd.31 for ; Sat, 12 Feb 2011 01:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=P6FYMfN4QmL3u6SwnHYX1h/Dv8BmdGT6uxel3EeU9Mk=; b=uNf4myzQQOsFhEXwfM+yUUp0m1dIZmr3ODhMx1h/jJYs6Ingk8K7tVnoyWRBD1oH4u bItkW/7vdIiz2fx/r7MZPuMA9ADVBP34eNc/Hiue6ILM7s0LJtI/26WGgEVfbtIv7uAs 3qQdHs4wyqnjvZ5Lgqajn5hjDpdw9HbLoiNrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=tdpknk3J4OaBgLQ0wth4MnaforSBhVozHDqezAlCtevsHhL/nRJGaiJbCyIRD475S+ P7Gbtu5wrL+qByvNj3VXYk5Xug4yTONeMJ8XvlPdvkiJ1yArnZRAgWU2+8nKpH7CZbRI 5aFsoO4hHGktM1TLyc7IDclPoBeZx7HPGQGcU= Received: by 10.213.27.78 with SMTP id h14mr1467655ebc.17.1297501241539; Sat, 12 Feb 2011 01:00:41 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id u1sm221021eeh.10.2011.02.12.01.00.38 (version=SSLv3 cipher=OTHER); Sat, 12 Feb 2011 01:00:40 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D564C35.1050007@gnutls.org> Date: Sat, 12 Feb 2011 10:00:37 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: mrex@sap.com References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> In-Reply-To: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 09:00:26 -0000 On 02/12/2011 12:31 AM, Martin Rex wrote: >>> Do you think this draft should be adopted by the WG and be >>> published as historic? > I would consider it counter-productive to make such a document a WG > item (I assume the WG would have to re-charter for it). There is not > that much "to fix" about this document anyway, so an individual > submission should be just fine. In my understanding "historic" is a > classification, not a document type. --the document type ("track") > would be Informational. Considering that a non-marginal fraction of > the TLS protected communication actually negotiates protocol version > {0x03,0x00}, there is not reason for a classification of "historic". Ah, I see what you mean here... The "historic" is mostly because the protocol is already obsoleted (by TLS 1.x), even if it is still in use. I don't think the historic category refers to the actual protocol usage on the internet. regards, Nikos From ralph-tls-tum@ralphholz.de Sat Feb 12 03:24:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E84B3A69B5 for ; Sat, 12 Feb 2011 03:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz72MfPv7d58 for ; Sat, 12 Feb 2011 03:24:29 -0800 (PST) Received: from serverkommune.de (serverkommune.de [88.198.12.136]) by core3.amsl.com (Postfix) with ESMTP id 5079C3A6981 for ; Sat, 12 Feb 2011 03:24:28 -0800 (PST) Received: (qmail 26661 invoked by uid 89); 12 Feb 2011 12:24:44 +0100 Received: from serverkommune.de (HELO ?192.168.178.36?) (ralph@serverkommune.de@88.198.12.136) by serverkommune.de with ESMTPA; 12 Feb 2011 12:24:44 +0100 Message-ID: <4D566DFB.8040603@ralphholz.de> Date: Sat, 12 Feb 2011 12:24:43 +0100 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> In-Reply-To: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 11:24:30 -0000 Hi, > Considering that a non-marginal fraction of the TLS protected communication > actually negotiates protocol version {0x03,0x00}, there is not reason for > a classification of "historic". Not intending to take sides here, but from our own observations at a large ISP, SSLv3 seems to be chosen as a protocol version only for a very marginal fraction of connections. I can't quite remember the numbers, but it was something around 0.1% or less. I can look it up, if you want. -- Regards, Ralph From hallam@gmail.com Sat Feb 12 06:04:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE973A6AB9 for ; Sat, 12 Feb 2011 06:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOOjIIJk-Oda for ; Sat, 12 Feb 2011 06:04:56 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id AA2673A6A9A for ; Sat, 12 Feb 2011 06:04:55 -0800 (PST) Received: by yie19 with SMTP id 19so1631267yie.31 for ; Sat, 12 Feb 2011 06:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YSlCNCOoqYR2JMNAZiJSHGWZ7CwHwVA4XeviNgfn0lU=; b=Cg4DkfiAJgN0BHD+m4sOmfn31tXwO56LtuoP1twmQXrH4OcZEHXGjElJp01S0aVIcI GoSXIURTPSiqFiQgFyjZK6PaH2qN+RPiqXT/vHNxYJxaJqye7J+JP9Tkuss28SiW6/Tf CE1D7nAzWiumrGUJ/5dlYe5iSDDcrnXQgBiXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=katmFlYBwnJJB3G7WeDUNnC8SV5tBMVzH2shLfYu40Drr+PsbE5ZfBqgsbsZrb4jhM Ce/ZMTQQBQ68GB439clZfkly3DBAWao7ysLQ43W3JfGzLdI7vv8D/te0urGW5NLfSaeP LPQrobzMCjVb8sQZz57CmzynvB57fB6NITny8= MIME-Version: 1.0 Received: by 10.100.37.4 with SMTP id k4mr716449ank.176.1297519512890; Sat, 12 Feb 2011 06:05:12 -0800 (PST) Received: by 10.100.244.38 with HTTP; Sat, 12 Feb 2011 06:05:12 -0800 (PST) In-Reply-To: <201102120126.p1C1QpmH021132@fs4113.wdf.sap.corp> References: <201102120126.p1C1QpmH021132@fs4113.wdf.sap.corp> Date: Sat, 12 Feb 2011 09:05:12 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e644d652a7ac3b049c164d54 Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 14:04:57 -0000 --0016e644d652a7ac3b049c164d54 Content-Type: text/plain; charset=ISO-8859-1 Wouldn't it make more sense to set the status to Deprecated? Historic is appropriate for stuff that is never used. The point here is to tell people to stop using it. And all the draft needs to say is SSL3.0 has known security issues and TLS is the current protocol. On Fri, Feb 11, 2011 at 8:26 PM, Martin Rex wrote: > Geoffrey Keating wrote: > > > > > > > > > > > I support this, but would suggest that there should be something > > > > warning readers that SSLv3 has known security issues and so should > not > > > > be used by new implementations. > > > > > > Consider me highly confused. > > > > > > What specific security issues do you have in mind that are not either > > > implementation (rather than protocol) issues other than the overly > > > detailed alert codes that enabled timing attacks > (Bleichebacher,Vaudeney) ? > > > > Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1. > > Padding? Does the MAC include the _entire_ padding in any TLS version? > MAC-ing only the payload and not MAC-ing the padding may leak information > about the size of the padding. > > A possible solution is to hash the payload, copy the hash context, > hash the padding and finalize only the copied context of the hash over > the payload. I don't remember any TLS specs hinting about this. > > > > > > There are a number of other things that are questionable but not flaws > > as such, like the 'should' for SSLv2, and the export cipher suites. I > > guess use of MD5 and SHA-1 also counts as 'questionable' nowadays. > > There is a difference between "could have done better" and "flawed". > > I'm not aware of anything that would make me sleep bad. > I'm actually wondering why TLSv1.2 still truncates the finished > messages to 12 octets, instead of truncating to 20 octets. > > > > > > The latter would be easy to address with an implementation note. > > > > Writing such a note might get quite complex and probably deserves a > > RFC of its own... > > I think it would be simple. If there are pitfalls that can be avoided, > a few implementation hints should be perfectly sufficient. > > > > > > I was thinking of something simpler, just noting > > that this protocol has known flaws which are addressed in current > > versions. I'm good with either approach. > > > A brief "this protocol has known flaws which are addressed in current > versions" statement, without listing the issues and possible mitigations, > looks somewhat like FUD to me. > > > I would prefer to spend time on re-publication of the SSLv3 spec as > an informational RFC only if it adds value for the community. > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Website: http://hallambaker.com/ --0016e644d652a7ac3b049c164d54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wouldn't it make more sense to set the status to Deprecated?

Historic is appropriate for stuff that is never used. The point he= re is to tell people to stop using it.=A0

And all = the draft needs to say is SSL3.0 has known security issues and TLS is the c= urrent protocol.

On Fri, Feb 11, 2011 at 8:26 PM, Martin Rex = <mrex@sap.com><= /span> wrote:
Geoffrey Keating wrote:
> >
> > >
> > > I support this, but would suggest that there should be somet= hing
> > > warning readers that SSLv3 has known security issues and so = should not
> > > be used by new implementations.
> >
> > Consider me highly confused.
> >
> > What specific security issues do you have in mind that are not ei= ther
> > implementation (rather than protocol) issues other than the overl= y
> > detailed alert codes that enabled timing attacks (Bleichebacher,V= audeney) ?
>
> Yes, I was thinking of the IV and padding attacks fixed in TLS 1.1.
Padding? =A0Does the MAC include the _entire_ padding in any TLS vers= ion?
MAC-ing only the payload and not MAC-ing the padding may leak information about the size of the padding.

A possible solution is to hash the payload, copy the hash context,
hash the padding and finalize only the copied context of the hash over
the payload. =A0 I don't remember any TLS specs hinting about this.


>
> There are a number of other things that are questionable but not flaws=
> as such, like the 'should' for SSLv2, and the export cipher su= ites. =A0I
> guess use of MD5 and SHA-1 also counts as 'questionable' nowad= ays.

There is a difference between "could have done better" and = "flawed".

I'm not aware of anything that would make me sleep bad.
I'm actually wondering why TLSv1.2 still truncates the finished
messages to 12 octets, instead of truncating to 20 octets.

>
> > The latter would be easy to address with an implementation note.<= br> >
> Writing such a note might get quite complex and probably deserves a > RFC of its own...

I think it would be simple. =A0If there are pitfalls that can be avoi= ded,
a few implementation hints should be perfectly sufficient.


>
> I was thinking of something simpler, just noting
> that this protocol has known flaws which are addressed in current
> versions. =A0I'm good with either approach.


A brief "this protocol has known flaws which are addressed in cu= rrent
versions" statement, without listing the issues and possible mitigatio= ns,
looks somewhat like FUD to me.


I would prefer to spend time on re-publication of the SSLv3 spec as
an informational RFC only if it adds value for the community.


-Martin
__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



--
Website: http://hallambaker.com/

--0016e644d652a7ac3b049c164d54-- From yngve@opera.com Sat Feb 12 06:32:34 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF473A698F for ; Sat, 12 Feb 2011 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOUKwX76aOao for ; Sat, 12 Feb 2011 06:32:33 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id C22633A696B for ; Sat, 12 Feb 2011 06:32:32 -0800 (PST) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1CEWm9L015435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 12 Feb 2011 14:32:49 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> <4D566DFB.8040603@ralphholz.de> Date: Sat, 12 Feb 2011 15:32:57 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <4D566DFB.8040603@ralphholz.de> User-Agent: Opera Mail/10.63 (Win32) X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81 Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 14:32:34 -0000 On Sat, 12 Feb 2011 12:24:43 +0100, Ralph Holz wrote: > Hi, > >> Considering that a non-marginal fraction of the TLS protected >> communication >> actually negotiates protocol version {0x03,0x00}, there is not reason >> for >> a classification of "historic". > > Not intending to take sides here, but from our own observations at a > large ISP, SSLv3 seems to be chosen as a protocol version only for a > very marginal fraction of connections. I can't quite remember the > numbers, but it was something around 0.1% or less. I can look it up, if > you want. Among sites probed by my "TLS Prober" the number of SSLv3-only servers is about 1.0%. See http://my.opera.com/securitygroup/blog/2010/11/04/a-few-results-from-the-tls-prober for more information. Please note that the article says that the SSL v3-only number at the time was 1.5%, later investigation revealed that 0.5 percentage-points of the probed servers were actually TLS 1.0 servers that required the Record Protocol Version field and the Client Hello Version field to both be 3.1 to select TLS 1.0; the prober was generally using 3.0 as the Record Protocol version. The servers were therefore incorrectly classifies as SSL v3-only. The detection problem has since been fixed. For reference, the number (*not* percentage) of TLS 1.2 servers in the last run on Monday was 21 (of 378390). Which is up from the two(2) testservers detected when probing started almost a year ago. The TLS 1.1 count was 108. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From paul.hoffman@vpnc.org Sat Feb 12 08:23:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B6B3A6AC3 for ; Sat, 12 Feb 2011 08:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.138 X-Spam-Level: X-Spam-Status: No, score=-100.138 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJm6iZq3Ec9W for ; Sat, 12 Feb 2011 08:23:00 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3DFE73A699E for ; Sat, 12 Feb 2011 08:23:00 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1CGNHRM053266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 12 Feb 2011 09:23:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D56B3F5.5000209@vpnc.org> Date: Sat, 12 Feb 2011 08:23:17 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <201102120126.p1C1QpmH021132@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 16:23:01 -0000 On 2/12/11 6:05 AM, Phillip Hallam-Baker wrote: > Wouldn't it make more sense to set the status to Deprecated? There is currently no such status for RFCs; see RFC 2026. Having the TLS WG attempt to modify RFC 2026 for this one document seems like a large use of energy. From ralph-tls-tum@ralphholz.de Sat Feb 12 11:20:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82293A6A77 for ; Sat, 12 Feb 2011 11:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBv1a9Oan89q for ; Sat, 12 Feb 2011 11:20:40 -0800 (PST) Received: from serverkommune.de (serverkommune.de [88.198.12.136]) by core3.amsl.com (Postfix) with ESMTP id AB7363A6824 for ; Sat, 12 Feb 2011 11:20:39 -0800 (PST) Received: (qmail 17159 invoked by uid 89); 12 Feb 2011 20:20:55 +0100 Received: from serverkommune.de (HELO ?192.168.178.36?) (ralph@serverkommune.de@88.198.12.136) by serverkommune.de with ESMTPA; 12 Feb 2011 20:20:55 +0100 Message-ID: <4D56DD96.7040205@ralphholz.de> Date: Sat, 12 Feb 2011 20:20:54 +0100 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> <4D566DFB.8040603@ralphholz.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 19:20:40 -0000 Hi, > Among sites probed by my "TLS Prober" the number of SSLv3-only servers > is about 1.0%. > [...] Interesting. The difference here may be that you are probing servers (the Alexa Top 1M list, as I take it) and the ISP is observing what version established connections actually use. I am currently away from my office, but I will be back in 10 days and can find out then. Maybe the numbers are not actually off. > For reference, the number (*not* percentage) of TLS 1.2 servers in the > last run on Monday was 21 (of 378390). Which is up from the two(2) > testservers detected when probing started almost a year ago. The TLS 1.1 > count was 108. Agreed, it's a vanishing percentage. -- Regards, Ralph From ynir@checkpoint.com Sat Feb 12 11:31:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222C13A6AD8 for ; Sat, 12 Feb 2011 11:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pdhPFHUWtIr for ; Sat, 12 Feb 2011 11:31:46 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 058ED3A6824 for ; Sat, 12 Feb 2011 11:31:45 -0800 (PST) X-CheckPoint: {4D56E033-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1CJW2ZE029878 for ; Sat, 12 Feb 2011 21:32:02 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Sat, 12 Feb 2011 21:32:02 +0200 From: Yoav Nir To: "tls@ietf.org" Date: Sat, 12 Feb 2011 21:32:01 +0200 Thread-Topic: [TLS] publishing SSL 3.0 as historic Thread-Index: AcvK64XabNOniSPpSzCqtfKw4/3d/Q== Message-ID: <6D932F0C-3473-4DD5-93E7-16FEA9B0A39E@checkpoint.com> References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> <4D566DFB.8040603@ralphholz.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 19:31:47 -0000 On Feb 12, 2011, at 4:32 PM, Yngve N. Pettersen (Developer Opera Software A= SA) wrote: > On Sat, 12 Feb 2011 12:24:43 +0100, Ralph Holz =20 > wrote: >=20 >> Hi, >>=20 >>> Considering that a non-marginal fraction of the TLS protected =20 >>> communication >>> actually negotiates protocol version {0x03,0x00}, there is not reason = =20 >>> for >>> a classification of "historic". >>=20 >> Not intending to take sides here, but from our own observations at a >> large ISP, SSLv3 seems to be chosen as a protocol version only for a >> very marginal fraction of connections. I can't quite remember the >> numbers, but it was something around 0.1% or less. I can look it up, if >> you want. >=20 > Among sites probed by my "TLS Prober" the number of SSLv3-only servers is= =20 > about 1.0%. >=20 Yes, but among clients, the latest figures I've heard, 20% were still IE6, = and that by default supports only SSLv2 and SSLv3, so the connections end u= p being SSLv3. That 0.1% figure seems very low to me. From n.mavrogiannopoulos@gmail.com Sun Feb 13 00:35:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F143A6B57 for ; Sun, 13 Feb 2011 00:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrnefMYiZ994 for ; Sun, 13 Feb 2011 00:35:24 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3BC2E3A6A94 for ; Sun, 13 Feb 2011 00:35:23 -0800 (PST) Received: by ewy8 with SMTP id 8so2112688ewy.31 for ; Sun, 13 Feb 2011 00:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=ugmAaNwYz9u7MoU8CQNK68oCkdXic5P8V2kaB+BoDLU=; b=C2Oaiqgzmg2b4twf6sk2/eXhlKo78oRn+h8X+QFt6glB3VPFb4C7BZnxq9ecmwV7WO PC9mI53EER/IWSEChG/0dnRfwvs/WJF/UsXogdxopf43nHfIk5fl7EgReLYsd9cyrfic /+nXZ4t7WEHPPwPspQPPbp7yuXPCbUflub4o8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=D3e3Ljvpfde1dVKZbqJed0paRY4halKKPdEOrJzjCLlliasCsuHrq13coHwkWmOgcH 8l144c83Tygx12IzQI7rT5SZdUJAZzYqg7tZ1y9DE+112bvBQ0WqxIaML0oFNEV8s0Wh oRFIMkjHKgbQJIp1o3h1MJaKCMkXsYAAw+bKk= Received: by 10.213.26.15 with SMTP id b15mr2485885ebc.16.1297586142996; Sun, 13 Feb 2011 00:35:42 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id q52sm1207582eei.9.2011.02.13.00.35.41 (version=SSLv3 cipher=OTHER); Sun, 13 Feb 2011 00:35:41 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D5797DF.7070405@gnutls.org> Date: Sun, 13 Feb 2011 09:35:43 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Geoffrey Keating References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 08:35:26 -0000 On 02/12/2011 01:32 AM, Geoffrey Keating wrote: > Writing such a note might get quite complex and probably deserves a > RFC of its own... I was thinking of something simpler, just noting > that this protocol has known flaws which are addressed in current > versions. I'm good with either approach. > Since I'm looking at the document, I'd also suggest removing this paragraph: > Note: Additional cipher suites will be considered for implementation > only with submission of notarized letters from two independent > entities. Netscape Communications Corp. will act as an interim > registration office, until a public standards body assumes control of > SSL. Indeed this note might deserve to be removed... > and also remove or update the 'Reserved port assignments' section. Since this is a historic document, it might be nice for this section to stay to indicate how SSL was initially used. I also would like to minimize editing/removal of text, because I want to keep the original author's names, and it would be unfair to publish a different text. regards, Nikos From paul.hoffman@vpnc.org Sun Feb 13 08:12:09 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9393A6A11 for ; Sun, 13 Feb 2011 08:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.134 X-Spam-Level: X-Spam-Status: No, score=-100.134 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R71VYzgep9zc for ; Sun, 13 Feb 2011 08:12:08 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DB3793A6A0F for ; Sun, 13 Feb 2011 08:12:08 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1DGCShC096372 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 13 Feb 2011 09:12:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D5802ED.60501@vpnc.org> Date: Sun, 13 Feb 2011 08:12:29 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> <4D5797DF.7070405@gnutls.org> In-Reply-To: <4D5797DF.7070405@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 16:12:09 -0000 On 2/13/11 12:35 AM, Nikos Mavrogiannopoulos wrote: > I also would like to minimize editing/removal of text, > because I want to keep the original author's names, and > it would be unfair to publish a different text. Yes, but this document could *really* use a small subsection near the beginning of the Introduction saying why the RFC is being published in 2011, and saying what the diffs are from the earlier document. From SRS0=SB7s=VL=acm.org=bmoeller@srs.kundenserver.de Mon Feb 14 00:47:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEEC3A6A6C for ; Mon, 14 Feb 2011 00:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba-f57q5AdEd for ; Mon, 14 Feb 2011 00:47:26 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 173B73A690E for ; Mon, 14 Feb 2011 00:47:25 -0800 (PST) Received: from dhcp-172-28-208-167.zrh.corp.google.com ([74.125.57.36]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lkzrh-1QPKuU1JY5-00aUf0; Mon, 14 Feb 2011 09:47:47 +0100 From: Bodo Moeller To: mrex@sap.com In-Reply-To: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> References: <201102112331.p1BNVZbN013815@fs4113.wdf.sap.corp> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Feb 2011 09:47:46 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V02:K0:nBU12XFC68gpuu1hoiAJPT96ZcHfEOoexBrZzMuIoh6 erNWgGzHNZC/JsodhZQEAEYTrZhe8Qvihu7k+YSPl6qZ1ubtNM P+myNjdHXuz4uHfOnO0m+AAaj3VLYtfktITGr09WWn9JND0Sls ESwsEfY2eEhmN+UVwGjqjsxshSrJgsu9JQSN2BdDt4leBqcCJ5 g8VYE/uF73XZszeTAymhQ== Cc: TLS Working Group Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 08:57:40 -0000 On Feb 12, 2011, at 12:31 AM, Martin Rex wrote: > Geoffrey Keating wrote: >> I support this, but would suggest that there should be something >> warning readers that SSLv3 has known security issues and so should >> not >> be used by new implementations. > What specific security issues do you have in mind that are not either > implementation (rather than protocol) issues other than the overly > detailed alert codes that enabled timing attacks > (Bleichebacher,Vaudeney) ? I can't speak for Geoffrey, but quite a while ago I found problems with the unspecified CBC padding bytes in SSL 3.0: something that's a potential implementation bug in TLS 1.0 is a protocol bug in SSL 3.0; see item 3 in http://www.openssl.org/~bodo/tls-cbc.txt. Of course, TLS 1.0 still has problems with its CBC ciphersuites (implicit IVs are bad), as documented in the TLS 1.1 specs (RFC 4346). Bodo From mrex@sap.com Mon Feb 14 05:47:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B183A6D48 for ; Mon, 14 Feb 2011 05:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.178 X-Spam-Level: X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8XwYFahbErE for ; Mon, 14 Feb 2011 05:47:05 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 351933A6D4C for ; Mon, 14 Feb 2011 05:47:05 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1EDlQx0013285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2011 14:47:26 +0100 (MET) From: Martin Rex Message-Id: <201102141347.p1EDlQGt022588@fs4113.wdf.sap.corp> To: ralph-tls-tum@ralphholz.de (Ralph Holz) Date: Mon, 14 Feb 2011 14:47:26 +0100 (MET) In-Reply-To: <4D566DFB.8040603@ralphholz.de> from "Ralph Holz" at Feb 12, 11 12:24:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 13:47:06 -0000 Ralph Holz wrote: > > > Considering that a non-marginal fraction of the TLS protected communication > > actually negotiates protocol version {0x03,0x00}, there is not reason for > > a classification of "historic". > > Not intending to take sides here, but from our own observations at a > large ISP, SSLv3 seems to be chosen as a protocol version only for a > very marginal fraction of connections. I can't quite remember the > numbers, but it was something around 0.1% or less. I can look it up, if > you want. That low number appears somewhat unrealistic to me. Microsoft Windows XP was shipped with SSLv2 enabled and TLSv1.0 disabled. The client market shares reported here: http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=10 are for Feb 14,2011: Windows XP 55.26% Windows 7 22.31% Windows Vista 11.66% and I would expect the fraction of the Windows XP users that still uses MSIE with the default configuration (SSLv2 enabled, TLSv1.0 disabled) is much larger than 0,1% Then there are a number of programmatic clients that use SSLv3. They may not cause much of the Web traffic, but they represent a non-marginal installed base. -Martin From mrex@sap.com Mon Feb 14 08:47:59 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491D33A6D43 for ; Mon, 14 Feb 2011 08:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhhPvxV38xvh for ; Mon, 14 Feb 2011 08:47:58 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 8D44F3A6A6D for ; Mon, 14 Feb 2011 08:47:57 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1EGmJal027859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 Feb 2011 17:48:19 +0100 (MET) From: Martin Rex Message-Id: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Mon, 14 Feb 2011 17:48:18 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:47:59 -0000 Dear implementors of TLSv1.2, The use of TLSv1.2 with DSA client certs using key lengths > 1024 as defined by FIPS 186-3 appears slightly underspecified. I would like to find out what current implementations of TLSv1.2 are doing -- and what they are doing when negotiating a protocol version less that {0x03,0x03}. The base protocol spec does not define what to do with a (L=2048,N=224), (L=2048,N=256) or (L=3072,N=256) DSA key from FIPS 186-3 in a client cert in TLSv1.1. rfc4492 Page 20 provides a hint for how to represent ECDSA signature values with hash algorithms other than SHA-1 but does not describe a means to indicate to the receiver, which other hash was actually used. I think it would be sensible to imply SHA-256 whenever the DSA key that is used for signature verification, does not allow creation of SHA-1 based signatures according to FIPS 186-3, but does allow creation of SHA-256 based signatures. Avoiding SHA-224 entirely would facilitate the Server Side verification of the CertificateVerify handshake message with DSA client certificates using key sizes > 1024 for protocol version < TLSv1.2. All TLS protocol specification (TLSv1.0->TLSv1.2 & SSLv3) share a text that is limited to SHA-1 in Section 4.7 Cryptographic Algorihms: In DSS, the 20 bytes of the SHA hash are run directly through the Digital Signing Algorithm with no additional hashing. This produces two values, r and s. The DSS signature is an opaque vector, as above, the contents of which are the DER encoding of: Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } The hint from rfc4492 "ECC Ciphersuites for TLS" about SHA/sha_hash not being limited to SHA-1/20-octets did not make it into TLSv1.2, so the situation is still somewhat undefined for the TLS protocol versions that are actually being negotiated and used on the internet. http://tools.ietf.org/html/rfc4492#page-20 ECDSA signatures are generated and verified as described in Section 5.10, and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. There was a change in the representation of a digitally signed element between TLSv1.2 and TLSv1.1&prior, which avoids the problem of not really knowing the signature algorithm that was used for (EC)DSA, in that digital signatures are now explicitly tagged in TLSv1.2: up to TLSv1.1 http://tools.ietf.org/html/rfc4346#section-4.7 In digital signing, one-way hash functions are used as input for a signing algorithm. A digitally-signed element is encoded as an opaque vector <0..2^16-1>, where the length is specified by the signing algorithm and key. TLSv1.2 http://tools.ietf.org/html/rfc5246#section-4.7 A digitally-signed element is encoded as a struct DigitallySigned: struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; The latter is building on the definitions from the SignatureAlgorithm TLSv1.2 extension: http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } SignatureAlgorithm; struct { HashAlgorithm hash; SignatureAlgorithm signature; } SignatureAndHashAlgorithm; -Martin From wtc@google.com Mon Feb 14 12:50:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9922A3A6C4F for ; Mon, 14 Feb 2011 12:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfJGzq3juiPn for ; Mon, 14 Feb 2011 12:50:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7D75B3A6ADB for ; Mon, 14 Feb 2011 12:50:13 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p1EKoZpl018935 for ; Mon, 14 Feb 2011 12:50:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297716636; bh=jd7cgFNkAPuKyzieVbjiET74zAk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=SY9EnIs6d2XwcFCexcnrHtFpoGVS5eaMQIPnypMYMgQGsnblmd+vDSK0WDNrS1BmN TIQdohBBnyizI1+tDYR4w== Received: from wyb38 (wyb38.prod.google.com [10.241.225.102]) by wpaz24.hot.corp.google.com with ESMTP id p1EKoXbR013339 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 14 Feb 2011 12:50:34 -0800 Received: by wyb38 with SMTP id 38so5430618wyb.2 for ; Mon, 14 Feb 2011 12:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RpYVfe/JN37hWc8GSN+CUjl5RSm59Ngkg//vZXm6HWg=; b=XkmGLvRKfVFfWcqiCvP39QrtksiTuYGr60LsFu4LeVMniCDpq6TJ52UZf4TlaiNxH9 kDyXp+orSyYGoC9salsw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B5L5uhqbUorFSIewHa2bw7hLjdM1Hocrpog09jmJmbi2VoyGtC2rRCq8SZ1BlkHllg qm68/5LS/U+aoHmQ3k+w== MIME-Version: 1.0 Received: by 10.216.160.1 with SMTP id t1mr60366wek.2.1297716632609; Mon, 14 Feb 2011 12:50:32 -0800 (PST) Received: by 10.216.6.81 with HTTP; Mon, 14 Feb 2011 12:50:31 -0800 (PST) In-Reply-To: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> References: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> Date: Mon, 14 Feb 2011 12:50:31 -0800 Message-ID: From: Wan-Teh Chang To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 20:50:14 -0000 The problem isn't limited to DSA client certs. DSA server certs have the same problem with DHE_DSS cipher suites. I believe TLS 1.2 assumes DSA keys are 1024 bits and needs to be updated for the larger DSA keys specified in FIPS 186-3. The avoid the need to buffer the handshake messages for the CertificateVerify message, the hash algorithm should ideally be chosen so that it can be reused for the verify_data in the Finished message. But clients with 1024-bit DSA client certs already need to either buffer the handshake messages or compute their SHA-1 hash, in addition to their SHA-256 hash for verify_data. Wan-Teh Chang From mrex@sap.com Mon Feb 14 14:30:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C231D3A6C30 for ; Mon, 14 Feb 2011 14:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAD6+tKAlqd6 for ; Mon, 14 Feb 2011 14:30:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 220B83A6997 for ; Mon, 14 Feb 2011 14:30:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1EMV8gB011913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2011 23:31:08 +0100 (MET) From: Martin Rex Message-Id: <201102142231.p1EMV7AD023546@fs4113.wdf.sap.corp> To: wtc@google.com (Wan-Teh Chang) Date: Mon, 14 Feb 2011 23:31:07 +0100 (MET) In-Reply-To: from "Wan-Teh Chang" at Feb 14, 11 12:50:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 22:30:50 -0000 Wan-Teh Chang wrote: > > The problem isn't limited to DSA client certs. DSA server certs have > the same problem with DHE_DSS cipher suites. There are two different issues. The handshake message hash that goes into the CertificateVerify when a client certificate is requested and used is orthogonal to DHE_DSS cipher suites. For the Handshake message hash, an implementation currently needs: sha-1 for SSLv3, TLSv1.0 & TLSv1.1 and for TLSv1.2 with DSA (L=1024,N=160) client cert md5 for SSLv3 sha-256 for TLSv1.2, and for TLSv1.x with DHE_DSS cipher suites and server certs with 2048 bits (FIPS 186-3) and for TLSv1.x with DSA client certs with 2048 bits (FIPS 186-3) certs with 2048 bits Requiring TLS implementations to also carry along SHA-224 hashes does not seem to make any sense. As it is described in FIPS 180-3, SHA-224 is equivalent to SHA-256 and SHA-384 is equivalent to SHA-512 as far as algorithmic strength and computational requirements are concerned -- in both cases the shorter hash uses the exact same algorithm, just with an differing initialization vector and truncation of the final output. When computing DSA signatures, the two integers "r" and "s" representing the DSA digital signature are the result of a modulo operation with the public prime q (see FIPS 186-3 section 4.6). And when computing the DSA signature with a SHA hash whose size exceeds the size of the public prime q, the hash is truncated first (see FIPS 186-3, Section 4.3, 2nd paragraph of page 16). Something similar may apply to ECDSA digital signatures. Hashes may need to be truncated with ECDSA as well (FIPS 186-3, Section 6.1.1, top of page 28). I'm not into crypto math and don't have X9.62 nor Schneiers Applied Cryptography around, so don't know what exact modulo operation applies to r&s for ECDSA (it's still r&s according to rfc4492). So when sha-224 was added (late) into TLSv1.2 (rfc5246) somewhere after March 04, 2008 http://www.ietf.org/mail-archive/web/tls/current/mail10.html it newly created a problem rather than solving one. While the "SignatureAndHashAlgorithm" tag should have applied only to the digital signatures created by TLS itself (in the KeyExchange and CertificateVerify handshake message, the defintion of the changed PDU for CertificateRequest says this: - Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. which IMHO is a pretty bad idea. It is an Anti-Agility requirement, precluding the PKI implementation outside of TLS that is doing the certificate path validation from evolving independent of TLS. This restriction is especially silly considering that this information can not even be conveyed if a protocol version below TLSv1.2 is negotiated. It is adding an interoperability impairment that did not exist in prior versions of TLS... > > I believe TLS 1.2 assumes DSA keys are 1024 bits and needs to be > updated for the larger DSA keys specified in FIPS 186-3. TLSv1.2 (rfc5246) does have a reference to a FIPS 186-3 draft. IMHO rather than rushing sha-224 into TLSv1.2 and creating pain and confusion, the above mentioned new restriction on signatures within certificates should have been removed from 7.4.4 CertificateRequest. > > The avoid the need to buffer the handshake messages for the > CertificateVerify message, the hash algorithm should ideally be chosen > so that it can be reused for the verify_data in the Finished message. > But clients with 1024-bit DSA client certs > already need to either buffer the handshake messages or compute their > SHA-1 hash, in addition to their SHA-256 hash for verify_data. It is extremely rare for TLS clients and servers to actually negotiate TLSv1.2, and I currently do not expect this to change significantly during the next couple of years. There seem to be two reasons for this: - at least one vendor sees a performance problem with enabling TLSv1.2 for the server by default - clients proposing ClientHello.client_version TLSv1.1{0x03,0x02} instead of TLSv1.0 {0x03,0x01} experience an increased amount of handshake failures, and it becomes even worse when proposing TLSv1.2{0x03,0x03} Personally, I think it would be reasonable to define/standardize a workaround for the latter interop problem through (ab)use of two special cipher suite values. The approach that a number of Web Browsers are currently doing, trying reconnect fallback after failed handshakes, is an application-level workaround instead of a TLS-level fix for a genuine TLS interop problem. -Martin From mike-list@pobox.com Mon Feb 14 15:21:19 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088DF3A6C2E for ; Mon, 14 Feb 2011 15:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2mX7qj1ApTG for ; Mon, 14 Feb 2011 15:21:17 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id DBB0D3A69E5 for ; Mon, 14 Feb 2011 15:21:16 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C8DD33FFE; Mon, 14 Feb 2011 18:22:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Fi82fY37qYr2 eh8+V5q/2u2Z9g4=; b=haztpp2WzKXhQbUxLB4yFBonAVzROufF1RtCm3keF+6V zQDTm7XweGxogOFHglQr9FnfI501glC6kDhGZ+Dg0l48nWKu7LSjvQ0Q8O4BEia9 4k41XoMuoQX9i44B5pH6Wo13kpOwdy3XefJ9/o6LSnTrRA+7mGz7cZUcD89sK8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=AJkZMA TnYxtH6kDMftYS5crQYqrGJgQLr4wuUw7Fh8bsUITuc/jBOSXOpBNfj243lG+92H eDtHqSvB38EhipoIvO5F+D0m5SNttcBquXk5Ad+XD4lOOfNjLZ4InRfbd96mHZBj taDa3DwAb6EcXIAk0621HPdFYIAOLfYQOBqOQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B4BE23FFB; Mon, 14 Feb 2011 18:22:41 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 301ED3FF4; Mon, 14 Feb 2011 18:22:39 -0500 (EST) Message-ID: <4D59B8FE.6010908@pobox.com> Date: Mon, 14 Feb 2011 15:21:34 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mrex@sap.com References: <201102142231.p1EMV7AD023546@fs4113.wdf.sap.corp> In-Reply-To: <201102142231.p1EMV7AD023546@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 51ECF98A-3891-11E0-8E76-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and key size >1024 bits) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 23:21:19 -0000 > It is extremely rare for TLS clients and servers to actually negotiate > TLSv1.2, and I currently do not expect this to change significantly > during the next couple of years. > > There seem to be two reasons for this: > > - at least one vendor sees a performance problem with enabling > TLSv1.2 for the server by default This is not a problem with TLS 1.2 itself, but of that vendor's implementation of it. My server shows virtually no difference in throughput for any SSL/TLS version, though SSL3 is a tiny bit slower than the rest. This could be explained by the slightly more complicated MAC computation in SSLv3 vs HMAC in TLS. Mike From n.mavrogiannopoulos@gmail.com Tue Feb 15 00:39:42 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988513A6AE0 for ; Tue, 15 Feb 2011 00:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbJFVIuh5Sau for ; Tue, 15 Feb 2011 00:39:41 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 61BA03A6ABB for ; Tue, 15 Feb 2011 00:39:41 -0800 (PST) Received: by qwi2 with SMTP id 2so4005604qwi.31 for ; Tue, 15 Feb 2011 00:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QtGzbeDwKmgchqSj3e6Ug0PDIUzRGC3ajIGcowM1VuM=; b=Qrd37+DHqRURrDM2cAtQvApVvU6KMVSGmpGoP27yssd21O7SBUCv4OCoG63pazwN5D TWIJYnXOtVcS/RqCEaURKQvVtapR4ODc2sfKmgEDCNi1aWTe+kFVLhHhBWNPzxX2QetG 13yjJpJxxHhLQL73Dumz8Y1YKfS8oOAYxxVuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iH70iCFdAzK0mtrEWR6Si5/T65MYfTIR4VpF8W9lf7knVGsOunkc2+FJ4AUwkiSyh/ V0EesiNHOOmpYhnjRYJ41627zeJ1QQxbUwa/911byWXXZd5H1BW1xZhiMMssFtJiXYaq 0AJmfPuKQPpv0Wa/hMcY4k46tR/mVJJqjX7j0= MIME-Version: 1.0 Received: by 10.229.241.84 with SMTP id ld20mr3720408qcb.128.1297759204681; Tue, 15 Feb 2011 00:40:04 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Tue, 15 Feb 2011 00:40:04 -0800 (PST) In-Reply-To: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> References: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> Date: Tue, 15 Feb 2011 09:40:04 +0100 X-Google-Sender-Auth: K6cQsX87EsWKcy5RiyJxxuRLkg4 Message-ID: From: Nikos Mavrogiannopoulos To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 08:39:42 -0000 On Mon, Feb 14, 2011 at 5:48 PM, Martin Rex wrote: > Dear implementors of TLSv1.2, > The use of TLSv1.2 with DSA client certs using key lengths > 1024 > as defined by FIPS 186-3 appears slightly underspecified. > I would like to find out what current implementations of TLSv1.2 > are doing -- and what they are doing when negotiating a protocol > version less that {0x03,0x03}. > The base protocol spec does not define what to do with a (L=3D2048,N=3D22= 4), > (L=3D2048,N=3D256) or (L=3D3072,N=3D256) DSA key from FIPS 186-3 in a cli= ent cert > in TLSv1.1. =C2=A0rfc4492 Page 20 provides a hint for how to represent > ECDSA signature values with hash algorithms other than SHA-1 but > does not describe a means to indicate to the receiver, which > other hash was actually used. Currently gnutls uses SHA-1 on versions prior to TLS 1.2. For TLS 1.2 it uses a hash that corresponds to the length of q (i.e. chooses between SHA-1, SHA-224 and SHA-256). regards, Nikos From simon@josefsson.org Tue Feb 15 05:52:01 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905403A6D40 for ; Tue, 15 Feb 2011 05:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bi4KoUPsQ+f for ; Tue, 15 Feb 2011 05:52:00 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 538503A6D32 for ; Tue, 15 Feb 2011 05:52:00 -0800 (PST) Received: from latte.josefsson.org (host-78-79-131-254.mobileonline.telia.com [78.79.131.254]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1FDqBVo003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Feb 2011 14:52:17 +0100 From: Simon Josefsson To: mrex@sap.com References: <4D566DFB.8040603@ralphholz.de> <201102141347.p1EDlQGt022588@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110215:mrex@sap.com::0zR1tvMAfhPySQ25:3VCS X-Hashcash: 1:22:110215:ralph-tls-tum@ralphholz.de::werGKM6q6m1BTR/G:2xbO X-Hashcash: 1:22:110215:tls@ietf.org::YwMW5R2/TWvmLu0U:9BzB Date: Tue, 15 Feb 2011 14:52:10 +0100 In-Reply-To: <201102141347.p1EDlQGt022588@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 14 Feb 2011 14:47:26 +0100 (MET)") Message-ID: <87vd0lbe2d.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 13:52:01 -0000 Martin Rex writes: > Ralph Holz wrote: >> >> > Considering that a non-marginal fraction of the TLS protected communication >> > actually negotiates protocol version {0x03,0x00}, there is not reason for >> > a classification of "historic". >> >> Not intending to take sides here, but from our own observations at a >> large ISP, SSLv3 seems to be chosen as a protocol version only for a >> very marginal fraction of connections. I can't quite remember the >> numbers, but it was something around 0.1% or less. I can look it up, if >> you want. > > That low number appears somewhat unrealistic to me. > > Microsoft Windows XP was shipped with SSLv2 enabled and TLSv1.0 disabled. Service packs can make rather radical changes, are you sure an updated Windows XP still enable SSLv2? If so, I'm hoping the next security update will disable it. /Simon From lists@drh-consultancy.demon.co.uk Tue Feb 15 06:18:49 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8ED23A6D2C for ; Tue, 15 Feb 2011 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysWwTO4zAITl for ; Tue, 15 Feb 2011 06:18:49 -0800 (PST) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by core3.amsl.com (Postfix) with ESMTP id 1C9183A6CD8 for ; Tue, 15 Feb 2011 06:18:49 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49709 helo=[192.168.7.8]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10587) with esmtpa (authdaemon_plain:drh) id 1PpLkG-0007y9-Ho for tls@ietf.org (return-path ); Tue, 15 Feb 2011 14:19:12 +0000 Message-ID: <4D5A8B6B.2010104@drh-consultancy.demon.co.uk> Date: Tue, 15 Feb 2011 14:19:23 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 CC: tls@ietf.org References: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> In-Reply-To: <201102141648.p1EGmInm003093@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 14:18:50 -0000 On 14/02/2011 16:48, Martin Rex wrote: > Dear implementors of TLSv1.2, > > The use of TLSv1.2 with DSA client certs using key lengths > 1024 > as defined by FIPS 186-3 appears slightly underspecified. > I would like to find out what current implementations of TLSv1.2 > are doing -- and what they are doing when negotiating a protocol > version less that {0x03,0x03}. > OpenSSL uses SHA-1 for TLS v1.1 and below. OpenSSL doesn't currently support TLS v1.2. As I mentioned elsewhere FIPS 186-3 also includes comments about RSA (section 5). For example it limits keys sizes to 1024, 2048 and 3072 bits. 4096 bit RSA keys are not that uncommon and oddball keylengths like 2047 bits crop up quite often too. There is a similar comment about SHA-1 though not an outright prohibition: "A hash function that provides a lower security strength than the security strength associated with the bit length of the modulus ordinarily should not be used, since this would reduce the security strength of the digital signature process to a level no greater than that provided by the hash function." Using SHA-2 algorithms isn't possible in TLS 1.1 and earlier with RSA as they hard code the SHA1+MD5 signature. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Tue Feb 15 07:09:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B778F3A6D56 for ; Tue, 15 Feb 2011 07:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.205 X-Spam-Level: X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Snk4Nyl9LSVX for ; Tue, 15 Feb 2011 07:09:46 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B07503A6D54 for ; Tue, 15 Feb 2011 07:09:45 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1FFA7UL016749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2011 16:10:08 +0100 (MET) From: Martin Rex Message-Id: <201102151510.p1FFA7Rf019374@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 15 Feb 2011 16:10:07 +0100 (MET) In-Reply-To: <87vd0lbe2d.fsf@latte.josefsson.org> from "Simon Josefsson" at Feb 15, 11 02:52:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] publishing SSL 3.0 as historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 15:09:46 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > > Ralph Holz wrote: > >> > >> > Considering that a non-marginal fraction of the TLS protected communication > >> > actually negotiates protocol version {0x03,0x00}, there is not reason for > >> > a classification of "historic". > >> > >> Not intending to take sides here, but from our own observations at a > >> large ISP, SSLv3 seems to be chosen as a protocol version only for a > >> very marginal fraction of connections. I can't quite remember the > >> numbers, but it was something around 0.1% or less. I can look it up, if > >> you want. > > > > That low number appears somewhat unrealistic to me. > > > > Microsoft Windows XP was shipped with SSLv2 enabled and TLSv1.0 disabled. > > Service packs can make rather radical changes, are you sure an updated > Windows XP still enable SSLv2? If so, I'm hoping the next security > update will disable it. I do not have access to a sufficient variety of "virgin" installs. My impression is that installation of MSIE7 (or later) might change the defaults and disable SSLv2 and enable TLSv1.0. I don't know about XPsp3. With XPsp2+MSIE6 as well as Win2K3sp2+MSIE6 the original default applies. -Martin From mrex@sap.com Tue Feb 15 08:18:35 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959693A6B3B for ; Tue, 15 Feb 2011 08:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECyTJ9ls3ji7 for ; Tue, 15 Feb 2011 08:18:34 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 816AE3A6A9E for ; Tue, 15 Feb 2011 08:18:34 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1FGIx4C026944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2011 17:18:59 +0100 (MET) From: Martin Rex Message-Id: <201102151618.p1FGIwQ8023299@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Tue, 15 Feb 2011 17:18:58 +0100 (MET) In-Reply-To: <4D5A8B6B.2010104@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Feb 15, 11 02:19:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 16:18:35 -0000 Dr Stephen Henson wrote: > > [...] a similar comment about SHA-1 though not an outright prohibition: > > "A hash function that provides a lower security strength than the > security strength associated with the bit length of the modulus > ordinarily should not be used, since this would reduce the security > strength of the digital signature process to a level no greater > than that provided by the hash function." It's true that the wording in FIPS 186-3 section 4.2 (page 16 2nd paragraph) uses "should not" (while the same description for ECDSA uses "shall not"). However, this looks to me like a transitional exception that might have ended on 31.12.2010. In the same section, last paragraph on page 15, it reads: Both the security strength of the hash function used and the security strength of the (L, N) pair shall meet or exceed the security strength required for the digital signature process. > > Using SHA-2 algorithms isn't possible in TLS 1.1 and earlier with RSA > as they hard code the SHA1+MD5 signature. I agree. The hash algorithm(s) in the digital signature of the KeyExchange and CertificateVerify handshake messages prior to TLSv1.2 is implied and fixed. Support for longer DSA keys with hashes from the SHA-2 family will require code changes to the installed base, where some may wonder why not implementing TLSv1.2. One of the problem appears to be the default reluctance to offer/use TLSv1.2 even by those implementations that already contain the code and the resulting TLS handshake failures with non-marginal parts of the installed base of servers for clients proposing TLSv1.2 through ClientHello.client_version. -Martin From lists@drh-consultancy.demon.co.uk Tue Feb 15 08:42:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E52D3A6C32 for ; Tue, 15 Feb 2011 08:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkOnZZNAvWtV for ; Tue, 15 Feb 2011 08:42:30 -0800 (PST) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by core3.amsl.com (Postfix) with ESMTP id CC1423A6A8B for ; Tue, 15 Feb 2011 08:42:29 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50790 helo=[192.168.7.8]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10587) with esmtpa (authdaemon_plain:drh) id 1PpNzJ-0005kU-4V (return-path ); Tue, 15 Feb 2011 16:42:53 +0000 Message-ID: <4D5AAD0C.5050900@drh-consultancy.demon.co.uk> Date: Tue, 15 Feb 2011 16:42:52 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mrex@sap.com References: <201102151618.p1FGIwQ8023299@fs4113.wdf.sap.corp> In-Reply-To: <201102151618.p1FGIwQ8023299@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 16:42:31 -0000 On 15/02/2011 16:18, Martin Rex wrote: > Dr Stephen Henson wrote: >> >> [...] a similar comment about SHA-1 though not an outright prohibition: >> >> "A hash function that provides a lower security strength than the >> security strength associated with the bit length of the modulus >> ordinarily should not be used, since this would reduce the security >> strength of the digital signature process to a level no greater >> than that provided by the hash function." > > It's true that the wording in FIPS 186-3 section 4.2 (page 16 2nd paragraph) > uses "should not" (while the same description for ECDSA uses "shall not"). > It also says: "In addition, an RSA digital signature key pair shall not be used for other purposes (e.g., key establishment)." I can't imagine many servers using two distinct certificates for ephemeral and static RSA ciphersuites, even is the server software supports it. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From mrex@sap.com Tue Feb 15 09:01:19 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352F53A6CB7 for ; Tue, 15 Feb 2011 09:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5BrVw1k8WMK for ; Tue, 15 Feb 2011 09:01:18 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C7E433A6D13 for ; Tue, 15 Feb 2011 09:01:17 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1FH1gb9002193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2011 18:01:42 +0100 (MET) From: Martin Rex Message-Id: <201102151701.p1FH1gVM025768@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Tue, 15 Feb 2011 18:01:42 +0100 (MET) In-Reply-To: <4D5AAD0C.5050900@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Feb 15, 11 04:42:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:01:19 -0000 Dr Stephen Henson wrote: > > [FIPS 186-3] also says: > > "In addition, an RSA digital signature key pair shall not be used for other > purposes (e.g., key establishment)." > > I can't imagine many servers using two distinct certificates for ephemeral and > static RSA ciphersuites, even is the server software supports it. I noticed that as well. :) So I looked at the next best SSL Server cert (happened to be issued by Thawte SGC) and noticed that it does not contain a KeyUsage extension (only ExtendedKeyUsage and BasicConstraints cA=FALSE). static RSA ciphersuites need KeyUsage "keyEncipherment", and DHE_RSA would need "digitalSignature". But asserting both in a cert seems literally incompatible with FIPS 186-3. I also noticed the distinction between PKCS1-v1.5 and PKCS1-PSS signatures, and that RSA keys should be used for only one of the two for their entire lifetime. While it is sensible in general to distinguish credentials for online authentication and credentials for longterm digital signatures, PKCS1-v1.5 is hardwired into SSLv3 and all current versions of TLS. I didn't see reference to or definition of an ExtendedKeyUsage OID to recognize/distinguish RSA PKCS1-PSS keys in FIPS 186-3, which looks somewhat inconsequential for the v1.5/PSS issue. -Martin From DPKemp@missi.ncsc.mil Tue Feb 15 09:59:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AE13A6D2D for ; Tue, 15 Feb 2011 09:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJF8tkz1dNgv for ; Tue, 15 Feb 2011 09:59:20 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 6355C3A6CD5 for ; Tue, 15 Feb 2011 09:59:20 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p1FHxis8053732; Tue, 15 Feb 2011 12:59:44 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 12:59:03 -0500 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 Date: Tue, 15 Feb 2011 12:54:11 -0500 Message-ID: In-Reply-To: <4D5AAD0C.5050900@drh-consultancy.demon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits Thread-Index: AcvNLqQMua3oNsQwTH6zpCgK4gniiAABC/jw References: <201102151618.p1FGIwQ8023299@fs4113.wdf.sap.corp> <4D5AAD0C.5050900@drh-consultancy.demon.co.uk> From: "Kemp, David P." To: "Dr Stephen Henson" , X-OriginalArrivalTime: 15 Feb 2011 17:59:03.0578 (UTC) FILETIME=[07F97FA0:01CBCD3A] Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:59:22 -0000 The wording could probably use clarification - a "digital signature" key pair is used by an entity to bind its identity to a piece of information. If the only external result of an ephemeral ciphersuite is an authenticated shared key, then the RSA key is being used for the purpose of key establishment even if a signature algorithm is used internally by the key establishment process. If a client purported to have data signed by a server as a result of having performed a key exchange using a key establishment certificate, it would be misrepresenting the results of the key exchange. No relying party would accept as valid data "signed" using a key establishment certificate, protecting the server from unintended consequences. Dave -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Dr Stephen Henson Sent: Tuesday, February 15, 2011 11:43 AM To: mrex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits On 15/02/2011 16:18, Martin Rex wrote: > Dr Stephen Henson wrote: >> >> [...] a similar comment about SHA-1 though not an outright prohibition: >> >> "A hash function that provides a lower security strength than the >> security strength associated with the bit length of the modulus >> ordinarily should not be used, since this would reduce the security >> strength of the digital signature process to a level no greater >> than that provided by the hash function." >=20 > It's true that the wording in FIPS 186-3 section 4.2 (page 16 2nd paragraph) > uses "should not" (while the same description for ECDSA uses "shall not"). >=20 It also says: "In addition, an RSA digital signature key pair shall not be used for other purposes (e.g., key establishment)." I can't imagine many servers using two distinct certificates for ephemeral and static RSA ciphersuites, even is the server software supports it. Steve. --=20 Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From noskov@microsoft.com Tue Feb 15 10:00:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5585C3A6D33 for ; Tue, 15 Feb 2011 10:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFdezbQgAH0V for ; Tue, 15 Feb 2011 10:00:46 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2F91C3A6CD5 for ; Tue, 15 Feb 2011 10:00:46 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Feb 2011 10:01:12 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 15 Feb 2011 10:01:07 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.252]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 15 Feb 2011 10:01:03 -0800 From: Nasko Oskov To: Adam Langley , Geoffrey Keating Thread-Topic: [TLS] AES-GCM implementation Thread-Index: AQHLyj1/9qCqyVn55k2hzhNf+hbqKpQC36Ug Date: Tue, 15 Feb 2011 17:59:41 +0000 Deferred-Delivery: Tue, 15 Feb 2011 18:00:00 +0000 Message-ID: <5481EC27EF8E6D469C71CD1236902816173B79DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <4D4D04C8.1090307@gnutls.org> <5481EC27EF8E6D469C71CD1236902816173AC1DD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Davies, Joshua" , "tls@ietf.org" Subject: Re: [TLS] AES-GCM implementation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 18:00:47 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gTGFuZ2xleQ0K PlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTEsIDIwMTEgMjo0NSBQTQ0KPlRvOiBHZW9mZnJleSBL ZWF0aW5nDQo+Q2M6IERhdmllcywgSm9zaHVhOyB0bHNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTog W1RMU10gQUVTLUdDTSBpbXBsZW1lbnRhdGlvbg0KPg0KPk9uIEZyaSwgRmViIDExLCAyMDExIGF0 IDQ6NDkgUE0sIEdlb2ZmcmV5IEtlYXRpbmcgPGdlb2Zma0BnZW9mZmsub3JnPiB3cm90ZToNCj4+ IElmIHlvdSBjb25uZWN0IHRvIGh0dHBzOi8vdGxzLndvb2Rncm92ZWJhbmsuY29tL0NpcGVyc3Vp dGVzLmh0bSwgaXQNCj4+IHRlbGxzIHlvdSB3aGljaCBjaXBoZXIgc3VpdGVzIGl0IHN1cHBvcnRz LiDCoEl0IGFwcGVhcnMgdG8gc3VwcG9ydCBHQ00NCj4+IG9ubHkgd2l0aCBFQ0RTQS4NCj4NCj5B bHRob3VnaCB0aGUgY2VydGlmaWNhdGUgaGFzIGV4cGlyZWQ6ICJOb3QgQWZ0ZXIgOiBKYW4gMjYg MDA6Mjk6MDEgMjAxMSBHTVQiDQoNClRoaXMgc2hvdWxkIGJlIG5vdyBmaXhlZC4NClRoYW5rcywN Ck5hc2tvDQo= From kent@bbn.com Tue Feb 15 13:55:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E8B3A6C21; Tue, 15 Feb 2011 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v-1hcecLqT4; Tue, 15 Feb 2011 13:55:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 333583A6AB9; Tue, 15 Feb 2011 13:55:01 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:56192 helo=[10.84.131.124]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpSrn-000HQ2-Ax; Tue, 15 Feb 2011 16:55:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D55A4A2.7020900@gmail.com> References: <4D55A4A2.7020900@gmail.com> Date: Tue, 15 Feb 2011 11:34:26 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IPsecme WG , tls@ietf.org Subject: Re: [TLS] [IPsec] Security consideration for DTLS: Adversarial packet loss/reordering X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 21:55:02 -0000 At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote: >Hi Steve, > >[Cross-posted to ipsecme] > >I have always wondered about these sequence numbers, and the concept >of anti-replay in IPsec. > >- IPsec is architecturally a "plug-in replacement" for IP. And IP >allows for arbitrary packet deletion, duplication and reordering. >- Anti-replay counters are giving us no end of trouble in clustered >environments (e.g. >http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/). >- IPsec (unfortunately) does not have an application API, at least >in most implementations. Such an API might indeed have put this >feature to good use. >- And lastly, IPsec anti-replay is optional, which signifies to me >that it's always been an iffy feature. > >I have looked at RFC 4301 again (the IPsec architecture), and it >provides only weak justification for this feature. Can you please >point me to a more convincing reasoning? > >Thanks, > Yaron Can any Steve reply? While IP allows arbitrary packet arrival, IPsec allows a receiver to limit the extent of such OOO arrival, to enable it to detect and reject replay attacks. That is the rationale for AR and it is just as applicable in a clustered receiver context as in a single receiver context. The fact that it is optional to use (not to implement) is NOT an indication that it is "iffy." It is an indication that not all apps might require its use, and some might find it in conflict with the app. That is a app-specific decision, not a decision to be made by an IPsec vendor. Use of this feature is declared via the SAD, so an administrative interface is one way to specify use of this feature based on the protocol and port #'s. I'm sorry that AR is causing problems in clustered contexts, but that is not a justification to not support it. Steve From mrex@sap.com Wed Feb 16 08:51:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C753A6E89 for ; Wed, 16 Feb 2011 08:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zer4dAOnkoIi for ; Wed, 16 Feb 2011 08:51:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 605033A6CB0 for ; Wed, 16 Feb 2011 08:51:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1GGpvhs005338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Feb 2011 17:51:57 +0100 (MET) From: Martin Rex Message-Id: <201102161651.p1GGpvbs016665@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 16 Feb 2011 17:51:57 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:51:33 -0000 Does anyone remember this report (&ensuing discussion): http://www.ietf.org/mail-archive/web/tls/current/msg06840.html > > For IE 8, the scenario looks like: > > IE 8<--------------> TLS server > --->ClientHello V1.2---> > <---ServerHello V1.1<--- > ... > --->PreMasterSecret (v1.2)---> (as expected) > ... > <---HelloRequest<---- > ---->ClientHello v1.1----> (ask for an abbreviated handshake) > <---ServerHello V1.1<--- (not resumable, new session) > ... > --->PreMasterSecret (v1.2)---> (**) > > (**) IE 8 uses the version number offered by the ClientHello in the > initial handshaking. The behavior of IE 8 (actually SChannel) is clearly defective for the renegotiation handshake, because the client_version in the PreMasterSecret does not match the ClientHello.client_version from the same handshake. (Just how *independent* SSL handshakes were designed to be should have become painfully obvious with the renegotiation vulnerability...) According to what a colleague just told me, the behaviour that was described for Opera (and also used by SunJSSE) results in a handshake failure on renegotiation with IIS7: > > For Opera, the scenario looks like: > > Opera <--------------> TLS server > --->ClientHello V1.2---> > <---ServerHello V1.1<--- > ... > --->PreMasterSecret (v1.2)---> (as expected) > ... > <---HelloRequest<---- > ---->ClientHello v1.1----> (ask for an abbreviated handshake) > <---ServerHello V1.1<--- (not resumable, new session) > ... > --->PreMasterSecret (v1.1)---> (*) > > (*) Opera uses the version number offered by the ClientHello in the > renegotiation handshaking. While coping with defective clients such as described with IE8 above has a long tradition, a server like IIS7 that chokes on _correct_ behaviours seems to be a new kid on the block. One reason why this problem may not be immediately apparent at Browser UIs is that newer browsers contain extremely dirty application-level hacks to work around TLS version interop problems, and they're caching the TLS version for which the handshake succeeds and steer further connects to start with that exact same version (instead of always proposing the highest version the client implements, as the TLS spec suggests). Has anyone else observed this interop problem with newer SChannel-based servers on renegotiation handshakes and wondered? -Martin From mrex@sap.com Wed Feb 16 10:14:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D6F3A6D15 for ; Wed, 16 Feb 2011 10:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvmoQiI7-Gc0 for ; Wed, 16 Feb 2011 10:14:46 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DB2773A6EEC for ; Wed, 16 Feb 2011 10:14:45 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1GIFDZ3005130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Feb 2011 19:15:13 +0100 (MET) From: Martin Rex Message-Id: <201102161815.p1GIFD9q021649@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 16 Feb 2011 19:15:12 +0100 (MET) In-Reply-To: <201102161651.p1GGpvbs016665@fs4113.wdf.sap.corp> from "Martin Rex" at Feb 16, 11 05:51:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:14:47 -0000 While the behaviour that was described for Opera is allowed the way I read the TLS spec, it is _not_ the recommended behaviour. I also wrote that in my first comment to the original posting: http://www.ietf.org/mail-archive/web/tls/current/msg06842.html A client that always sends the highest supported version, will avoid this IIS7 interop problem. For application-level reconnect fallbacks--rather than memorizing the TLS version that was negotiated and forcing that version in all later TLS handshakes, a client should probably memorize the highest protocol version (known to the client) which could be safely proposed in ClientHello.client_version to the server on all further Handshakes (new connects, resumes, renegotiations) and in both, ClientHello.client_version and RSA PreMasterSecret.client_version. -Martin Martin Rex wrote: > > > Does anyone remember this report (&ensuing discussion): > > http://www.ietf.org/mail-archive/web/tls/current/msg06840.html > > According to what a colleague just told me, the behaviour that was > described for Opera (and also used by SunJSSE) results in a handshake > failure on renegotiation with IIS7: > > > > > For Opera, the scenario looks like: > > > > Opera <--------------> TLS server > > --->ClientHello V1.2---> > > <---ServerHello V1.1<--- > > ... > > --->PreMasterSecret (v1.2)---> (as expected) > > ... > > <---HelloRequest<---- > > ---->ClientHello v1.1----> (ask for an abbreviated handshake) > > <---ServerHello V1.1<--- (not resumable, new session) > > ... > > --->PreMasterSecret (v1.1)---> (*) > > > > (*) Opera uses the version number offered by the ClientHello in the > > renegotiation handshaking. > > > While coping with defective clients such as described with IE8 above > has a long tradition, a server like IIS7 that chokes on _correct_ > behaviours seems to be a new kid on the block. While the behaviour above is allowed by my reading of the TLS specification, I noted > > > One reason why this problem may not be immediately apparent at > Browser UIs is that newer browsers contain extremely dirty > application-level hacks to work around TLS version interop > problems, and they're caching the TLS version for which the > handshake succeeds and steer further connects to start with > that exact same version (instead of always proposing the > highest version the client implements, as the TLS spec suggests). > > > Has anyone else observed this interop problem with newer > SChannel-based servers on renegotiation handshakes and wondered? > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mike-list@pobox.com Wed Feb 16 11:11:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644FA3A6EF8 for ; Wed, 16 Feb 2011 11:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL6WgqTBRcHG for ; Wed, 16 Feb 2011 11:11:06 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 14F6C3A6D43 for ; Wed, 16 Feb 2011 11:11:05 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C375F32AB; Wed, 16 Feb 2011 14:12:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=VJmpLvKU3vIl Wc4HgytDTUASLYI=; b=AIBAg1oKmIi/8cW+5agmxTmjKd0w4Em41x1L11jZ3/u0 DhW6sTXbeKrUM8yiDimvU7MEe4AZmcDwtwjoZZkFG/TET9vxAltLofhvOUZO0v/l MToGKJ9rlq+u133OBPcqAwICXdaFx4l99qSn46IEVN0amqanRGPzFw9Mn+pitGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=XNGPjY YSA43C14FQCxBHP7rhFwGFhcGQ/yGcH/UyYCIphxRZDU6FZU+puwAiY1uNjewHiC /9i1wvpZ79wIIds0IkEvkQi2WAB0dBmR4r075hpHT9dPdylzPpkhL14GMQA2rsAq gy9o9FtckH8rCswntqarPBngGbuKErjNMuyX0= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 98F3A32AA; Wed, 16 Feb 2011 14:12:38 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id B078A32A7; Wed, 16 Feb 2011 14:12:36 -0500 (EST) Message-ID: <4D5C2161.9090803@pobox.com> Date: Wed, 16 Feb 2011 11:11:29 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mrex@sap.com References: <201102161815.p1GIFD9q021649@fs4113.wdf.sap.corp> In-Reply-To: <201102161815.p1GIFD9q021649@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: B83107D4-3A00-11E0-AD18-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:11:11 -0000 Martin Rex wrote: > While the behaviour that was described for Opera is allowed > the way I read the TLS spec, it is _not_ the recommended behaviour. > > I also wrote that in my first comment to the original posting: > > http://www.ietf.org/mail-archive/web/tls/current/msg06842.html > > A client that always sends the highest supported version, > will avoid this IIS7 interop problem. > > For application-level reconnect fallbacks--rather than > memorizing the TLS version that was negotiated and forcing that > version in all later TLS handshakes, a client should probably > memorize the highest protocol version (known to the client) which > could be safely proposed in ClientHello.client_version to the server > on all further Handshakes (new connects, resumes, renegotiations) and > in both, ClientHello.client_version and RSA PreMasterSecret.client_version. A problem with caching the server's highest protocol version is that it can change as the server is upgraded. So the time to live of the cached data should not be too long, in order to not have the client cause downgrade attacks on itself. Mike > Martin Rex wrote: >> >> Does anyone remember this report (&ensuing discussion): >> >> http://www.ietf.org/mail-archive/web/tls/current/msg06840.html >> >> According to what a colleague just told me, the behaviour that was >> described for Opera (and also used by SunJSSE) results in a handshake >> failure on renegotiation with IIS7: >> >>> For Opera, the scenario looks like: >>> >>> Opera <--------------> TLS server >>> --->ClientHello V1.2---> >>> <---ServerHello V1.1<--- >>> ... >>> --->PreMasterSecret (v1.2)---> (as expected) >>> ... >>> <---HelloRequest<---- >>> ---->ClientHello v1.1----> (ask for an abbreviated handshake) >>> <---ServerHello V1.1<--- (not resumable, new session) >>> ... >>> --->PreMasterSecret (v1.1)---> (*) >>> >>> (*) Opera uses the version number offered by the ClientHello in the >>> renegotiation handshaking. >> >> While coping with defective clients such as described with IE8 above >> has a long tradition, a server like IIS7 that chokes on _correct_ >> behaviours seems to be a new kid on the block. > > While the behaviour above is allowed by my reading of the TLS specification, > I noted > > >> >> One reason why this problem may not be immediately apparent at >> Browser UIs is that newer browsers contain extremely dirty >> application-level hacks to work around TLS version interop >> problems, and they're caching the TLS version for which the >> handshake succeeds and steer further connects to start with >> that exact same version (instead of always proposing the >> highest version the client implements, as the TLS spec suggests). >> >> >> Has anyone else observed this interop problem with newer >> SChannel-based servers on renegotiation handshakes and wondered? >> >> >> -Martin >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From yngve@opera.com Wed Feb 16 11:27:24 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E14C3A6EFA for ; Wed, 16 Feb 2011 11:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex77KozL2ASy for ; Wed, 16 Feb 2011 11:27:23 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id A50883A6EED for ; Wed, 16 Feb 2011 11:27:22 -0800 (PST) Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1GJRnew020356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Feb 2011 19:27:50 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: mrex@sap.com References: <201102161815.p1GIFD9q021649@fs4113.wdf.sap.corp> Date: Wed, 16 Feb 2011 20:27:54 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve Nysaeter Pettersen" Organization: Opera Software Message-ID: In-Reply-To: <201102161815.p1GIFD9q021649@fs4113.wdf.sap.corp> User-Agent: Opera Mail/11.01 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:27:24 -0000 Hi, The reason for Opera's behavior is that a renegotiation is essentially treated as a Session resume, which the server may or may not accept (most likely not, but it might just be a rekeying event). As I recall (this is ancient, probably from when we introduced TLS 1.0 in Opera 3.50 in late 1998), historically we have observed interoperability problems if the version in Client Hello attempting session resume was not the same as negotiated. Similar reasons are IIRC behind our reordering of the cipher suites offered to place the previously used cipher suite at the front. Regarding the premaster secret RFC 5246 says The version number in the PreMasterSecret is the version offered by the client in the ClientHello.client_version which I read to mean the Client Hello of the _current_ negotiation, not the first on the connection, or the one used when the currently active session was negotiated. We recently received a report about the version in premaster during renegotiation issue. On Wed, 16 Feb 2011 19:15:12 +0100, Martin Rex wrote: > While the behaviour that was described for Opera is allowed > the way I read the TLS spec, it is _not_ the recommended behaviour. Where is this recommendation written in the TLS RFCs? The Client Hello section says that the version in that record SHOULD be the latest (highest valued) version supported by the client We use the version that we know can be safely negotiated, even though we store information that indicates the highest version that can be safely be negotiated, specifically for Renego patched servers (for unpatched servers the servers version is stored), and as mentioned we choose the session version since there have been trouble using the supported version during session resume. I notice that the IE8 Hello referenced was sending negotiated version as the Client Hello version, not what was used in the original Client Hello (like Opera), while using the original connection handshake Client Hello version as the premaster secret version (unlike Opera). IMO several things may have to be clarified: 1) Should session resume Client Hellos specify negotiated or supported versions during _new_ connection negotiation? 2) Should renegotiation use the Client Hello version from the original Hello, or the negotiated version 3) If the versions in the renegotiation Client Hello is different from the version used in the initial negotiation, which should be used. 4) If the negotiated version is used in session resume, if the current connection was a session resume, should the highest supported version be used in the premaster secret? I think 1) could go either way, but unless I am mistaken "everybody" is using negotiated version at present. And I have no idea what the current status is regarding tolerance for this (feature request filed for the TLS Prober). The answer to 2) would probably follow the answer to 1). The big question is what should be the answer to 3) and 4), and in any case here we come up against the fact that both the server and client in Schannel were developed by the same company and tested against each other, but also the that 30% of all servers do not check the premaster version field, and 99% of all servers have TLS 1.0 as their highest enabled version. Additionally, renegotiation is not used that frequently in deployed systems. My opinion is that the Client Hello of the current negotiation should be used, since that makes the logic easier, mistakes less easy to make, and AFAIK unless the negotiated protocol version is vulnerable to an active rollback attack and MITM attack, the negotiated version will be the highest supported by the server, so that should not present a security problem or rollback possibility. Whatever is decided, one probably have to be very careful, since changing from the current system might cause interoperability problems with existing systems. > I also wrote that in my first comment to the original posting: > > http://www.ietf.org/mail-archive/web/tls/current/msg06842.html > > A client that always sends the highest supported version, > will avoid this IIS7 interop problem. > > For application-level reconnect fallbacks--rather than > memorizing the TLS version that was negotiated and forcing that > version in all later TLS handshakes, a client should probably > memorize the highest protocol version (known to the client) which > could be safely proposed in ClientHello.client_version to the server > on all further Handshakes (new connects, resumes, renegotiations) and > in both, ClientHello.client_version and RSA > PreMasterSecret.client_version. > > -Martin > > > Martin Rex wrote: >> >> >> Does anyone remember this report (&ensuing discussion): >> >> http://www.ietf.org/mail-archive/web/tls/current/msg06840.html >> >> According to what a colleague just told me, the behaviour that was >> described for Opera (and also used by SunJSSE) results in a handshake >> failure on renegotiation with IIS7: >> >> > >> > For Opera, the scenario looks like: >> > >> > Opera <--------------> TLS server >> > --->ClientHello V1.2---> >> > <---ServerHello V1.1<--- >> > ... >> > --->PreMasterSecret (v1.2)---> (as expected) >> > ... >> > <---HelloRequest<---- >> > ---->ClientHello v1.1----> (ask for an abbreviated handshake) >> > <---ServerHello V1.1<--- (not resumable, new session) >> > ... >> > --->PreMasterSecret (v1.1)---> (*) >> > >> > (*) Opera uses the version number offered by the ClientHello in the >> > renegotiation handshaking. >> >> >> While coping with defective clients such as described with IE8 above >> has a long tradition, a server like IIS7 that chokes on _correct_ >> behaviours seems to be a new kid on the block. > > While the behaviour above is allowed by my reading of the TLS > specification, > I noted > > >> >> >> One reason why this problem may not be immediately apparent at >> Browser UIs is that newer browsers contain extremely dirty >> application-level hacks to work around TLS version interop >> problems, and they're caching the TLS version for which the >> handshake succeeds and steer further connects to start with >> that exact same version (instead of always proposing the >> highest version the client implements, as the TLS spec suggests). >> >> >> Has anyone else observed this interop problem with newer >> SChannel-based servers on renegotiation handshakes and wondered? >> >> >> -Martin >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From mrex@sap.com Wed Feb 16 11:57:24 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B332E3A6CFF for ; Wed, 16 Feb 2011 11:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs+gMCcMvnqV for ; Wed, 16 Feb 2011 11:57:23 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 733943A6ABD for ; Wed, 16 Feb 2011 11:57:23 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1GJvpKe023772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 20:57:51 +0100 (MET) From: Martin Rex Message-Id: <201102161957.p1GJvo6W027397@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve Nysaeter Pettersen) Date: Wed, 16 Feb 2011 20:57:50 +0100 (MET) In-Reply-To: from "Yngve Nysaeter Pettersen" at Feb 16, 11 08:27:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:57:24 -0000 Yngve Nysaeter Pettersen wrote: > > Regarding the premaster secret RFC 5246 says > > The version number in the PreMasterSecret is the version > offered by the client in the ClientHello.client_version Yup, this is the important information about the "client_version" in ClientHello and RSA PreMasterSecret and applies to every TLS handshake (and NEVER cross-handshake). > On Wed, 16 Feb 2011 19:15:12 +0100, Martin Rex wrote: > > > While the behaviour that was described for Opera is allowed > > the way I read the TLS spec, it is _not_ the recommended behaviour. > > Where is this recommendation written in the TLS RFCs? > > The Client Hello section says that the version in that record > > SHOULD be the latest (highest valued) version supported by the client You are quoting the recommendation here. The recommendation is to ALWAYS send the latest version supported by the client (more precisely it is the highest version that the client is willing to use). In face of interop problems when sending ClientHello.client_version with values of TLSv1.1{0x03,0x02} or TLSv1.2{0x03,0x03}, the interoperability enhanced guidance would be something like this: ClientHello should be the latest (highest valued) version that the client implementation supports, the client app is willing to use and the server is now known to choke on. If the client caches and forces the last protocol_version that was successfully negotiated, then it is impossible, in case that the server's TLS implementation gets upgraded, that the client uses a better version without probing. The client is better off if it memorizes the highest client_version that it could safely propose, because it may allow the use of higher protocol versions for every handshake without probing (unless the server chokes on all protocol versions that it does not implement). -Martin From mrex@sap.com Wed Feb 16 12:20:20 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138443A6D6C for ; Wed, 16 Feb 2011 12:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AWtmeL5kxCr for ; Wed, 16 Feb 2011 12:20:19 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CDCDF3A6C32 for ; Wed, 16 Feb 2011 12:20:18 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1GKKlAg026041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 21:20:47 +0100 (MET) From: Martin Rex Message-Id: <201102162020.p1GKKjWi028889@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 16 Feb 2011 21:20:45 +0100 (MET) In-Reply-To: <201102161957.p1GJvo6W027397@fs4113.wdf.sap.corp> from "Martin Rex" at Feb 16, 11 08:57:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 20:20:20 -0000 Sorry, typo (s/is now known/is not known/), fixed below: Martin Rex wrote: > > In face of interop problems when sending ClientHello.client_version > with values of TLSv1.1{0x03,0x02} or TLSv1.2{0x03,0x03}, the > interoperability enhanced guidance would be something like this: > ClientHello should be the latest (highest valued) version that the client implementation supports, the client app is willing to use and the server is not known to choke on. > > If the client caches and forces the last protocol_version that > was successfully negotiated, then it is impossible, in case > that the server's TLS implementation gets upgraded, that the > client uses a better version without probing. > > The client is better off if it memorizes the highest client_version > that it could safely propose, because it may allow the use of higher > protocol versions for every handshake without probing (unless the > server chokes on all protocol versions that it does not implement). -Martin From mrex@sap.com Wed Feb 16 14:51:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBA53A6DDF for ; Wed, 16 Feb 2011 14:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8sgkdgElyXy for ; Wed, 16 Feb 2011 14:51:26 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C004D3A6D6F for ; Wed, 16 Feb 2011 14:51:25 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1GMpsi7007638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 23:51:54 +0100 (MET) From: Martin Rex Message-Id: <201102162251.p1GMprQg007041@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 16 Feb 2011 23:51:53 +0100 (MET) In-Reply-To: <4D5C2161.9090803@pobox.com> from "Michael D'Errico" at Feb 16, 11 11:11:29 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS client_version (ClientHello & PreMasterSecret) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 22:51:28 -0000 Michael D'Errico wrote: > > A problem with caching the server's highest protocol version > is that it can change as the server is upgraded. So the time > to live of the cached data should not be too long, in order > to not have the client cause downgrade attacks on itself. Agreed. Assumptions about the servers protocol version (in)tolerance that were determined by unprotected probing heuristics should not be used/cached too long. The behaviour newer Web browsers that have reconnect fallbacks suggest that some browsers _are_ caching protocol versions for servers and that they might be caching the negotiated rather than the highest tolerated protocol version. -Martin From mrex@sap.com Wed Feb 16 15:34:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3393A6CE4 for ; Wed, 16 Feb 2011 15:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgYdq1vdv+3B for ; Wed, 16 Feb 2011 15:34:34 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CB93E3A6AB9 for ; Wed, 16 Feb 2011 15:34:33 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1GNZ1Ug019194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Feb 2011 00:35:01 +0100 (MET) From: Martin Rex Message-Id: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Thu, 17 Feb 2011 00:35:00 +0100 (MET) In-Reply-To: <4D59B8FE.6010908@pobox.com> from "Michael D'Errico" at Feb 14, 11 03:21:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 23:34:36 -0000 Michael D'Errico wrote: > > > It is extremely rare for TLS clients and servers to actually negotiate > > TLSv1.2, and I currently do not expect this to change significantly > > during the next couple of years. > > > > There seem to be two reasons for this: > > > > - at least one vendor sees a performance problem with enabling > > TLSv1.2 for the server by default > > This is not a problem with TLS 1.2 itself, but of that vendor's > implementation of it. My server shows virtually no difference in > throughput for any SSL/TLS version, though SSL3 is a tiny bit > slower than the rest. This could be explained by the slightly > more complicated MAC computation in SSLv3 vs HMAC in TLS. The more I think about it, the more I believe it is, in fact, a design flaw in TLSv1.2 responsible for a handshake performance issue (at least when a client certificate is requested). While the PRF was changed from SSLv3->TLSv1.0, there was no change to the CertificateVerify handshake message. So for creating and verifying a CertificateVerify handshake message, two hashes must be maintained over all handshake messages: MD5 + SHA1. With TLSv1.2, if a server does not want to artificially limit the signature algorithms on acceptable client certificates, it must send a long list of acceptable combinations (sha1,rsa), (sha1,dsa), (sha256,rsa), (sha384,rsa), (sha512,rsa), (sha224,dsa), (sha256,dsa), ... So unless both, server and client must either hold on to all handshake messages up to CertificateVerify or carry along hash contexts for all of the possible algorithms. Compare: SSLv3, TLSv1.0/1.1 md5 + sha1 TLSv1.2 md5 + sha1 + sha224 + sha256 + sha384 + sha512 If you look at this list, look at how TLS uses hashes for digital signatures and think about the algorithmic relationships between sha224&sha256 and between sha384&sha52, then sha224 and sha384 are utterly useless fifth and sixth wheel on the TLS cart. For TLS itself, sha256 -- or maybe even sha256 alone would have been PERFECTLY sufficent, and a LOT less work. What I also don't understand is the idea behind "default signature algorithms". For implementing TLSv1.2, SHA-256 _must_ be supported, but unless explicitly negotiated with the TLS SignatureAlgorithm extension, SHA-256 appears not allowed to be used for CertificateVerify. That would mean, when TLSv1.2 is negotiated, but no SignatureAlgorithms extension exchanged, the resulting signature with an RSA client cert in CertificateVerify no longer uses MD5+SHA-1 as in TLS up to v1.1, but _only_ SHA-1 (which slightly weakens that signature compared to prior protocol versions...). The use of SHA-256 is prohibited!??! Weird, really. -Martin From mike-list@pobox.com Wed Feb 16 16:03:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83D73A6D9E for ; Wed, 16 Feb 2011 16:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFR6CMldBf6Y for ; Wed, 16 Feb 2011 16:03:05 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 8D2063A6D98 for ; Wed, 16 Feb 2011 16:03:05 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D5A653524; Wed, 16 Feb 2011 19:04:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=EFKTURQDGO37 Khng4Nt3GotvIcY=; b=PIqgAuRwFC1tD9ojU0gl21Pd9KWvOeOVupl0/hubRThT 9DY7eg/VG4mXDVbN1lbTAb5rLxMILjhjqCODYMrG3P4YD/HmdfvQNh/+z57Q4cYa y8ipgIMkSslRT7YzA8TvNuluNNvrhz8481u7nstoD9kYIm+Oprba+KovD87lAb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=CcAEsy 6sqEuUBeu/Wz7CLTar0boft5S/ws8IMG/ErEvcUAdd4eb5uy88lCoe4GhdhhF/sl MiDw7EDEsHBT/dglc6bOWDV7jUbyEvj0DOnCQjopWlwWRL4D6FGWMTf8yz92XyG1 qsGvAq0hx1FJwVcmJoJMBqAwORbt6mNnY+ECc= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id BDCAD3523; Wed, 16 Feb 2011 19:04:40 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id F02E83522; Wed, 16 Feb 2011 19:04:38 -0500 (EST) Message-ID: <4D5C65D2.4060502@pobox.com> Date: Wed, 16 Feb 2011 16:03:30 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mrex@sap.com References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> In-Reply-To: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 8435C770-3A29-11E0-BF58-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 00:03:07 -0000 I see the potential problem. For me, though, I just hold onto all of the handshake messages until the handshake concludes. It may use a bit more memory for a short amount of time, but the issue you raise is completely avoided. Call it a space <-> code complexity trade-off. In TLS 1.2, a CertificateRequest message is where the server tells the client which signature algorithms are acceptable. I don't think it's allowed to be an empty list, but if it is, the sensible thing to do is to assume the same hash functions are supported as previous versions which didn't have that parameter. In other words choose rsa/sha1, rsa/md5 or dsa/sha1. This issue would have been avoided if the supported_signature_algorithms extension was symmetric and allowed the server to specify its list of algorithms in a ServerHello extension. Alas, that was not the design we ended up with. Mike Martin Rex wrote: > > The more I think about it, the more I believe it is, in fact, a > design flaw in TLSv1.2 responsible for a handshake performance issue > (at least when a client certificate is requested). > > > While the PRF was changed from SSLv3->TLSv1.0, there was no change to > the CertificateVerify handshake message. So for creating and > verifying a CertificateVerify handshake message, two hashes must > be maintained over all handshake messages: MD5 + SHA1. > > With TLSv1.2, if a server does not want to artificially limit the > signature algorithms on acceptable client certificates, it must > send a long list of acceptable combinations > > (sha1,rsa), (sha1,dsa), (sha256,rsa), (sha384,rsa), (sha512,rsa), > (sha224,dsa), (sha256,dsa), ... > > So unless both, server and client must either hold on to all handshake > messages up to CertificateVerify or carry along hash contexts for all > of the possible algorithms. > > Compare: > SSLv3, TLSv1.0/1.1 md5 + sha1 > TLSv1.2 md5 + sha1 + sha224 + sha256 + sha384 + sha512 > > If you look at this list, look at how TLS uses hashes for digital > signatures and think about the algorithmic relationships between > sha224&sha256 and between sha384&sha52, then sha224 and sha384 > are utterly useless fifth and sixth wheel on the TLS cart. > For TLS itself, sha256 -- or maybe even sha256 alone would have > been PERFECTLY sufficent, and a LOT less work. > > > What I also don't understand is the idea behind "default signature > algorithms". For implementing TLSv1.2, SHA-256 _must_ be supported, > but unless explicitly negotiated with the TLS SignatureAlgorithm > extension, SHA-256 appears not allowed to be used for CertificateVerify. > > That would mean, when TLSv1.2 is negotiated, but no SignatureAlgorithms > extension exchanged, the resulting signature with an RSA client cert > in CertificateVerify no longer uses MD5+SHA-1 as in TLS up to v1.1, > but _only_ SHA-1 (which slightly weakens that signature compared to > prior protocol versions...). The use of SHA-256 is prohibited!??! > > Weird, really. > > -Martin From wtc@google.com Wed Feb 16 17:30:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469763A6F08 for ; Wed, 16 Feb 2011 17:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MBJ7Qum7qM7 for ; Wed, 16 Feb 2011 17:30:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A7A513A6F02 for ; Wed, 16 Feb 2011 17:30:46 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p1H1VFwc031204 for ; Wed, 16 Feb 2011 17:31:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297906275; bh=AKLZIJfRdplNYrojpzmVXV4IZh8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=DoGzi6k2rsaKWJ4i21aYNWMd6yW5ufYPiOR852kSVQqzejA21pU1imvkLzYfhR7NI 7fd04hiFEZpk7MSn+E6zg== Received: from wwf26 (wwf26.prod.google.com [10.241.242.90]) by hpaq5.eem.corp.google.com with ESMTP id p1H1VEbT029436 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Feb 2011 17:31:14 -0800 Received: by wwf26 with SMTP id 26so2132340wwf.19 for ; Wed, 16 Feb 2011 17:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ALRFodL4Eyz8v2Y6I+tnAch2shjFhVuKU+izemA3+dU=; b=SWmmoZSobmrECg42txauHjeG1iwousdSsoI3EzOddtspziKWKnj/zOLAj/eEt87gXq rlk5Iu6o48Ct4pMFpjsA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hjQrBWUTDAGiyCSibWIb3hgSbQZakDbAPr+/WgGe3TfP0/xR0K7pAtz0v+asZtl35O +oP9JjJDWgziNL9tuAXg== MIME-Version: 1.0 Received: by 10.216.63.138 with SMTP id a10mr1074299wed.27.1297906273715; Wed, 16 Feb 2011 17:31:13 -0800 (PST) Received: by 10.216.6.81 with HTTP; Wed, 16 Feb 2011 17:31:13 -0800 (PST) In-Reply-To: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> References: <4D59B8FE.6010908@pobox.com> <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> Date: Wed, 16 Feb 2011 17:31:13 -0800 Message-ID: From: Wan-Teh Chang To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:30:48 -0000 On Wed, Feb 16, 2011 at 3:35 PM, Martin Rex wrote: > > What I also don't understand is the idea behind "default signature > algorithms". =A0For implementing TLSv1.2, SHA-256 _must_ be supported, > but unless explicitly negotiated with the TLS SignatureAlgorithm > extension, SHA-256 appears not allowed to be used for CertificateVerify. > > That would mean, when TLSv1.2 is negotiated, but no SignatureAlgorithms > extension exchanged, the resulting signature with an RSA client cert > in CertificateVerify no longer uses MD5+SHA-1 as in TLS up to v1.1, > but _only_ SHA-1 (which slightly weakens that signature compared to > prior protocol versions...). =A0The use of SHA-256 is prohibited!??! I think you're right. RFC 5246 Section 7.4.1.4.1 seems to say that {sha1,rsa} is the default RSA signature algorithm. I guess the solution is for a TLS 1.2 client to always send the signature_algorithms extension, and for a TLS 1.2 server to use a non-empty supported_signature_algorithms field in the Certificate Request message. Alternatively, we can amend RFC 5246 to change the default RSA signature algorithm to {sha256,rsa} . It seems that anything that uses MD5+SHA-1 in TLS 1.0 and 1.1 should use SHA-256 by default in TLS 1.2, for consistency. Wan-Teh Chang From ynir@checkpoint.com Wed Feb 16 22:07:03 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8296F3A6D10 for ; Wed, 16 Feb 2011 22:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbSDg3EbTBOx for ; Wed, 16 Feb 2011 22:06:47 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0AF6D3A6DA5 for ; Wed, 16 Feb 2011 22:06:45 -0800 (PST) X-CheckPoint: {4D5CBB10-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1H67774005958; Thu, 17 Feb 2011 08:07:07 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Thu, 17 Feb 2011 08:07:07 +0200 From: Yoav Nir To: Wan-Teh Chang Date: Thu, 17 Feb 2011 08:07:08 +0200 Thread-Topic: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and Thread-Index: AcvOaOeqpf/UVQ5BQ16JCUBNI+XzTw== Message-ID: <2703ECBC-3054-4F51-B5B3-6256B43A0B8C@checkpoint.com> References: <4D59B8FE.6010908@pobox.com> <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 06:07:04 -0000 On Feb 17, 2011, at 3:31 AM, Wan-Teh Chang wrote: > On Wed, Feb 16, 2011 at 3:35 PM, Martin Rex wrote: >>=20 >> What I also don't understand is the idea behind "default signature >> algorithms". For implementing TLSv1.2, SHA-256 _must_ be supported, >> but unless explicitly negotiated with the TLS SignatureAlgorithm >> extension, SHA-256 appears not allowed to be used for CertificateVerify. >>=20 >> That would mean, when TLSv1.2 is negotiated, but no SignatureAlgorithms >> extension exchanged, the resulting signature with an RSA client cert >> in CertificateVerify no longer uses MD5+SHA-1 as in TLS up to v1.1, >> but _only_ SHA-1 (which slightly weakens that signature compared to >> prior protocol versions...). The use of SHA-256 is prohibited!??! >=20 > I think you're right. RFC 5246 Section 7.4.1.4.1 seems to say that > {sha1,rsa} is the default RSA signature algorithm. >=20 > I guess the solution is for a TLS 1.2 client to always send the > signature_algorithms extension, and for a TLS 1.2 server to use > a non-empty supported_signature_algorithms field in the > Certificate Request message. >=20 > Alternatively, we can amend RFC 5246 to change the default > RSA signature algorithm to {sha256,rsa} . It seems that anything > that uses MD5+SHA-1 in TLS 1.0 and 1.1 should use SHA-256 > by default in TLS 1.2, for consistency. If you change that, it becomes TLS 1.3. This is a non-backwards-compatible = change in default behavior. From n.mavrogiannopoulos@gmail.com Thu Feb 17 00:46:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9A53A6C6A for ; Thu, 17 Feb 2011 00:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlxq6ZjbEw2I for ; Thu, 17 Feb 2011 00:46:40 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 58D273A6ABF for ; Thu, 17 Feb 2011 00:46:40 -0800 (PST) Received: by wwa36 with SMTP id 36so2325586wwa.13 for ; Thu, 17 Feb 2011 00:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :openpgp:content-type:content-transfer-encoding; bh=NNHXM1i9uBSShKhwtMbzhUujWP9CjLCOCZtKSw3SWkA=; b=ZdPSNydD0Ib40+8KS30/DkQ1Va09zUMsgxFQ/Uq+OHYCVw3p84pzk1GoKB/hc1D9U0 EYw0UjkVTUzG/Rp24sY532+K4usiYN0hIoI3gVaaTpE1/vRncR13DbDF62SYOwM9BIVK 1C3w2UsmbCMNLk3QUcJwRsl+KswIpFyeTyprA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=lAv/gp+XtQvy/K+xW6msR/uWmxn8xrzPbC3skcct497B6PAmwd4cacK/rAqZcDBame lJAtmK/DgED6gGGFtyu6YCE7GSaK5DL2hO6Az7WBalh6lVLibwQarAJdt7LM24nQaSOt yzhhrpOaK5tbK30c+Yv1Hc1EKQ/yJAYzQHpIg= Received: by 10.216.13.134 with SMTP id b6mr76308web.25.1297932430017; Thu, 17 Feb 2011 00:47:10 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id o33sm266559wej.13.2011.02.17.00.47.08 (version=SSLv3 cipher=OTHER); Thu, 17 Feb 2011 00:47:09 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 09:47:08 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> In-Reply-To: <4D5C65D2.4060502@pobox.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 08:46:41 -0000 On 02/17/2011 01:03 AM, Michael D'Errico wrote: > I see the potential problem. For me, though, I just hold onto all > of the handshake messages until the handshake concludes. It may use > a bit more memory for a short amount of time, but the issue you raise > is completely avoided. Call it a space <-> code complexity > trade-off. Indeed. There is no other way to correctly implement TLS 1.2 except from holding a copy of all the handshake messages. This is problematic when converting an implementation of TLS 1.0 or 1.1 to that, since those protocols only required to hold the state of 1 or 2 running hashes. This is also not easy to fix in TLS 1.3. Even if TLS 1.3 only requires to hold the state of a single hash, implementations must be prepared to hold the entire state just in case TLS 1.2 is negotiated. > This issue would have been avoided if the > supported_signature_algorithms extension was symmetric and allowed > the server to specify its list of algorithms in a ServerHello > extension. Alas, that was not the design we ended up with. That was a bad design decision in TLS 1.2 (if we assume that not caching all messages was a requirement). regards, Nikos From ekr@rtfm.com Thu Feb 17 01:34:59 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05593A6D69 for ; Thu, 17 Feb 2011 01:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx7MxMhFeKUO for ; Thu, 17 Feb 2011 01:34:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 18B453A6D8C for ; Thu, 17 Feb 2011 01:34:58 -0800 (PST) Received: by iym1 with SMTP id 1so2290592iym.31 for ; Thu, 17 Feb 2011 01:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.228.5 with SMTP id jc5mr2397065icb.228.1297935328336; Thu, 17 Feb 2011 01:35:28 -0800 (PST) Received: by 10.42.178.193 with HTTP; Thu, 17 Feb 2011 01:35:28 -0800 (PST) In-Reply-To: <4D5CE08C.5060402@gnutls.org> References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 11:35:28 +0200 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 09:34:59 -0000 On Thu, Feb 17, 2011 at 10:47 AM, Nikos Mavrogiannopoulos wrote: > On 02/17/2011 01:03 AM, Michael D'Errico wrote: >> I see the potential problem. =A0For me, though, I just hold onto all >> of the handshake messages until the handshake concludes. =A0It may use >> a bit more memory for a short amount of time, but the issue you raise >> is completely avoided. =A0Call it a space <-> code complexity >> trade-off. > > Indeed. There is no other way to correctly implement TLS 1.2 except > from holding a copy of all the handshake messages. This is problematic > when converting an implementation of TLS 1.0 or 1.1 to that, since > those protocols only required to hold the state of 1 or 2 running hashes. Is that really true?. My memory from the discussions and briefly refreshed by looking at the doc is that you only need to hold the messages until you see the ServerHello at which point you know the PRF and so you can just start storing hashes. Best, -Ekr From n.mavrogiannopoulos@gmail.com Thu Feb 17 01:48:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1963A6DCB for ; Thu, 17 Feb 2011 01:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcnYDl42WNqd for ; Thu, 17 Feb 2011 01:48:36 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 0EB7F3A6D69 for ; Thu, 17 Feb 2011 01:48:35 -0800 (PST) Received: by qyj19 with SMTP id 19so2325995qyj.10 for ; Thu, 17 Feb 2011 01:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IuinEXx6y/NQr/bok99zHcsgcHuiKUA7kqPAQvH9y9A=; b=XQ03hCHWIZ97G5jaNQLqr5xtiaSBfwgWl4bWcH1/Bx9igttzXZrqRkcaSl2QZoC/Ci 2AOYfT4I71Ykl9eyU57g1EqdXOJ6m4Lrn4yqQamwVJsS2BboJsRaA+279zLGUuHDUFh1 VLF9AeHijdh2P32FibKB1DFyomjnJ1ErSfQ/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XLPmWBwDdrwHZIZA37sUdMCtj13IErgh0ex5jamFM5W2mqzMZR65//YrhqtNANu+VQ E6WslsRHzfglbJAAcgC9JFoVTGGARME7/baf4V4Dpl842PeOyj1GDyBQVrb/Lh8U4SaO EdYSMbCO37X9H49be+Izi59+f23j5bQmAPCOI= MIME-Version: 1.0 Received: by 10.229.218.197 with SMTP id hr5mr2077864qcb.14.1297936146067; Thu, 17 Feb 2011 01:49:06 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 17 Feb 2011 01:49:06 -0800 (PST) In-Reply-To: References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 10:49:06 +0100 X-Google-Sender-Auth: 71bJnpLH7XXJUXylRRJw-UwKMfs Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 09:48:37 -0000 On Thu, Feb 17, 2011 at 10:35 AM, Eric Rescorla wrote: >>> I see the potential problem. =C2=A0For me, though, I just hold onto all >>> of the handshake messages until the handshake concludes. =C2=A0It may u= se >>> a bit more memory for a short amount of time, but the issue you raise >>> is completely avoided. =C2=A0Call it a space <-> code complexity >>> trade-off. >> Indeed. There is no other way to correctly implement TLS 1.2 except >> from holding a copy of all the handshake messages. This is problematic >> when converting an implementation of TLS 1.0 or 1.1 to that, since >> those protocols only required to hold the state of 1 or 2 running hashes= . > Is that really true?. My memory from the discussions and briefly > refreshed by looking at the > doc is that you only need to hold the messages until you see the > ServerHello at which point > you know the PRF and so you can just start storing hashes. Note that you're talking about the hashes required for the finished messages and you're correct on this note. However there is also the hash required for the CertificateVerify message. If the server requests a client certificate then it has to store all messages up to (but not including) the CertificateVerify message. That is because he cannot possibly know which signature algorithm hash the client will use. In TLS 1.0 and 1.1 the same hashes as the ones in the finished messages were being used, so that was not an issue. regards, Nikos From ekr@rtfm.com Thu Feb 17 02:54:07 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADB43A6DCB for ; Thu, 17 Feb 2011 02:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg+QXcRmSdkw for ; Thu, 17 Feb 2011 02:54:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 3AC8C3A6DC6 for ; Thu, 17 Feb 2011 02:54:06 -0800 (PST) Received: by iym1 with SMTP id 1so2363486iym.31 for ; Thu, 17 Feb 2011 02:54:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.213.194 with SMTP id gx2mr2494241icb.27.1297940075921; Thu, 17 Feb 2011 02:54:35 -0800 (PST) Received: by 10.42.178.193 with HTTP; Thu, 17 Feb 2011 02:54:35 -0800 (PST) In-Reply-To: References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 12:54:35 +0200 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 10:54:07 -0000 On Thu, Feb 17, 2011 at 11:49 AM, Nikos Mavrogiannopoulos wrote: > On Thu, Feb 17, 2011 at 10:35 AM, Eric Rescorla wrote: > >>>> I see the potential problem. =A0For me, though, I just hold onto all >>>> of the handshake messages until the handshake concludes. =A0It may use >>>> a bit more memory for a short amount of time, but the issue you raise >>>> is completely avoided. =A0Call it a space <-> code complexity >>>> trade-off. >>> Indeed. There is no other way to correctly implement TLS 1.2 except >>> from holding a copy of all the handshake messages. This is problematic >>> when converting an implementation of TLS 1.0 or 1.1 to that, since >>> those protocols only required to hold the state of 1 or 2 running hashe= s. >> Is that really true?. My memory from the discussions and briefly >> refreshed by looking at the >> doc is that you only need to hold the messages until you see the >> ServerHello at which point >> you know the PRF and so you can just start storing hashes. > > Note that you're talking about the hashes required for the finished > messages and you're correct on this note. However there is also the > hash required for the CertificateVerify message. If the server requests > a client certificate then it has to store all messages up to (but not > including) the CertificateVerify message. > That is because he cannot possibly know which signature algorithm > hash the client will use. Agreed. I can't recall if we discussed this when this feature was being des= igned for 5246 but ISTM that the only way to have this work that didn't have this property would be for the client to offer all his certificates up-front and the server to select one, since it's possible that each cert comes with a speci= fic hash algorithm tied to it. -Ekr From n.mavrogiannopoulos@gmail.com Thu Feb 17 03:17:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917463A6C8D for ; Thu, 17 Feb 2011 03:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVXaJJIVwQ-b for ; Thu, 17 Feb 2011 03:17:24 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B92BE3A6C87 for ; Thu, 17 Feb 2011 03:17:24 -0800 (PST) Received: by qyj19 with SMTP id 19so2384399qyj.10 for ; Thu, 17 Feb 2011 03:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7QcWzC80c/PjjQxeXkYR59LeN6bMF5mjrNyKg3fKy8A=; b=RnNE3xihU4V5WIcOZUmpYFcMHR/r161+85bHM0bawGf9YqDtITNRr/BgvPRXHEdyIN U58WggpY7AM7g9L9Pk4o/NPAF0cXCaWY0tWoj8GysCNMfWIF6pPqDbPBTndIwJmA0SS9 b2iFwm60gCS5hVKGCcneHTl7Fxa9CLR0NjCho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QM2YipOloj83PidyX5zl9QYcS85I8LwdQE3pQW6bjVBMG6qtUO5cPlu1M7u3KA4Xit XHpD1fH8jFa5mx371scezNaoPagUxfKx5GCJT4b6tqpPYaRBxkpDGmMoM11DSUvqGbVF v0qpdnDEwcXpnaRn4c5Udy90u1rfjArYIk3UQ= MIME-Version: 1.0 Received: by 10.229.220.83 with SMTP id hx19mr2158850qcb.52.1297941474248; Thu, 17 Feb 2011 03:17:54 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 17 Feb 2011 03:17:54 -0800 (PST) In-Reply-To: References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 12:17:54 +0100 X-Google-Sender-Auth: vgUcPpW_t9QvNdMfag1FdDdYdlw Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 11:17:25 -0000 On Thu, Feb 17, 2011 at 11:54 AM, Eric Rescorla wrote: >> Note that you're talking about the hashes required for the finished >> messages and you're correct on this note. However there is also the >> hash required for the CertificateVerify message. If the server requests >> a client certificate then it has to store all messages up to (but not >> including) the CertificateVerify message. >> That is because he cannot possibly know which signature algorithm >> hash the client will use. > Agreed. I can't recall if we discussed this when this feature was being designed > for 5246 but ISTM that the only way to have this work that didn't have > this property would be for the client to offer all his certificates > up-front and the > server to select one, since it's possible that each cert comes with a specific > hash algorithm tied to it. To which PKIX certificate field are you referring to? regards, Nikos From yngve@opera.com Thu Feb 17 04:53:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D573A6DE4 for ; Thu, 17 Feb 2011 04:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC3eUyWFluEM for ; Thu, 17 Feb 2011 04:53:50 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id E131C3A6A91 for ; Thu, 17 Feb 2011 04:53:49 -0800 (PST) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1HCsIVm000585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Feb 2011 12:54:19 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 13:54:32 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.63 (Win32) Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 12:53:51 -0000 On Thu, 17 Feb 2011 11:54:35 +0100, Eric Rescorla wrote: > On Thu, Feb 17, 2011 at 11:49 AM, Nikos Mavrogiannopoulos > wrote: >> On Thu, Feb 17, 2011 at 10:35 AM, Eric Rescorla wrote: >> >>>>> I see the potential problem. For me, though, I just hold onto all >>>>> of the handshake messages until the handshake concludes. It may use >>>>> a bit more memory for a short amount of time, but the issue you raise >>>>> is completely avoided. Call it a space <-> code complexity >>>>> trade-off. >>>> Indeed. There is no other way to correctly implement TLS 1.2 except >>>> from holding a copy of all the handshake messages. This is problematic >>>> when converting an implementation of TLS 1.0 or 1.1 to that, since >>>> those protocols only required to hold the state of 1 or 2 running >>>> hashes. >>> Is that really true?. My memory from the discussions and briefly >>> refreshed by looking at the >>> doc is that you only need to hold the messages until you see the >>> ServerHello at which point >>> you know the PRF and so you can just start storing hashes. >> >> Note that you're talking about the hashes required for the finished >> messages and you're correct on this note. However there is also the >> hash required for the CertificateVerify message. If the server requests >> a client certificate then it has to store all messages up to (but not >> including) the CertificateVerify message. >> That is because he cannot possibly know which signature algorithm >> hash the client will use. > > Agreed. I can't recall if we discussed this when this feature was being > designed > for 5246 but ISTM that the only way to have this work that didn't have > this property would be for the client to offer all his certificates > up-front and the > server to select one, since it's possible that each cert comes with a > specific > hash algorithm tied to it. How about removing the need to calculated the verify message based on a specific hash of the handshake message? Currently the verify message is defined as struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } CertificateVerify; How about changing that to this? struct { digitally-signed struct { PRF(master_secret, verify_label, Hash(handshake_messages)) [0..f(Cert_Hash)-1]; } } CertificateVerify; This would remove the need to store all the handshake messages, or manage multiple hashes of the same data, since the handshake-hash would take care of that. Using the PRF means that we can generate a string that is of sufficient length for each method, although an alternative if one think that is too complex, or generally unnecessary, is to just use Hash(handshake_messages). A possible issue is how this would affect security if the Cert_Hash method is much more secure than the Hash method. My current opinion is that this can be handled by using f(Cert_Hash) to provide a sufficiently long PRF, unless there are issues I am unaware of with such a solution. I'll leave that to the members for experienced in cracking crypto constructs. Of course, making this change requires a new TLS protocol version. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From ekr@rtfm.com Thu Feb 17 05:39:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E644F3A6E0C for ; Thu, 17 Feb 2011 05:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wo7qJD7LwNf for ; Thu, 17 Feb 2011 05:39:28 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1DCFD3A6E04 for ; Thu, 17 Feb 2011 05:39:28 -0800 (PST) Received: by iwc10 with SMTP id 10so2669587iwc.31 for ; Thu, 17 Feb 2011 05:39:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.228.5 with SMTP id jc5mr2751393icb.228.1297949998882; Thu, 17 Feb 2011 05:39:58 -0800 (PST) Received: by 10.42.178.193 with HTTP; Thu, 17 Feb 2011 05:39:58 -0800 (PST) In-Reply-To: References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 15:39:58 +0200 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 13:39:29 -0000 On Thu, Feb 17, 2011 at 1:17 PM, Nikos Mavrogiannopoulos wrote: > On Thu, Feb 17, 2011 at 11:54 AM, Eric Rescorla wrote: >>> Note that you're talking about the hashes required for the finished >>> messages and you're correct on this note. However there is also the >>> hash required for the CertificateVerify message. If the server requests >>> a client certificate then it has to store all messages up to (but not >>> including) the CertificateVerify message. >>> That is because he cannot possibly know which signature algorithm >>> hash the client will use. >> Agreed. I can't recall if we discussed this when this feature was being designed >> for 5246 but ISTM that the only way to have this work that didn't have >> this property would be for the client to offer all his certificates >> up-front and the >> server to select one, since it's possible that each cert comes with a specific >> hash algorithm tied to it. > > To which PKIX certificate field are you referring to? I'm not. I'm talking about environments where (for instance) some of your keys are in hardware and so, can only be used to with a specific hash algorithm. It's not incredibly common, but I have seen it. -Ekr From n.mavrogiannopoulos@gmail.com Thu Feb 17 06:45:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D062F3A6F07 for ; Thu, 17 Feb 2011 06:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhl4UvraNspx for ; Thu, 17 Feb 2011 06:45:25 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id DEFBB3A6EEF for ; Thu, 17 Feb 2011 06:45:24 -0800 (PST) Received: by qyj19 with SMTP id 19so2561008qyj.10 for ; Thu, 17 Feb 2011 06:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5MFZ69Nmx9vSVRlx4aCdFkW5ewKoN+BAaOTPVPFgRCk=; b=lkZjzoo9zk+0gDrqDQDKk/YNOXioe78b6djEvZI5d02Gqese2Ip/aaO6vd+w+sb3aA hlqa+4XVlV3sBldp7jWI+S6ux1FHF1f2bjU5bTc9Iqp1ZFCKFZwlGKK4mdAQUPt0YOpz z9gndDxGW05ImRNNQ1v5rrVZ/kOb97mKwHxO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YVgfmF5MDQcl/CAe58gbE6DdvSKrLrDd46hx2fvuPQAjtSoJESiW7cLyq0aP8WDEav mpiAXZ5a4LM76xv2dvWYBpzXU0IeiUaJXV7nG0AdGYKUtm6ijm58QK9LMjDnIjWlm2lF zeIzS8pR3xOuRoazLoiH8h9OjqrzFJf+J535U= MIME-Version: 1.0 Received: by 10.229.218.197 with SMTP id hr5mr2446715qcb.14.1297953955471; Thu, 17 Feb 2011 06:45:55 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Thu, 17 Feb 2011 06:45:55 -0800 (PST) In-Reply-To: References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> Date: Thu, 17 Feb 2011 15:45:55 +0100 X-Google-Sender-Auth: XLgUsgVC5M26hdvd-Ae8ykHgj8Y Message-ID: From: Nikos Mavrogiannopoulos To: "Yngve N. Pettersen (Developer Opera Software ASA)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 14:45:25 -0000 On Thu, Feb 17, 2011 at 1:54 PM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: >> Agreed. I can't recall if we discussed this when this feature was being >> designed >> for 5246 but ISTM that the only way to have this work that didn't have >> this property would be for the client to offer all his certificates >> up-front and the >> server to select one, since it's possible that each cert comes with a >> specific >> hash algorithm tied to it. > How about removing the need to calculated the verify message based on a > specific hash of the handshake message? > Currently the verify message is defined as > =C2=A0 =C2=A0 =C2=A0struct { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 digitally-signed struct { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque handshake_message= s[handshake_messages_length]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > =C2=A0 =C2=A0 =C2=A0} CertificateVerify; > How about changing that to this? > =C2=A0 =C2=A0 =C2=A0struct { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 digitally-signed struct { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRF(master_secret,= verify_label, Hash(handshake_messages)) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[0..f(Cert_Hash)-1]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > =C2=A0 =C2=A0 =C2=A0} CertificateVerify; This is a nice idea for 1.3. (I'd replace Cert_Hash with selected_hash thou= gh). regards, Nikos From mrex@sap.com Fri Feb 18 11:28:11 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB7F3A6E27 for ; Fri, 18 Feb 2011 11:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTvO43X3JWXC for ; Fri, 18 Feb 2011 11:28:10 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2DE1F3A6D4A for ; Fri, 18 Feb 2011 11:28:09 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1IJSUbc020807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Feb 2011 20:28:30 +0100 (MET) From: Martin Rex Message-Id: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Fri, 18 Feb 2011 20:28:29 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Feb 17, 11 12:54:35 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:28:11 -0000 Eric Rescorla wrote: > > Nikos Mavrogiannopoulos wrote: > > If the server requests a client certificate then it has to store > > all messages up to (but not including) the CertificateVerify message. > > That is because he cannot possibly know which signature algorithm > > hash the client will use. > > Agreed. I can't recall if we discussed this when this feature was being > designed for 5246 but ISTM that the only way to have this work that > didn't have this property would be for the client to offer all his > certificates up-front and the server to select one, since it's > possible that each cert comes with a specific hash algorithm tied to it. I am quite confused by a few issues in TLSv1.2 / rfc-5246 about hash and signature algorithms. In particular, that TLSv1.2 forces TLS-proprietary digital signatures from the TLS handshake messages ServerKeyExchange and CertificateVerify into the same single algorithm negotiation with digital signatures on certificates appears to create significant new problems. rfc-5246, 7.4.2 Server Certificate last paragraph on page 49 http://tools.ietf.org/html/rfc5246#page-49 If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). ? This is ? a departure from TLS 1.1, which required that the algorithms be the ? same. I searched TLSv1.1 (rfc4346) from top to buttom but did NOT find any requirements about signature algorithms of certificates in that spec. I have also not noticed any such restrictions in TLS implementations I looked at. So I created a DSA-rootCA, an rsa-2048 server cert, started a TLSv1.0 with this and WindowsXP, Firefox3 an OpenSSL all happily communicate with it. So this part of rfc-5246 purports to solve a problem that actually does not exist in earlier versions of TLS. The "solution" that TLSv1.2 alleges to provides looks more like a cumbersome limitation to me. While there is zero problem of using certificate chains with arbitrary mixtures of signature algorithms in TLSv1.1 and prior, this doesn't work anymore when negotiating TLSv1.2, in particular for signature algorithms which can not be represented with the code points of TLSv1.2. TLS implementations that do not want to hang on to carry along all handshake messages may want the list of hashes permitted for the "digitally signed" construct in ServerKeyExchange and CertificateVerify to be as small as possible, while they may want to remain a liberal as possible about digital signature algorithms on certificates, similar to all version of TLS up to v1.1. It's unclear for me what motivated conflating two quite contradictory objectives into a single protocol element (the SignatureAlgorithm list in the ClientHelloExtension SignatureAlgorithm applying to both ServerCertificate and ServerKeyExchange handshake messages, and the list of SignatureAlgorithms in CertificateRequest applying to both ClientCertificate and CertificateVerify handshake messages. As a result of this, any PKIs with less common digital signature algorithms on path certificates that may have worked perfectly fine with SSLv3, TLSv1.0 and TLSv1.1, and continue to work with an implementation of TLSv1.2 that negotiates only v1.0 or v1.1 are required to fail by the TLSv1.2 spec when TLSv1.2 is negotiated, because of a lack of code points to represent digital signature AlgIDs plus the complete lack of knowledge about the AlgIDs supported in the PKI implementation within the architecturally independent TLS protocol stack. A year ago we started shipping support for GOST ciphersuites based on this proposal: http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 in our (at that time OEM) implementation of TLSv1.0, with the GOST crypto algorithms provided to the TLS stack through a plugin- interface to a third-party (certifiable) GOST crypto plugin. A very similar capability exists in Windows XPsp2, where the GOST cipher suites can be used with SChannel and MSIE6 after installation of an adequate CryptoCSP, although XP's SChannel is an implementation of TLSv1.0 with _no_ TLS extensions. I believe there exists more flexibility in TLSv1.0/v1.1 architecture than rfc5246 asserts. -Martin From juhovh@iki.fi Fri Feb 18 14:39:23 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7BC3A6DFD for ; Fri, 18 Feb 2011 14:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xfTUYnD9VfI for ; Fri, 18 Feb 2011 14:39:23 -0800 (PST) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id ACAFC3A6DB1 for ; Fri, 18 Feb 2011 14:39:22 -0800 (PST) Received: from vagabond.lan (88.192.41.71) by jenni1.inet.fi (8.5.133) id 4D060B9403200286 for tls@ietf.org; Sat, 19 Feb 2011 00:39:56 +0200 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-5--213467059; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sat, 19 Feb 2011 00:39:56 +0200 In-Reply-To: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> To: tls@ietf.org References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> Message-Id: <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> X-Mailer: Apple Mail (2.1082) Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 22:39:23 -0000 --Apple-Mail-5--213467059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18.2.2011, at 21.28, Martin Rex wrote: > So this part of rfc-5246 purports to solve a problem that actually > does not exist in earlier versions of TLS. The "solution" that > TLSv1.2 alleges to provides looks more like a cumbersome > limitation to me. While there is zero problem of using certificate > chains with arbitrary mixtures of signature algorithms in TLSv1.1 > and prior, this doesn't work anymore when negotiating TLSv1.2, > in particular for signature algorithms which can not be represented > with the code points of TLSv1.2. This discussion has been going on for quite long, but I just want to = mention that I support Martin here and I don't think I have seen a good = response yet. I found the same issue a bit weird when I was going = through the TLSv1.2 specification, but it wasn't relevant at the time so = I just ignored and forgot it. Forcing the TLS implementation to buffer all handshake messages is one = thing that probably a performance problem in TLSv1.2, but it's not a = compatibility issue and as someone said fixing it would require = releasing TLSv1.3. However I don't see ANY sensible reasons why TLS = would care about which signature algorithm is used for signing the = actual certificate. As long as the certificate contains the keys = necessary to sign the key exchange it should be fine just like it was = before. Yes, it might be possible for a client to for example only support one = single hash and one single signature algorithm, which is most likely a = combination included in signature_algorithms. In that case, I would = support that the server SHOULD choose the certificate chain according to = the sent signature_algorithms if possible. However if there is no such = certificate chain available, it MUST continue the handshake by sending = some valid certificate. The server has no way to know if the client can = verify certificate chains outside the defined TLS signature algorithms, = therefore it would be plain stupid for the server to abort the handshake = just because it has a certificate which is signed with an algorithm not = supported by TLS. (especially if both sides can handle it) I don't think changing this from MUST to SHOULD would cause major = compatibility issues, because for TLSv1.0 and TLSv1.1 the clients need = to prepare for any kinds of certificates anyway. If someone has actually = written code that rejects certificates that don't match the sent = signature_algorithms it might cause an error, has anyone on this list = written that kind of code or seen it anywhere? Personally I find the = meddling with certificate signature hash and type annoying enough that I = am inclined to ignore it, even if that means incompatibility.... Juho --Apple-Mail-5--213467059 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMjE4MjIzOTU2WjAjBgkqhkiG9w0BCQQxFgQUaD6bgNbHQDR+c1ANYYHv2UaF+s8wgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEANM95zekuj6y5mfnTK52Cuf7Awvd96u4MIiS6gFVBbJQ2cNycK7e0gjdf2xEs2SN7K1CP c3OmLuT8d8PwPhfzj0lEtv2Q4DKppB9GSRMSsRiOid4OIW+1zU4+bQK0bNXGJK3ZGUnjzquEL/ua 9SnOYD6663wcc0JHf+UN0pG+lEWI7FfaQQ5riif3M9Ckq7l0zvWFSbmJ7qMhy0V3Dc7nR0lEax70 GG7hd2w1Zw942f7KVCK+WPcz7ozODxqc9htLgWAsXwCKI4VJQ1grN2M3H4RDt8ozMG3ojS2MQRWI I+vRADgu8AGMG6PMgWWOyu2jzwYNQ5kqZ/j1JbPtkwDDUQAAAAAAAA== --Apple-Mail-5--213467059-- From mike-list@pobox.com Fri Feb 18 17:06:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6233C3A6E3D for ; Fri, 18 Feb 2011 17:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjoFWGK8hH36 for ; Fri, 18 Feb 2011 17:06:28 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id B94503A6D9C for ; Fri, 18 Feb 2011 17:06:27 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 256523910; Fri, 18 Feb 2011 20:08:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=umXWRmGVHYkW SS/z4d2GqK72nfE=; b=N4LRu2tmWL74oHqFvKOsQ27ehTUkpSO+CUYdC9m9HGb5 KyNlf0HsMz2+C1VvHjBk+3HUax1/RzsnowLK6MzmJRy1KF+NkqpPlk09yFZU+o1g qFWCIhDtjofYHSbvWecx/Fy+VndZH1V3htNMwKlHOdZnNbPJLw0YZ7I0bkwJjlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=mE0zZQ SBH+rHb/60Cthgwh57GnejBYEZFXnGfHr7wlaAozCzPeFxL/f4JC87U2Ki1GTt0m /mCZVAIlh47RfjZ4qIt8zKLxLx3ploxkHXyjdSasboZqerFRoC2VjxrxCk3FCm8W mTWQQtMPcED1Qi+xPtN/5mBEarelb52+bHKHI= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 11FFA390F; Fri, 18 Feb 2011 20:08:09 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 5700F390E; Fri, 18 Feb 2011 20:08:07 -0500 (EST) Message-ID: <4D5F17B1.9030608@pobox.com> Date: Fri, 18 Feb 2011 17:06:57 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> In-Reply-To: <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Pobox-Relay-ID: B6F60FFC-3BC4-11E0-968B-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 01:06:30 -0000 The point of the signature_algorithms extension is to permit a graceful upgrade of server certificates to using better than SHA-1 hash functions. You couldn't just suddenly switch your server cert to one signed with RSA/SHA-256 and expect every client to cope. It would certainly cause problems for some. To benefit from the extension, you would need to have two concurrent server certificates: one signed with RSA/SHA-1, and another signed with RSA/SHA-256. Then based on the signature algorithms presented by the client, your TLS code would choose the best one. My server actually does this and you can try it out: https://www.mikestoolbox.net If you connect using TLS 1.2 and tell it you support RSA/SHA-256, you will get back a server certificate signed with that algorithm. Otherwise you'll get the one signed with RSA/SHA-1. Mike Juho V=E4h=E4-Herttua wrote: > On 18.2.2011, at 21.28, Martin Rex wrote: >> So this part of rfc-5246 purports to solve a problem that actually >> does not exist in earlier versions of TLS. The "solution" that >> TLSv1.2 alleges to provides looks more like a cumbersome >> limitation to me. While there is zero problem of using certificate >> chains with arbitrary mixtures of signature algorithms in TLSv1.1 >> and prior, this doesn't work anymore when negotiating TLSv1.2, >> in particular for signature algorithms which can not be represented >> with the code points of TLSv1.2. >=20 > This discussion has been going on for quite long, but I just want to me= ntion that I support Martin here and I don't think I have seen a good res= ponse yet. I found the same issue a bit weird when I was going through th= e TLSv1.2 specification, but it wasn't relevant at the time so I just ign= ored and forgot it. >=20 > Forcing the TLS implementation to buffer all handshake messages is one = thing that probably a performance problem in TLSv1.2, but it's not a comp= atibility issue and as someone said fixing it would require releasing TLS= v1.3. However I don't see ANY sensible reasons why TLS would care about w= hich signature algorithm is used for signing the actual certificate. As l= ong as the certificate contains the keys necessary to sign the key exchan= ge it should be fine just like it was before. >=20 > Yes, it might be possible for a client to for example only support one = single hash and one single signature algorithm, which is most likely a co= mbination included in signature_algorithms. In that case, I would support= that the server SHOULD choose the certificate chain according to the sen= t signature_algorithms if possible. However if there is no such certifica= te chain available, it MUST continue the handshake by sending some valid = certificate. The server has no way to know if the client can verify certi= ficate chains outside the defined TLS signature algorithms, therefore it = would be plain stupid for the server to abort the handshake just because = it has a certificate which is signed with an algorithm not supported by T= LS. (especially if both sides can handle it) >=20 > I don't think changing this from MUST to SHOULD would cause major compa= tibility issues, because for TLSv1.0 and TLSv1.1 the clients need to prep= are for any kinds of certificates anyway. If someone has actually written= code that rejects certificates that don't match the sent signature_algor= ithms it might cause an error, has anyone on this list written that kind = of code or seen it anywhere? Personally I find the meddling with certific= ate signature hash and type annoying enough that I am inclined to ignore = it, even if that means incompatibility.... >=20 >=20 > Juho From pgut001@login01.cs.auckland.ac.nz Fri Feb 18 18:11:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB0F3A6CF6 for ; Fri, 18 Feb 2011 18:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMp7OQ+7g1w4 for ; Fri, 18 Feb 2011 18:11:31 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 7504C3A6CA1 for ; Fri, 18 Feb 2011 18:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298081527; x=1329617527; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20TLS=20v1.2 =20performance=20(was=20Re:=20TLSv1.2=20with=20DSA=20clie nt=20cert=20and|Cc:=20tls@ietf.org|In-Reply-To:=20<201102 162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp>|Message-Id:=20 |Date:=20Sa t,=2019=20Feb=202011=2015:12:06=20+1300; bh=1hlPdQZSxqIZycsBYnR8iACOPAPuh/2P+ilSXOpop4Q=; b=fKIQZG3YvK3z/4A5hnGLi17MpPVMQrgsy8CxnHxbamB6e3q8RA+iPA3J GceSyd81COiAtXCRGPrC17PSTpdIE9SwgE8ckhB6rPvxOHXoLPZhi0FWl XFWGn0H1C/hJsxdq59s/4a19EzENyj0M5ETj6Jg8VItUOxuscKICBZV0y 8=; X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46883906" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 15:12:06 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqcIo-000571-GS; Sat, 19 Feb 2011 15:12:06 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqcIo-000295-1f; Sat, 19 Feb 2011 15:12:06 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> Message-Id: Date: Sat, 19 Feb 2011 15:12:06 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 02:11:33 -0000 Martin Rex writes: >The more I think about it, the more I believe it is, in fact, a design flaw >in TLSv1.2 responsible for a handshake performance issue (at least when a >client certificate is requested). Yes. I pointed this out a long time ago, you either have to cache all handshake messages or run multiple hashes in parallel until you know which one you need to settle on. Either option leads to performance suckage. From memory the response was "well, yeah, you just need to do that then". Peter. From pgut001@login01.cs.auckland.ac.nz Fri Feb 18 18:15:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BDF3A6D6D for ; Fri, 18 Feb 2011 18:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfcVONMIZFxz for ; Fri, 18 Feb 2011 18:15:32 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 0ADE83A6D10 for ; Fri, 18 Feb 2011 18:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298081768; x=1329617768; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20tls@ietf.org|Subject:=20Re:=20[ TLS]=20TLS=20v1.2=20performance=20(was=20Re:=20TLSv1.2=20 with=20DSA=20client=20cert=20and|In-Reply-To:=20<4D5CE08C .5060402@gnutls.org>|Message-Id:=20|Date:=20Sat,=2019=20Feb=202011 =2015:16:06=20+1300; bh=rFBe7gWuOfNDwwWMOfkgPTLwjJf4C+0GhyDKTPu9qh8=; b=VXuKmycHxryAPh+kUG4NGdBETgzcYbFxBipJfwMjhVsWguGOoriZoZMy Y/MIXKXEMi/Q7kfZCFHRQa/USLqboYevOlPPrbfn+XJDRDMQgKmCJ2Yer UULTlymZxbYY14uh3FrWY32MdWSuXSutCrtrGGXRP+y6ntCaTTTUHc/Iu 8=; X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46884022" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 15:16:07 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqcMg-0005EE-Hr; Sat, 19 Feb 2011 15:16:06 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqcMg-0002Gm-Fm; Sat, 19 Feb 2011 15:16:06 +1300 From: Peter Gutmann To: nmav@gnutls.org, tls@ietf.org In-Reply-To: <4D5CE08C.5060402@gnutls.org> Message-Id: Date: Sat, 19 Feb 2011 15:16:06 +1300 Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 02:15:33 -0000 Nikos Mavrogiannopoulos writes: >This is also not easy to fix in TLS 1.3. Even if TLS 1.3 only requires to >hold the state of a single hash, implementations must be prepared to hold the >entire state just in case TLS 1.2 is negotiated. But you know at the first message whether you're going to continue with TLS 1.2 or 1.3. If you only start the hashing after the first handshake packet then you only need to use the one hash that both sides have agreed on. Heck, you can even fix it right now with an extension (which is what my code does iff it finds another copy of my code at the other end). >That was a bad design decision in TLS 1.2 (if we assume that not caching all >messages was a requirement). Can I say "I toldja so" now? Peter. From mrex@sap.com Fri Feb 18 19:52:09 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5787A3A6EDF for ; Fri, 18 Feb 2011 19:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.226 X-Spam-Level: X-Spam-Status: No, score=-10.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nJ72n3BvCgs for ; Fri, 18 Feb 2011 19:52:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 342FE3A6D48 for ; Fri, 18 Feb 2011 19:52:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1J3qM37013649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Feb 2011 04:52:22 +0100 (MET) From: Martin Rex Message-Id: <201102190352.p1J3qL8N005353@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 19 Feb 2011 04:52:21 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Feb 19, 11 03:16:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 03:52:09 -0000 Peter Gutmann wrote: > > But you know at the first message whether you're going to continue with TLS > 1.2 or 1.3. If you only start the hashing after the first handshake packet > then you only need to use the one hash that both sides have agreed on. Heck, > you can even fix it right now with an extension (which is what my code does > iff it finds another copy of my code at the other end). What does your private extension look like? I also think it should be fairly easy to fix with a simple TLS extension that negotiates _only_ the hash that is going to be used for the digitalSignature struct in ServerKeyExchange or CertificateVerify. When the TLS extension carries a list of _only_ hash algorithms, SHA-256 is always implied by the extension (need not be listed, it will be the mandatory to implement hash). Client can propose other hashes, server will confirm exactly the one hash that is going to be used (instead of SHA-1) for those ciphersuites that do not imply/require something else (e.g. GOST). Such an extension could be used with TLSv1.0 and TLSv1.1 as well and would make the FIPS 186-3 DSA >1024 bit signatures work as well as ECDSA signatures (rfc-4492) with SHA-256. -Martin From marsh@extendedsubset.com Fri Feb 18 21:20:43 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76BA3A6CF7 for ; Fri, 18 Feb 2011 21:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59U7RnYV+DY3 for ; Fri, 18 Feb 2011 21:20:42 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 489A03A6DE5 for ; Fri, 18 Feb 2011 21:20:42 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Pqewi-0004rY-1l; Sat, 19 Feb 2011 05:01:28 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9E52360CC; Sat, 19 Feb 2011 05:21:14 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX196LuLceSn/ZbVPSkH9gdAsr1bZZHnBbzM= Message-ID: <4D5F534A.6050009@extendedsubset.com> Date: Fri, 18 Feb 2011 23:21:14 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 05:20:43 -0000 On 02/18/2011 08:12 PM, Peter Gutmann wrote: > > you either have to cache all > handshake messages or run multiple hashes in parallel until you know which one > you need to settle on. Either option leads to performance suckage. It seems like the bulk of the data in a handshake is in the certs, mostly sent by the server. So one server-side optimization might be to buffer all the handshake messages /except/ the server's fixed certs. You can make a guess from the most common hashes and run one or two in parallel. You could reconstruct the full handshake data if you guess wrong. More unfortunate complexity. :-( It's ironic to the point of being sub-optimal that endpoints are expected to bear the cost of running multiple hashes over the data - just to then throw away half the results. I saw somewhere NIST just standardized truncated SHA-512 variants. Isn't choice wonderful? - Marsh From pgut001@login01.cs.auckland.ac.nz Fri Feb 18 23:23:54 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58DD53A6DA5 for ; Fri, 18 Feb 2011 23:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1oj5UBd0Ry0 for ; Fri, 18 Feb 2011 23:23:52 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B5FD03A6D24 for ; Fri, 18 Feb 2011 23:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298100267; x=1329636267; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20TLS=20v1.2 =20performance=20(was=20Re:=20TLSv1.2=20with=20DSA=20clie nt|Cc:=20tls@ietf.org|In-Reply-To:=20<201102190352.p1J3qL 8N005353@fs4113.wdf.sap.corp>|Message-Id:=20|Date:=20Sat,=2019=20Feb =202011=2020:24:24=20+1300; bh=udwF49zc0fdbZeWaqF9uIveWbnI9J/jy6ec0KbNsfPA=; b=BPmR+cTcf31jE9co0bky1ZNI/jyNNlqrsDKspdx75+yKWxQVhUh6kxoq uEvWv7bXwYqOJSVNgGQVAPZLv1MTN9WDR9uu/VX4LAQ/uWawyOf9sQXNP lh+FddlEkExhN34dLwutFEM18/QiNr7pRNiczuB8mqW+eMpFAJPkOS4gP 0=; X-IronPort-AV: E=Sophos;i="4.62,191,1296990000"; d="scan'208";a="46902670" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 20:24:24 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqhB2-0005nE-Gx; Sat, 19 Feb 2011 20:24:24 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqhB2-0001rq-6o; Sat, 19 Feb 2011 20:24:24 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201102190352.p1J3qL8N005353@fs4113.wdf.sap.corp> Message-Id: Date: Sat, 19 Feb 2011 20:24:24 +1300 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 07:23:54 -0000 Martin Rex writes: >What does your private extension look like? Just an I-am-here for my own code, which imples only SHA-256 will be used and there's no need to do any other type of hashing (it also implies some other things that allow shortcuts in processing). >I also think it should be fairly easy to fix with a simple TLS extension that >negotiates _only_ the hash that is going to be used for the digitalSignature >struct in ServerKeyExchange or CertificateVerify. Yup, that would be the more general way of doing it, the client provides a set of choices and the server picks the one that it wants, so the client has to cache at most one message and the server none. >Such an extension could be used with TLSv1.0 and TLSv1.1 as well and would >make the FIPS 186-3 DSA >1024 bit signatures work as well as ECDSA signatures >(rfc-4492) with SHA-256. Yup, it would certainly make the handshake less painful. Peter. From juhovh@iki.fi Sat Feb 19 00:40:49 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0098F3A6E93 for ; Sat, 19 Feb 2011 00:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqM2+UgrtiCC for ; Sat, 19 Feb 2011 00:40:48 -0800 (PST) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id D9AD23A6D4F for ; Sat, 19 Feb 2011 00:40:47 -0800 (PST) Received: from vagabond.lan (88.192.41.71) by kirsi1.inet.fi (8.5.133) id 4D072CA7032C1DAB; Sat, 19 Feb 2011 10:41:20 +0200 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-6--177404048; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4D5F17B1.9030608@pobox.com> Date: Sat, 19 Feb 2011 10:40:59 +0200 Message-Id: <450D2317-1125-4008-AC6C-CFDECA94C05C@iki.fi> References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> <4D5F17B1.9030608@pobox.com> To: Michael D'Errico X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 08:40:49 -0000 --Apple-Mail-6--177404048 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19.2.2011, at 3.06, Michael D'Errico wrote: > The point of the signature_algorithms extension is to permit a = graceful > upgrade of server certificates to using better than SHA-1 hash = functions. > You couldn't just suddenly switch your server cert to one signed with > RSA/SHA-256 and expect every client to cope. It would certainly cause > problems for some. >=20 > To benefit from the extension, you would need to have two concurrent > server certificates: one signed with RSA/SHA-1, and another signed = with > RSA/SHA-256. Then based on the signature algorithms presented by the > client, your TLS code would choose the best one. Yes, but even in this case I think it would make much more sense to have = the requirement as SHOULD and not MUST. Because if all the server has is = RSA/SHA-1 and the client is requesting RSA/SHA-256, I think it's much = better that the server will continue with RSA/SHA-1 and then the client = can fail if it doesn't like it. How does your implementation work by the = way if the requested SHA/SHA-256 is not found? I expect you have a = client implementation as well, does it check that all the server = certificate signatures match the signature_algorithms extension sent in = ClientHello and fail if not? I think it's ok to use signature_algorithms as a recommended list of = algorithms and then fall back to locally configured preference if that = is not found, worst case is that the handshake fails, but it would fail = anyway if no suitable certificate is found...=20 Juho --Apple-Mail-6--177404048 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMjE5MDg0MDU5WjAjBgkqhkiG9w0BCQQxFgQU5j3/dCgXx0+oDdx0iLqLFjgbdu4wgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAUbdO+DOZ1POSudqEtRuZ1CHCcsOEyQiXCWDTT0WGrgOBKJbcGzbSrgWSbh863koYFrTA AcI9I8HoS7FvCL050Xf6UL0+7LRpk0J/ce9a6yEnhkHv647pFESA814HtFLogMJI+XF4GDYO5iGp KKIRwOyZn5rWup4peOWv5Sb9wUQwe3Wm3vFv5iJDlbj71b0bi6J36qc1aJViJerpSebuEWwI7Jbb TuFc/km0arqaHpQQXjkLLBM+I632gb/53+GI/cyIYjgaJAjjxIrjeyjXbnoIl7lUZbCjAFU28UAu Ss5qulwlm+DZL7XKNMQoopImChhX88GbkYINBCxdB0KUAwAAAAAAAA== --Apple-Mail-6--177404048-- From n.mavrogiannopoulos@gmail.com Sat Feb 19 00:56:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7363A6E93 for ; Sat, 19 Feb 2011 00:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zANRJdtEkXV1 for ; Sat, 19 Feb 2011 00:56:29 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 82D253A6DB5 for ; Sat, 19 Feb 2011 00:56:29 -0800 (PST) Received: by ewy8 with SMTP id 8so2053589ewy.31 for ; Sat, 19 Feb 2011 00:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=1TJPHZRB90+8IjECAwqBi0wpReDrPoeZVWvmwu8ye58=; b=GaPQvhIHYSMpBU90oGIWgJ5dPZwiWt2wTJUSlu7+MPsdyzRveD1V2t3MAqZH3g2U23 M2y1gKUUhzbkKhkj7dFB+kPqfingEKVjbaFvMhu0POnQfuGCh4NfoAWe6wGrFUxpx4Bz ZICQNdGTkAkKWDsdIGaYEwt5E9DjwxKwxjDQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=e+ryp4sJ6pWSPgdk4seIcXny0DBtyfXlItanoxoLInqLnop3GEBFarjyp5jWtbDxQ1 PNXgEbSTrVbH5EBbIi85glw5TyHYAbUJPOG3HGNbzz2C/kcbWkl+Am+SmA9Xqf+eQt8g nfdoD9SpEQj3xn977RNIvFZ7QgZaRzzyqbBe4= Received: by 10.213.109.199 with SMTP id k7mr2023444ebp.96.1298105824317; Sat, 19 Feb 2011 00:57:04 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id t5sm2684709eeh.20.2011.02.19.00.57.02 (version=SSLv3 cipher=OTHER); Sat, 19 Feb 2011 00:57:03 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D5F85DE.4040106@gnutls.org> Date: Sat, 19 Feb 2011 09:57:02 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Michael D'Errico References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> <4D5F17B1.9030608@pobox.com> In-Reply-To: <4D5F17B1.9030608@pobox.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 08:56:30 -0000 On 02/19/2011 02:06 AM, Michael D'Errico wrote: > The point of the signature_algorithms extension is to permit a graceful > upgrade of server certificates to using better than SHA-1 hash functions. > You couldn't just suddenly switch your server cert to one signed with > RSA/SHA-256 and expect every client to cope. It would certainly cause > problems for some. > To benefit from the extension, you would need to have two concurrent > server certificates: one signed with RSA/SHA-1, and another signed with > RSA/SHA-256. Then based on the signature algorithms presented by the > client, your TLS code would choose the best one. It's pretty bad that a single extension is being used for two distinct use-cases[0]. The use cases are: * Negotiate which signature algorithms to use for Server Key Exchange, and Certificate Verify messages. * Specify the signature algorithms allowed by a certificate sent by the server. There is no reason to assume that these are related. The first use-case applies to the server and client since they are the ones doing the signing. On this use case a reply to this extension with the selected algorithm is required to avoid caching all messages up to the point of signing. The latter use-case is relevant to the client only, and says, I don't accept a certificate that is not signed with any of these algorithms. The server however obtains his certificate already signed through a 3rd party (a CA), so there is little to do in the general case. This use-case does not require a reply to the extension from the server. I think that those extensions could be split into two to account for the different use-cases. regards, Nikos [0]. What if I have a security module doing TLS that supports only RSA-SHA256 for signatures, but I have no restriction for the verification of the certificates since this is done outside of the module? From mike-list@pobox.com Sat Feb 19 01:43:58 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB6C3A6FD6 for ; Sat, 19 Feb 2011 01:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MymdYHw8Z7w1 for ; Sat, 19 Feb 2011 01:43:57 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 707B93A6E5B for ; Sat, 19 Feb 2011 01:43:56 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0F6922D10; Sat, 19 Feb 2011 04:45:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=kKr3oyVOSsay C9Xi2+e3x8nmiPo=; b=tpXyIomWwzBzut8QHCbTngS3ux4ATJpAg91Tnb54Qv/x oKsp7eLR09GEwAkVxbuElQGYLMEkURZUGW0Qt5nJyTaAAv2P7ySCv35zlrXWsW9k nFhrZMa5qHng4x2TPbLt33En9CNi+IGhdLE+MIuBIomsGiFyju86SwgA3UYZpEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=JrMT/4 Yv3HSE9+fgLAv0fL/DDTMRxKojrFSLI7fFTC1yiiS9e942CEf0l7GPpxyHXoqy0L kCoxwFFVnOQ2rXj9N3Z3LSvkBSs5Rzf5rYx2z+Z12lG1Mx7o/+bFu64E8SZ7u4lT MbGXO1al9Fn4nQLI1lHo0bVrCMwP79m7tGhss= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id EE5742D0F; Sat, 19 Feb 2011 04:45:39 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 39C582D0E; Sat, 19 Feb 2011 04:45:37 -0500 (EST) Message-ID: <4D5F90FB.9010406@pobox.com> Date: Sat, 19 Feb 2011 01:44:27 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> <4D5F17B1.9030608@pobox.com> <450D2317-1125-4008-AC6C-CFDECA94C05C@iki.fi> In-Reply-To: <450D2317-1125-4008-AC6C-CFDECA94C05C@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Pobox-Relay-ID: 02BDEA5C-3C0D-11E0-8271-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 09:43:58 -0000 Juho V=E4h=E4-Herttua wrote: > On 19.2.2011, at 3.06, Michael D'Errico wrote: >> The point of the signature_algorithms extension is to permit a gracefu= l >> upgrade of server certificates to using better than SHA-1 hash functio= ns. >> You couldn't just suddenly switch your server cert to one signed with >> RSA/SHA-256 and expect every client to cope. It would certainly cause >> problems for some. >> >> To benefit from the extension, you would need to have two concurrent >> server certificates: one signed with RSA/SHA-1, and another signed wit= h >> RSA/SHA-256. Then based on the signature algorithms presented by the >> client, your TLS code would choose the best one. >=20 > Yes, but even in this case I think it would make much more sense to hav= e the requirement as SHOULD and not MUST. Because if all the server has i= s RSA/SHA-1 and the client is requesting RSA/SHA-256, I think it's much b= etter that the server will continue with RSA/SHA-1 and then the client ca= n fail if it doesn't like it. How does your implementation work by the wa= y if the requested SHA/SHA-256 is not found? I expect you have a client i= mplementation as well, does it check that all the server certificate sign= atures match the signature_algorithms extension sent in ClientHello and f= ail if not? Originally I made the server lenient; if there was no suitable certificat= e chain, then it would choose the "best" match and hope the client would accept it. But then I got a bug report from someone who suggested that the server should abort the handshake if there isn't a perfect match. Initially I disagreed, but their logic makes sense: if the client was willing to accept a certificate signed with RSA/SHA-1, then it would have included that algorithm in the list. Since it didn't (and in this case the client only wanted ECDSA certificates which I don't support yet), it was causing the client trouble. I'm pretty sure my client code is still lenient, but it's been a while since I looked at that part of it. Mike > I think it's ok to use signature_algorithms as a recommended list of al= gorithms and then fall back to locally configured preference if that is n= ot found, worst case is that the handshake fails, but it would fail anywa= y if no suitable certificate is found...=20 >=20 >=20 > Juho >=20 From juhovh@iki.fi Sat Feb 19 01:56:49 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB1B3A6EAC for ; Sat, 19 Feb 2011 01:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly3zBl2szXcC for ; Sat, 19 Feb 2011 01:56:48 -0800 (PST) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id 1524C3A6FE4 for ; Sat, 19 Feb 2011 01:56:48 -0800 (PST) Received: from vagabond.lan (88.192.41.71) by jenni1.inet.fi (8.5.133) id 4D060B94032368D7; Sat, 19 Feb 2011 11:57:21 +0200 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-7--172834219; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4D5F90FB.9010406@pobox.com> Date: Sat, 19 Feb 2011 11:57:09 +0200 Message-Id: <0B7CA5F9-67D5-42F9-BFA8-15E3B7BFFBB4@iki.fi> References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> <7B07CE79-74A3-4CED-90E9-5910E67E90C7@iki.fi> <4D5F17B1.9030608@pobox.com> <450D2317-1125-4008-AC6C-CFDECA94C05C@iki.fi> <4D5F90FB.9010406@pobox.com> To: Michael D'Errico X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 09:56:49 -0000 --Apple-Mail-7--172834219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19.2.2011, at 11.44, Michael D'Errico wrote: > Originally I made the server lenient; if there was no suitable = certificate > chain, then it would choose the "best" match and hope the client would > accept it. >=20 > But then I got a bug report from someone who suggested that the server > should abort the handshake if there isn't a perfect match. Initially = I > disagreed, but their logic makes sense: if the client was willing to > accept a certificate signed with RSA/SHA-1, then it would have = included > that algorithm in the list. Since it didn't (and in this case the = client > only wanted ECDSA certificates which I don't support yet), it was = causing > the client trouble. The bug report makes sense in a way, because that's what the TLSv1.2 RFC = currently says. However, I don't understand how it could cause the = client any extra trouble, because it has to validate the certificate it = is getting from the server anyway and abort the handshake. If sending = the wrong certificate type would somehow crash the client, it would be = an easy attack for anyone interested. Do you remember if they mentioned = more precisely about what kind of trouble it caused? The logic you mentioned doesn't really make sense to me, because as = mentioned before the client might be willing to accept a certificate = signed with RSA/SHA-1 but doesn't accept key exchange signed with = RSA/SHA-1. Also as Martin has brought up, there are some signature = combinations not supported by TLS at all, which the client has no = possibility to put on the signature_algorithms. So to try to conclude somehow, defining the certificate signature = requirements as SHOULD instead of MUST would be a minor quick fix that = would allow the above-mentioned lenient method. It would still allow the = client to send a preference for certain signature algorithms and = wouldn't fail any more handshakes than are already failed (assuming = clients are properly implemented), making it pretty compatible. = Separating the certificate selection signature algorithms and key = exchange signature algorithms as separate fields would be a proper fix, = but would need a new extension definition. Since the extension = definition is included in TLSv1.2 itself and the change is not = compatible with existing implementations, I suppose it would require = TLSv1.3. Juho --Apple-Mail-7--172834219 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMjE5MDk1NzA5WjAjBgkqhkiG9w0BCQQxFgQUI99O5WMoQRUO6L0eYMH+mmaSWv4wgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAbcpiPQJw1e4kxtF5B/y/Q6yukHAzo6E8zOzmmovm3cKh5EuwCX2s5Ij6C2KowX81k1Nj UrspO3D0ykZF88dzTmE/ypkM6TUuChMh9heZrpkDZsHR6Tx6EHvL5rpU0BnTh/ojxhVaSCyQxBGD YYylab7aGLdfnSELw7W4ytL4lijRN7H18beHhScIdXJBbKy4WLLAQZ9j0UyT2Eeuo+GHY2e28fr2 dntDSP0YcsB0PoUZaU7wXklQTCh2Fq6NiMOHrrtW803QNcxJtyzbrfzbxXu2ODRj6/qVkJhoNRXA CQvgBFdNaIrbEnR8g7J4bVbKnsev49UMUcX9sOISgkT0bQAAAAAAAA== --Apple-Mail-7--172834219-- From n.mavrogiannopoulos@gmail.com Sat Feb 19 08:49:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE593A6F53 for ; Sat, 19 Feb 2011 08:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGEXXToJLhkk for ; Sat, 19 Feb 2011 08:49:48 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A6F313A6DF6 for ; Sat, 19 Feb 2011 08:49:47 -0800 (PST) Received: by wyf23 with SMTP id 23so4970710wyf.31 for ; Sat, 19 Feb 2011 08:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=M5oRaLyIlOZvUb2m8hK64iUjddZhvLgNKDNh7eNAraM=; b=NyPMOyWvraV12+/XF1nKFG+9ci6fgi7zdUBMwv/09sUPUc2jWlFv8NuN0QGs98w1NB qfUBS+jQ0sbHpkybLxNQlRJ8AHTWzTEQYuQLjCGvteqVfWli3yKTQTR7AIRYXpxYC5gC ditLgz9Idg/wQH38RyH4nII5ojNue3zEMVRjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=lMoid8RY0M06xss3KRCYuX5S791FDaDoegf5yLlt63MTkJlikgbx7BaCunuEE8o9OX foD6pY0/MeQSWh+OciNfM//WSQdMFCVfrLO0GRGwpuk6RIikz3NMTFHs3kWGTDJGFnn0 SFSCCygFOavmAtDYO1pnaYa1jVS7qemlzlOck= Received: by 10.216.173.7 with SMTP id u7mr594322wel.50.1298134223421; Sat, 19 Feb 2011 08:50:23 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id o6sm2620182wbo.15.2011.02.19.08.50.21 (version=SSLv3 cipher=OTHER); Sat, 19 Feb 2011 08:50:22 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D5FF4CD.9070307@gnutls.org> Date: Sat, 19 Feb 2011 17:50:21 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tls@ietf.org" , nagendra@cs.stanford.edu, Eric Rescorla X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 16:49:48 -0000 Hello, While trying to implement DTLS 1.0, I had some issues with the way DTLS handles packet loss and retransmission during the handshake process. There is not an explicit acknowledgement per packet flight, but rather, an implicit acknowledgement is done by waiting for the the peer's next flight. This however has the following issues: 1. Retransmission timers depend on the time required for the peer to do calculations (if an explicit ACK is used then the timers only depend on peer's packet processing). 2. The last message sent by the client expects no reply from the server, thus there is not an implicit ACK. DTLS 1.2 tries to solve issue 2, by reading the next packet, checking whether it is application data, or handshake data, and if it is the latter retransmit. I find the above solution a hack, rather than a solution. That is because: * the retransmission code might have to receive and parse a packet (Application data) that is not intended for it, blurring the separation of the handshake process and the application data protocol. * If a packet (application data) is not received then the retransmission code has to wait for an unspecified amount of time for the peer's retransmission to occur (if packet was lost). For these reason I'd suggest to add explicit acknowledgement packets, at least for the last packet from client. regards, Nikos From ekr@rtfm.com Sat Feb 19 17:48:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAF03A6F2C for ; Sat, 19 Feb 2011 17:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUD1IxGKiqSj for ; Sat, 19 Feb 2011 17:48:06 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0063B3A6A6E for ; Sat, 19 Feb 2011 17:48:05 -0800 (PST) Received: by iwl42 with SMTP id 42so1745844iwl.31 for ; Sat, 19 Feb 2011 17:48:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.173.198 with SMTP id s6mr3008086icz.362.1298166523304; Sat, 19 Feb 2011 17:48:43 -0800 (PST) Received: by 10.42.178.193 with HTTP; Sat, 19 Feb 2011 17:48:43 -0800 (PST) In-Reply-To: <4D5FF4CD.9070307@gnutls.org> References: <4D5FF4CD.9070307@gnutls.org> Date: Sat, 19 Feb 2011 17:48:43 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 01:48:07 -0000 On Sat, Feb 19, 2011 at 8:50 AM, Nikos Mavrogiannopoulos wrote: > Hello, > =A0While trying to implement DTLS 1.0, I had some issues > with the way DTLS handles packet loss and retransmission > during the handshake process. There is not an > explicit acknowledgement per packet flight, > but rather, an implicit acknowledgement is done > by waiting for the the peer's next flight. Hi Nikos, I'm glad to hear you're implementing DTLS. > This however has the following issues: > 1. Retransmission timers depend on the time required > for the peer to do calculations (if an explicit > ACK is used then the timers only depend on peer's > packet processing). I agree that this is true, but I don't think it's really a big deal. You should be using initial retransmit times in the area of 200-500 ms, and this is really a lot faster than pretty much any computation the other side would be expected to do. And eve= n in the worst case, if you assume processing time is 0 you just end up doing a spurious retransmit. That doesn't seem bad. > 2. The last message sent by the client expects > no reply from the server, thus there is not > an implicit ACK. You must mean during resumption, since in the full handshake, the last message from the client is ACKed by the server's Finished. Regardless, I don't understand why this is an issue: both sides maintain retransmission timers and so if you sent message A and expect B and you don't get it, you retransmit A. So, in this case the server would retransmit his Finished in the expectation that the client would respond by resending the client's Finished. Obviously, someone has to speak last and t= he other side needs to enforce the receipt of the last message, but there's nothing unusual about that. Can you explain why this isn't adequate? > DTLS 1.2 tries to solve issue 2, by reading the next > packet, checking whether it is application data, or > handshake data, and if it is the latter retransmit. For the reasons above this seems to me to be merely an optimization to shortcut the timer above. -Ekr > I find the above solution a hack, rather than a > solution. That is because: > * the retransmission code might have to receive and parse a > packet (Application data) that is not intended for it, > blurring the separation of the handshake process and the > application data protocol. > > * If a packet (application data) is not received then > the retransmission code has to wait for an unspecified > amount of time for the peer's retransmission to occur (if > packet was lost). > > > For these reason I'd suggest to add explicit acknowledgement > packets, at least for the last packet from client. > > regards, > Nikos > From aerowolf@gmail.com Sun Feb 20 16:35:23 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E383A6CC3 for ; Sun, 20 Feb 2011 16:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TppKOJZnZpth for ; Sun, 20 Feb 2011 16:35:21 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 245003A6CF5 for ; Sun, 20 Feb 2011 16:35:21 -0800 (PST) Received: by gyc15 with SMTP id 15so511967gyc.31 for ; Sun, 20 Feb 2011 16:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:date:message-id:subject:in-reply-to :references:mime-version:content-type; bh=/u8S5mf0uwpt84Uok6SxeM8oTlv/EWdTonntX/bwZ1E=; b=BBaiCTnyqib+32UML6w3rYF8KET4yJvUK5+o7SRy7Jx+bpVA+oYM8vGxcTpKOiIVXv 0QtCJoyfTubpjIA6yn/GNCODPpe7sLzvcQUT+1tZntWu7uQa5FFhuxMaQr23XMpdjkJu U95N8SlnpiIHR/ejyBJTP1mWD4lvo1SCDdFDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; b=qc5kMWjBcyWkjNLDk/WluaUfqvK+4NNKLJ7/M7Xb6FwG+pdo0b+FsZ8yNlrqRq2OoP LFivRlzloukhipJ9RrUpc9jiDtSg6Hnb26vyGXgpVXp0aZ4hxXr4Fs+6UWpEOKOwYkgA qgyb/ym+OK59trQESdZCyLbJYPbULQiDrqgKs= Received: by 10.100.46.13 with SMTP id t13mr354405ant.116.1298248560927; Sun, 20 Feb 2011 16:36:00 -0800 (PST) Received: from [127.0.0.1] (c-71-202-74-146.hsd1.ca.comcast.net [71.202.74.146]) by mx.google.com with ESMTPS id c7sm5989550ana.17.2011.02.20.16.35.58 (version=SSLv3 cipher=OTHER); Sun, 20 Feb 2011 16:35:59 -0800 (PST) From: "Kyle Hamilton" To: =?ISO-8859-1?Q?Juho_V=e4h=e4-Herttua?= Date: Sun, 20 Feb 2011 16:36:07 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> References: from "Eric Rescorla" at Feb 17, 11 12:54:35 pm <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; charset=x-user-defined; boundary=gmsm1.6.0eqgkenoduk8a7ejtvfzc2 Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 00:35:23 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.6.0eqgkenoduk8a7ejtvfzc2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIEZyaSwgRmViIDE4LCAyMDExIGF0IDI6MzkgUE0sIEp1aG8gVuRo5C1IZXJ0dHVhIDxq dWhvdmhAaWtpLmZpPiB3cm90ZToNCj4gT24gMTguMi4yMDExLCBhdCAyMS4yOCwgTWFydGluIFJl eCB3cm90ZToNCj4gRm9yY2luZyB0aGUgVExTIGltcGxlbWVudGF0aW9uIHRvIGJ1ZmZlciBhbGwg aGFuZHNoYWtlIG1lc3NhZ2VzIGlzIG9uZSB0aGluZyB0aGF0IHByb2JhYmx5IGEgcGVyZm9ybWFu Y2UgcHJvYmxlbSBpbiBUTFN2MS4yLCBidXQgaXQncyBub3QgYSBjb21wYXRpYmlsaXR5IGlzc3Vl IGFuZCBhcyBzb21lb25lIHNhaWQgZml4aW5nIGl0IHdvdWxkIHJlcXVpcmUgcmVsZWFzaW5nIFRM U3YxLjMuIEhvd2V2ZXIgSSBkb24ndCBzZWUgQU5ZIHNlbnNpYmxlIHJlYXNvbnMgd2h5IFRMUyB3 b3VsZCBjYXJlIGFib3V0IHdoaWNoIHNpZ25hdHVyZSBhbGdvcml0aG0gaXMgdXNlZCBmb3Igc2ln bmluZyB0aGUgYWN0dWFsIGNlcnRpZmljYXRlLiBBcyBsb25nIGFzIHRoZSBjZXJ0aWZpY2F0ZSBj b250YWlucyB0aGUga2V5cyBuZWNlc3NhcnkgdG8gc2lnbiB0aGUga2V5IGV4Y2hhbmdlIGl0IHNo b3VsZCBiZSBmaW5lIGp1c3QgbGlrZSBpdCB3YXMgYmVmb3JlLg0KDQpCZWNhdXNlIFRMUyBpcyB0 aGUgbGF5ZXIgd2hlcmUgY29tbXVuaWNhdGlvbnMgcG9saWNpZXMgYXJlIG5lZ290aWF0ZWQuICBU aGUgY2xpZW50IGlzIGluZm9ybWluZyB0aGUgc2VydmVyIHRoYXQgKGUuZy4pIGl0IGRvZXNuJ3Qg YWNjZXB0IE1ENSBhcyBhIHZhbGlkIGhhc2ggYWxnb3JpdGhtIGZvciByZWFsdGltZSBjb21tdW5p Y2F0aW9uLiAgSWYgaXQgZG9lc24ndCBhY2NlcHQgaXQgZm9yIHJlYWx0aW1lIGNvbW11bmljYXRp b24sIHRoZXJlIGlzIGFsc28gbm8gcmVhc29uIHRvIGFjY2VwdCBpdCBmb3IgYW4gb2ZmbGluZSBw cm9vZiAtLSBiZWNhdXNlIGFuIGF0dGFja2VyIGhhcyB0aGF0IG11Y2ggbW9yZSB0aW1lIHRvIGZp bmQgYSBwcmVpbWFnZS4NCg0KPiBZZXMsIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIGZvciBhIGNsaWVu dCB0byBmb3IgZXhhbXBsZSBvbmx5IHN1cHBvcnQgb25lIHNpbmdsZSBoYXNoIGFuZCBvbmUgc2lu Z2xlIHNpZ25hdHVyZSBhbGdvcml0aG0sIHdoaWNoIGlzIG1vc3QgbGlrZWx5IGEgY29tYmluYXRp b24gaW5jbHVkZWQgaW4gc2lnbmF0dXJlX2FsZ29yaXRobXMuIEluIHRoYXQgY2FzZSwgSSB3b3Vs ZCBzdXBwb3J0IHRoYXQgdGhlIHNlcnZlciBTSE9VTEQgY2hvb3NlIHRoZSBjZXJ0aWZpY2F0ZSBj aGFpbiBhY2NvcmRpbmcgdG8gdGhlIHNlbnQgc2lnbmF0dXJlX2FsZ29yaXRobXMgaWYgcG9zc2li bGUuIEhvd2V2ZXIgaWYgdGhlcmUgaXMgbm8gc3VjaCBjZXJ0aWZpY2F0ZSBjaGFpbiBhdmFpbGFi bGUsIGl0IE1VU1QgY29udGludWUgdGhlIGhhbmRzaGFrZSBieSBzZW5kaW5nIHNvbWUgdmFsaWQg Y2VydGlmaWNhdGUuIFRoZSBzZXJ2ZXIgaGFzIG5vIHdheSB0byBrbm93IGlmIHRoZSBjbGllbnQg Y2FuIHZlcmlmeSBjZXJ0aWZpY2F0ZSBjaGFpbnMgb3V0c2lkZSB0aGUgZGVmaW5lZCBUTFMgc2ln bmF0dXJlIGFsZ29yaXRobXMsIHRoZXJlZm9yZSBpdCB3b3VsZCBiZSBwbGFpbiBzdHVwaWQgZm9y IHRoZSBzZXJ2ZXIgdG8gYWJvcnQgdGhlIGhhbmRzaGFrZSBqdXN0IGJlY2F1c2UgaXQgaGFzIGEg Y2VydGlmaWNhdGUgd2hpY2ggaXMgc2lnbmVkIHdpdGggYW4gYWxnb3JpdGhtIG5vdCBzdXBwb3J0 ZWQgYnkgVExTLiAoZXNwZWNpYWxseSBpZiBib3RoIHNpZGVzIGNhbiBoYW5kbGUgaXQpDQoNClR3 byByZWFzb25zIHdoeSB0aGlzIGlzIGluYXBwcm9wcmlhdGUuICBGaXJzdCwgaWYgdGhlIHNlcnZl ciBkb2Vzbid0IGhhdmUgYSBjZXJ0aWZpY2F0ZSBjaGFpbiB0aGUgY2xpZW50IHdpbGwgYWNjZXB0 LCBpdCBkb2Vzbid0IG5lZWQgdG8gd2FzdGUgdGhlIGJhbmR3aWR0aCAoaXQgZG9lc24ndCBuZWVk IHRvIGJyb2FkY2FzdCB0aGUgc2VydmVyJ3MgZGV0YWlscyB0byBzb21lb25lIHdobyB3b24ndCBh Y2NlcHQgdGhlbSBhbnl3YXkpLiAgU2Vjb25kLCBUTFMgYWxyZWFkeSBzcGVjaWZpZXMgYSB2YWxp ZCB1bmF1dGhlbnRpY2F0ZWQgbW9kZS4gIFRoZSBvbmx5IHJlYXNvbiB3aHkgdW5hdXRoZW50aWNh dGVkIG1vZGVzIGFyZSB1bnBvcHVsYXIgaXMgYmVjYXVzZSBvZiB0aGUgY29tbW9ubHktaGVsZCB2 aWV3IG9mICJpZiB5b3UgZG9uJ3Qga25vdyB3aG8geW91J3JlIHRhbGtpbmcgdG8sIHdoYXQncyB0 aGUgcG9pbnQ/Ig0KDQotS3lsZSBIDQo= --gmsm1.6.0eqgkenoduk8a7ejtvfzc2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMTAyMjEwMDM2MDdaMCMGCSqGSIb3DQEJBDEWBBQMrNfC/Bpw/JqbRW+OoDm4 NieylTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEADOeBn7eFaSehs/5ePY1vljVwrcowg/MW5UcEWUFl9GbsKdQxycwm6eg8/VMyDPgm8eNN TXmdTR4ej8TTMn5MYNkEszB8d0FnEkRdVHGjlKMwlXTEhhDgkgA+k0FogZIUynTv7g2BVaqIrzOJ tFAMK9gAppdVg1ws/5X6iZSeQhVwhvBM+unll/DOxNqkGUpHAnz94Xe9f25otQQRJ8XVB3hz+4F7 S98hZhxYqkerL4pAWgzXCx5mmGEN1qol4eJ+kfjZiPS/jCGreoEyzWAle6u02nbIYP0/sLToL0mY cW9inSLwaNn5kNJ4tquih31aaNpuX+A7kN2Nf1RzMUEJnQAAAAAAAA== --gmsm1.6.0eqgkenoduk8a7ejtvfzc2-- From n.mavrogiannopoulos@gmail.com Mon Feb 21 00:41:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6213A6F7A for ; Mon, 21 Feb 2011 00:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P+qFntyItm4 for ; Mon, 21 Feb 2011 00:41:37 -0800 (PST) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id 86AF63A6DFF for ; Mon, 21 Feb 2011 00:41:37 -0800 (PST) Received: by qwj9 with SMTP id 9so4999449qwj.27 for ; Mon, 21 Feb 2011 00:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zqWEEWdv8XvKsb6W/3J538qBusJKnc4NagqQeTs24L4=; b=B7ENoDzP5U5GExTt6gHt2tBi6txbMHbYVuCgoUQ45SyTisDl2XTII0nhq7c5Fa4DQJ KM9XSqpyDtO9oW5sgWz3kLdPv+bErC8FY9YPTGNhheWloUGHyuuVNtSz4aEpq8w3s3vr jim7GDKEZPg1QLwShP9Dif+Ngj/SS1JciIjf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hbEoPuj7oKSDPVFoYnQfGY0N1fwQ7XXnqDV8HDTBQySfWbCsRinbWONlGlNn0ytAkr QlDM5JIeht3cbYjcVzFzK1Zv5MNco2gorCon3bWoqn7TamsxZu8gofia5Q9vy75zdPbm USZFRb8WnVmrPiNGvhPZ4myojWTUSN1KhNdXg= MIME-Version: 1.0 Received: by 10.229.183.142 with SMTP id cg14mr773637qcb.90.1298277738199; Mon, 21 Feb 2011 00:42:18 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Mon, 21 Feb 2011 00:42:18 -0800 (PST) In-Reply-To: References: <201102181928.p1IJSThD006475@fs4113.wdf.sap.corp> Date: Mon, 21 Feb 2011 09:42:18 +0100 X-Google-Sender-Auth: henZLLbbvvVQ809hW_F1vtU7zWg Message-ID: From: Nikos Mavrogiannopoulos To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 08:41:38 -0000 On Mon, Feb 21, 2011 at 1:36 AM, Kyle Hamilton wrote: >> Forcing the TLS implementation to buffer all handshake messages is one >> thing that probably a performance problem in TLSv1.2, but it's not a >> compatibility issue and as someone said fixing it would require releasin= g >> TLSv1.3. However I don't see ANY sensible reasons why TLS would care abo= ut >> which signature algorithm is used for signing the actual certificate. As >> long as the certificate contains the keys necessary to sign the key exch= ange >> it should be fine just like it was before. > Because TLS is the layer where communications policies are negotiated. = =C2=A0The > client is informing the server that (e.g.) it doesn't accept MD5 as a val= id > hash algorithm for realtime communication. =C2=A0If it doesn't accept it = for > realtime communication, there is also no reason to accept it for an offli= ne > proof -- because an attacker has that much more time to find a preimage. Actually TLS negotiates things related to the TLS connection. The whole communication policy is something TLS shouldn't be concerned with. You say that the certificate signature algorithms are important enough to be negotiated with TLS, I would add that not only signature algorithms, but also the key length of the certificate, and even the issuing date of the certificate and the type of the SubjectAlternative name. This is perfec= tly valid under your assumption that TLS should handle this stuff. Fortunately TLS left all the "communication policy" parts that do not concern TLS (i.e. details of certificates), outside its negotiation. The signatureAlgorithms was the first extension to negotiate something that is not relevant for the TLS protocol. > Two reasons why this is inappropriate. =C2=A0First, if the server doesn't= have a > certificate chain the client will accept, it doesn't need to waste the > bandwidth (it doesn't need to broadcast the server's details to someone w= ho > won't accept them anyway). Well, given the way certificates are being used today, that extension canno= t really do much. A server will not request a new certificate from a CA, just because a client added the signatureAlgorithms extension in his clientHello and reque= sted SHA-224. regards, Nikos From n.mavrogiannopoulos@gmail.com Mon Feb 21 01:11:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4313A6F68 for ; Mon, 21 Feb 2011 01:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOpiLEns2tyb for ; Mon, 21 Feb 2011 01:11:15 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id EF6233A6FFD for ; Mon, 21 Feb 2011 01:11:14 -0800 (PST) Received: by qyk29 with SMTP id 29so965160qyk.10 for ; Mon, 21 Feb 2011 01:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ybQe9X/ml6uNihYE7C9pHSHgMZVNZbWy3ZXgteIQLjw=; b=MnEycn43caMnuXW42fBblyNbNJmpJODbsF3TcXF9aR+tDTWXWkzKQgWmR/k35AwAPj l71pjfO79QwkTKYNOvZ3OkqDSR5xOMTQZ3IZ2kyVLtGDrI4nqBiGDJUvfykiAu/4X7JZ k7gIN0LjdOC3N1DoU265zvAfTU8rDwJhwySck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Wi1bJZGThSxpeOsPyXQSErcO8FA1ZuLLexz1Gl0QLwOMevbZoxsB+d2dKxqfUwdL7J VUkg/fkfKenchF3ARRB+4ZqKX8sbgzhSSLEQDncgzU3BbBAyQEc98lkm+qCP5zJTFYci oegvs+zppLSbpSlqdrhS+sHhRY3MhyeBZmStE= MIME-Version: 1.0 Received: by 10.229.218.197 with SMTP id hr5mr795882qcb.14.1298279515754; Mon, 21 Feb 2011 01:11:55 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Mon, 21 Feb 2011 01:11:55 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Mon, 21 Feb 2011 10:11:55 +0100 X-Google-Sender-Auth: 4w3eq0uz-Jn918OWkWFC2DOEFeA Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 09:11:25 -0000 On Sun, Feb 20, 2011 at 2:48 AM, Eric Rescorla wrote: Hello and thank you for the reply. Please don't take my comments as vicious or so, they just reflect my point of view after working on implementation. This might be different but not necessary better. >> This however has the following issues: >> 1. Retransmission timers depend on the time required >> for the peer to do calculations (if an explicit >> ACK is used then the timers only depend on peer's >> packet processing). > I agree that this is true, but I don't think it's really a big deal. > You should be using > initial retransmit times in the area of 200-500 ms, and this is really > a lot faster than > pretty much any computation the other side would be expected to do. And even in > the worst case, if you assume processing time is 0 you just end up > doing a spurious > retransmit. That doesn't seem bad. Indeed. I just didn't like that the retransmission timers are (and cannot be) specified precisely and they are left to the implementor, who is not more qualified to specify them. >> 2. The last message sent by the client expects >> no reply from the server, thus there is not >> an implicit ACK. > You must mean during resumption, since in the full handshake, the last > message from > the client is ACKed by the server's Finished. Regardless, I don't > understand why this > is an issue: both sides maintain retransmission timers and so if you > sent message > A and expect B and you don't get it, you retransmit A. So, in this > case the server > would retransmit his Finished in the expectation that the client would > respond by > resending the client's Finished. Obviously, someone has to speak last and the > other side needs to enforce the receipt of the last message, but > there's nothing unusual > about that. > Can you explain why this isn't adequate? Sorry I meant on server side.. Also in that case I think that the timers should be more precisely specified. For how long should a server wait for a client to resend? If a client has a retransmit timer of 2 seconds, and I wait for only 1, then the protocol negotiation will fail. Since there is not an explicit negotiation of timers, there should be at least some upper or lower limits for the implementers to follow. This makes the protocol look unstable, in the sense that there might be protocol failures depending on the network status. Another issue that might be is, if a ChangeCipherSpec is transmitted as a separate DTLS record. If received out of order there is no way for the DTLS server or client to distinguish whether this is a replay a future, or an old packet (there is no handshake sequence number there). What should such a server do? I expect that ignoring it would be the right answer but maybe the protocol should be explicit. Also the document specifies what to do when invalid records are received. But what if a "lost" handshake message is received during application data exchange? I.E. Client Server ------ ------ Finished --------> [lost] [ChangeCipherSpec] [lost] <-------- Finished Finished --------> [ChangeCipherSpec] <-------- Finished <- Application data exchange -> [replay of lost] [ChangeCipherSpec] [replay of lost] <-------- Finished The ChangeCipherSpec will be rejected by record layer since the epoch will be old, but the finished has the correct epoch, a correct MAC, and a correct sequence number (was not received before). What should an implementation do then? Discard it as a valid but unexpected message? regards, Nikos From ekr@rtfm.com Mon Feb 21 05:21:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F73C3A6F37 for ; Mon, 21 Feb 2011 05:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzhFJBh15ozY for ; Mon, 21 Feb 2011 05:21:47 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 838323A6F5F for ; Mon, 21 Feb 2011 05:21:46 -0800 (PST) Received: by iwl42 with SMTP id 42so3013252iwl.31 for ; Mon, 21 Feb 2011 05:22:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.179.3 with SMTP id bo3mr1967495icb.94.1298294547936; Mon, 21 Feb 2011 05:22:27 -0800 (PST) Received: by 10.43.46.70 with HTTP; Mon, 21 Feb 2011 05:22:27 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Mon, 21 Feb 2011 05:22:27 -0800 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:21:48 -0000 On Mon, Feb 21, 2011 at 1:11 AM, Nikos Mavrogiannopoulos wrote: > On Sun, Feb 20, 2011 at 2:48 AM, Eric Rescorla wrote: > > Hello and thank you for the reply. Please don't take my comments > as vicious or so, they just reflect my point of view after working on > implementation. This might be different but not necessary better. I'm not taking them that way at all. It's really important to get this kind of implementor feedback. Sorry if my response didn't come off like that. >>> This however has the following issues: >>> 1. Retransmission timers depend on the time required >>> for the peer to do calculations (if an explicit >>> ACK is used then the timers only depend on peer's >>> packet processing). >> I agree that this is true, but I don't think it's really a big deal. >> You should be using >> initial retransmit times in the area of 200-500 ms, and this is really >> a lot faster than >> pretty much any computation the other side would be expected to do. And = even in >> the worst case, if you assume processing time is 0 you just end up >> doing a spurious >> retransmit. That doesn't seem bad. > > Indeed. I just didn't like that the retransmission timers are (and > cannot be) specified precisely and they are left to the implementor, > who is not more qualified to specify them. There is some guidance in 4.2.4.1 (1 second doubling up to 60 seconds.). Can you give me an idea of what sort of more detailed guidance you woud like? >>> 2. The last message sent by the client expects >>> no reply from the server, thus there is not >>> an implicit ACK. >> You must mean during resumption, since in the full handshake, the last >> message from >> the client is ACKed by the server's Finished. Regardless, I don't >> understand why this >> is an issue: both sides maintain retransmission timers and so if you >> sent message >> A and expect B and you don't get it, you retransmit A. So, in this >> case the server >> would retransmit his Finished in the expectation that the client would >> respond by >> resending the client's Finished. Obviously, someone has to speak last an= d the >> other side needs to enforce the receipt of the last message, but >> there's nothing unusual >> about that. >> Can you explain why this isn't adequate? > > Sorry I meant on server side.. Also in that case I think that the timers = should > be more precisely specified. For how long should a server wait for a clie= nt > to resend? If a client has a retransmit timer of 2 seconds, and I wait fo= r only > 1, then the protocol negotiation will fail. Since there is not an > explicit negotiation > of timers, there should be at least some upper or lower limits for the > implementers > to follow. Sorry, I'm not following you here: if there is a timer mismatch this just creates a race condition in which case there might be a spurious retransmit. Yes, if = the sides have mismatched total duration timers, then one might kill the connec= tion before the other expects it, but what's wrong with that. > This makes the protocol look unstable, in the sense that there might be p= rotocol > failures depending on the network status. Isn't this always true with any packet protocol, even TCP? > Another issue that might be is, > if a ChangeCipherSpec is transmitted as a separate DTLS record. If receiv= ed > out of order there is no way for the DTLS server or client to distinguish > whether this is a replay a future, or an old packet (there is no handshak= e > sequence number there). Doesn't the epoch make this clear? > Also the document specifies what to do when invalid records are > received. But what > if a "lost" handshake message is received during application data exchang= e? I.E. > > =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0Server > =A0 =A0------ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0------ > =A0 =A0Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--------> > > [lost] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 [ChangeCipherSpec] > [lost] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0 =A0 =A0 = =A0 =A0 =A0 Finished > > =A0 =A0Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--------> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0[ChangeCipherSpec] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-------- =A0 =A0 = =A0 =A0 =A0 =A0 Finished > > <- Application data exchange -> > [replay of lost] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = [ChangeCipherSpec] > [replay of lost] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <-------- =A0 =A0 = =A0 =A0 =A0 =A0 Finished > > The ChangeCipherSpec will be rejected by record > layer since the epoch will be old, but the finished > has the correct epoch, a correct MAC, and a correct > sequence number (was not received before). > > What should an implementation do then? Discard > it as a valid but unexpected message? No, it should trigger a retransmit of the last handshake message that was sent , though the packet itself isn't processed since it's a replay (due to the handshake sequence number). I'll see about making this clear. -Ekr From n.mavrogiannopoulos@gmail.com Mon Feb 21 06:25:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CB53A7089 for ; Mon, 21 Feb 2011 06:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFHOHGc9XsQb for ; Mon, 21 Feb 2011 06:25:29 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 700CC3A6FD5 for ; Mon, 21 Feb 2011 06:25:29 -0800 (PST) Received: by qyk29 with SMTP id 29so1180502qyk.10 for ; Mon, 21 Feb 2011 06:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LXjogQIjYJMfp9VcS+BsDgcX+IjTQolNTj0hZ1MiYOI=; b=o1fOWbZtO+I/IiHV3qcHmWJ8j7CvB0eSO5gAqSGcrD8ntNtUIOgZpHq4Br8lo7KSwy XDDTrwsTS0jeabXfYx7vjxh0izH6kt+X0IsIyaJ0geCxsj3oPpnP1rD0MEX9jgyRdFM3 FWJzdWauwx07ZCgm4HA0LuFPb2Fvr6jmJzt54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xixZxjKEJB4N+YtQQ9f8d+81v+anv0tfsXR9ghSoJ65SNp7b7TmxosZavAkRhmIVY+ PO2jDUz1tDBbHx7kzs1/VJ0qaFQqboCcz0VIChfgLv/NK75T98yCECjflKCIZlv9R1wJ 8EyRf1HZpiF4v+FbIMfDu9uneZvM/JeoplKSQ= MIME-Version: 1.0 Received: by 10.229.220.83 with SMTP id hx19mr1051431qcb.52.1298298370834; Mon, 21 Feb 2011 06:26:10 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.232.18 with HTTP; Mon, 21 Feb 2011 06:26:10 -0800 (PST) In-Reply-To: References: <4D5FF4CD.9070307@gnutls.org> Date: Mon, 21 Feb 2011 15:26:10 +0100 X-Google-Sender-Auth: wuzXwGLOiVSav9260l2lHvysMyg Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 14:25:30 -0000 On Mon, Feb 21, 2011 at 2:22 PM, Eric Rescorla wrote: > There is some guidance in 4.2.4.1 (1 second doubling up to 60 seconds.). > Can you give me an idea of what sort of more detailed guidance you woud > like? How long would the client need to wait for the last flight retransmit (in o= rder to retransmit his finished)? If the application protocol requires the clien= t to start sending application data this is an issue. >> This makes the protocol look unstable, in the sense that there might be = protocol >> failures depending on the network status. > Isn't this always true with any packet protocol, even TCP? >> Another issue that might be is, >> if a ChangeCipherSpec is transmitted as a separate DTLS record. If recei= ved >> out of order there is no way for the DTLS server or client to distinguis= h >> whether this is a replay a future, or an old packet (there is no handsha= ke >> sequence number there). > Doesn't the epoch make this clear? The changecipherspec has the same epoch as the handshake exchange, so if it is received out-of-order during the handshake, the server can not know when it was supposed to be sent. Maybe it should be explicit that replays or out-of-order receival of that message should be discarded.. >> =C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Server >> =C2=A0 =C2=A0------ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0------ >> =C2=A0 =C2=A0Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0--------> >> >> [lost] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec] >> [lost] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Finished >> >> =C2=A0 =C2=A0Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0--------> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Chang= eCipherSpec] >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Finished >> >> <- Application data exchange -> >> [replay of lost] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec] >> [replay of lost] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Finished >> >> The ChangeCipherSpec will be rejected by record >> layer since the epoch will be old, but the finished >> has the correct epoch, a correct MAC, and a correct >> sequence number (was not received before). >> What should an implementation do then? Discard >> it as a valid but unexpected message? > No, it should trigger a retransmit of the last handshake message that was > sent , though the packet itself isn't processed since it's a replay > (due to the handshake sequence number). I'll see about making this > clear. Note that the handshake at that point is over and data have been already exchanged (e.g. I did an HTTP request got a page, and I receive this replay now). regards, Nikos From robert.cragie@gridmerge.com Tue Feb 22 07:29:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84CF3A6914 for ; Tue, 22 Feb 2011 07:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zqIzlhGcxzI for ; Tue, 22 Feb 2011 07:29:46 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 6E60E3A6910 for ; Tue, 22 Feb 2011 07:29:45 -0800 (PST) Received: from client-86-27-30-190.glfd.adsl.virginmedia.com ([86.27.30.190] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1PruC2-0008KV-3j for tls@ietf.org; Tue, 22 Feb 2011 15:30:28 +0000 Message-ID: <4D63D693.7020204@gridmerge.com> Date: Tue, 22 Feb 2011 15:30:27 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090604050707050104000300" X-Authenticated-As: robert.cragie@gridmerge.com Subject: [TLS] Alert processing in RFC 5216 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:29:46 -0000 This is a cryptographically signed message in MIME format. --------------ms090604050707050104000300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I have a question about RFC 5216 (EAP-TLS) regarding the conversation=20 illustrated on page 10 introduced by "In the case where the server=20 authenticates to the peer successfully, but the peer fails to=20 authenticate to the server, the conversation will appear as follows:".=20 Shouldn't the conversation appear as follows, i.e. where the alert is=20 sent from the server instead of the change_cipher_spec and finished from = the server? This is because the server can tell at the point it receives = the client's finished message that authentication has failed. Or am I=20 missing something? Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=3DEAP-TLS (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=3DEAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=3DEAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request EAP-Type=3DEAP-TLS (TLS Alert message) EAP-Response/ EAP-Type=3DEAP-TLS -> <- EAP-Failure (User Disconnected) Regards Robert --------------ms090604050707050104000300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMjIyMTUzMDI3WjAjBgkqhkiG9w0BCQQxFgQU4jG1 IMiiIPqF7OUtE26jKQPMNUgwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAboBGm3ROIOmQRRdhx2qGh654xR/IWVQrW13b 1Akmj785zAI54vsL67rM56/dijJlvDH/W8m0VrLUBQkrTOiRSkEdIagJti/tgJH1uA1BVbqT siXHMLP68eZLFABURB8lIVNYQUUwudUJmqozGyK5VD3StEhoxX8uixvOaqWLcKSSP+BegwYS P3Nuldnh26XK9AO3kUzQGuVqxP0c/n/c2fo99D981+iQFi2CRm4/DLOvr36pGz9NKBeK4Crd WZHdcTrpnE8TZ6+h8gW2ks1Wm903QRQTEyFDrAS3G31Fh6m5ftP1yvxz74fbMXSD85JZMDdJ lRMMrS0yKuoYGC1YrAAAAAAAAA== --------------ms090604050707050104000300-- From iesg-secretary@ietf.org Wed Feb 23 09:29:56 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593EE3A6956; Wed, 23 Feb 2011 09:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtBaYos7udxU; Wed, 23 Feb 2011 09:29:55 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415213A6915; Wed, 23 Feb 2011 09:29:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce , tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110223172955.27054.7913.idtracker@localhost> Date: Wed, 23 Feb 2011 09:29:55 -0800 Subject: [TLS] Last Call: (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 17:29:56 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)' 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 2011-03-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://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ No IPR declarations have been submitted directly on this I-D. From n.mavrogiannopoulos@gmail.com Wed Feb 23 10:00:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC41D3A694A; Wed, 23 Feb 2011 10:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq0STlbzADa6; Wed, 23 Feb 2011 10:00:01 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 59A2F3A693B; Wed, 23 Feb 2011 10:00:01 -0800 (PST) Received: by ewy9 with SMTP id 9so1177442ewy.31 for ; Wed, 23 Feb 2011 10:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Fabv+Doqq+jfz4Nxz9+IJ93rcYwngIy9hD20ebs+EVg=; b=XA4yZb3lz5zVThrjmT7UVSlP6tMugG0DHBWUJu2RXnb4zrueD2YYjvenyipnoBoJmt mT5XlOO/BUo3X+W7zGkQwFnxVEwypg0S8IAsR5nHXAM2Xhcg3c+yZ7T08EDCPFFUCoB9 VJruSv1aheNeQ75A3jsYXy6P6mE4fxJ5k2aFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=EekMRM3j9ewSe27ovJUy3GlN1Nf3NBGcbM0ZJUOUk9+0V5ndHC7VucT9xppZk+0lOc bm3fqyTlgQqd1xf1TeLfa9VoxRkuK3hCLEsCOg1L+fcF3SUxhf/AboGaxsVG5pUFZr+L heB/+j6Jv75R7AiKGUbdmO5veAfIH/ASX+HYQ= Received: by 10.14.119.16 with SMTP id m16mr4476540eeh.8.1298484047906; Wed, 23 Feb 2011 10:00:47 -0800 (PST) Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id x54sm7303066eeh.23.2011.02.23.10.00.46 (version=SSLv3 cipher=OTHER); Wed, 23 Feb 2011 10:00:46 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4D654B4D.8020800@gnutls.org> Date: Wed, 23 Feb 2011 19:00:45 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org References: <20110223172955.27054.7913.idtracker@localhost> In-Reply-To: <20110223172955.27054.7913.idtracker@localhost> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 18:00:03 -0000 On 02/23/2011 06:29 PM, The IESG wrote: > > The IESG has received a request from an individual submitter to > consider the following document: - 'Addition of the Camellia Cipher > Suites to Transport Layer Security (TLS)' > 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 2011-03-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://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ I see that this document defines ciphersuites with a PRF based on SHA384... However it does not specify the verify_data_length, thus the default value of 12 applies, and the SHA384 PRF is being truncated to 96 bits. Is this intentional? If yes, then what is the purpose to use the SHA384 as PRF? regards, Nikos From turners@ieca.com Wed Feb 23 09:34:29 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF38D3A6915 for ; Wed, 23 Feb 2011 09:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5xzmiyoqUhW for ; Wed, 23 Feb 2011 09:34:28 -0800 (PST) Received: from nm11.bullet.mail.ac4.yahoo.com (nm11.bullet.mail.ac4.yahoo.com [98.139.52.208]) by core3.amsl.com (Postfix) with SMTP id 723733A68DC for ; Wed, 23 Feb 2011 09:34:28 -0800 (PST) Received: from [98.139.52.194] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 17:35:11 -0000 Received: from [98.139.52.173] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 17:35:11 -0000 Received: from [127.0.0.1] by omp1056.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 17:35:11 -0000 X-Yahoo-Newman-Id: 726877.5430.bm@omp1056.mail.ac4.yahoo.com Received: (qmail 58053 invoked from network); 23 Feb 2011 17:35:11 -0000 Received: from thunderfish.local (turners@71.191.3.225 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 23 Feb 2011 09:35:11 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: bQXRUwMVM1lYOPiBcf3Dt8lHXrsJTteEFhz8HhFNJ1mNJmh .tQWZqAFIXU_B.jteyUavrxmI0m4i8QWkJF3aPrYKVo1ygFQWRp4PjUUJqR9 75PJ2X211fBmthQCPgOTgwDlJG3J0wx6eDHArt5vzYOjpkXzL5r1j4dhCBA3 dTbSU2lfYJqS6Afrg.N7EOnrtI1TiJwIbPQOBMXUf29HUcpiyQMyLfDgYIvG h7e9X4rHyYnopkIfuoPnzO1X2ZGKeiFHP1gDDLthJmM5z8PmrOcdxApuq5tZ NJ8IyzgyShEe8MTaJCU8jkaJvTXWrijk15I2KsBla6GcgyBpZqWNxD0Y0eI6 9sDDr9r1o_1POCjjdChKzR0MjGAc8_r3FhPLI.911hHmWq6Rv0CDHr3JJMnc HYQt32GiB.x4IYWAJXomrzoM9vqid78g- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D65454E.2010208@ieca.com> Date: Wed, 23 Feb 2011 12:35:10 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bodo Moeller References: <20100723083243.410E2E0638@rfc-editor.org> <540319A8-AD8A-49F9-B022-9308A65E5E40@acm.org> In-Reply-To: <540319A8-AD8A-49F9-B022-9308A65E5E40@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 23 Feb 2011 21:59:53 -0800 Cc: tim.polk@nist.gov, bodo@openssl.org, chris@corriente.net, nelson@bolyard.com, vipul.gupta@sun.com, tls@ietf.org Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (2389) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 17:34:29 -0000 On 7/23/10 5:28 AM, Bodo Moeller wrote: > On Jul 23, 2010, at 10:32 AM, RFC Errata System wrote: > >> >> The following errata report has been submitted for RFC4492, >> "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer >> Security (TLS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=2389 >> >> -------------------------------------- >> Type: Technical >> Reported by: Juho Vähä-Herttua >> >> Section: 5.4 >> >> Original Text >> ------------- >> point: This is the byte string representation of an elliptic curve >> point following the conversion routine in Section 4.3.6 of ANSI >> X9.62 [7]. This byte string may represent an elliptic curve point >> in uncompressed or compressed format; it MUST conform to what the >> client has requested through a Supported Point Formats Extension >> if this extension was used. >> >> enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; >> >> ec_basis_trinomial: Indicates representation of a characteristic-2 >> field using a trinomial basis. >> >> ec_basis_pentanomial: Indicates representation of a >> characteristic-2 field using a pentanomial basis. >> >> Corrected Text >> -------------- >> point: This is the byte string representation of an elliptic curve >> point following the conversion routine in Section 4.3.6 of ANSI >> X9.62 [7]. This byte string may represent an elliptic curve point >> in uncompressed or compressed format; it MUST conform to what the >> client has requested through a Supported Point Formats Extension >> if this extension was used. >> >> enum { >> ec_basis_trinomial(1), ec_basis_pentanomial(2), >> (255) >> } ECBasisType; >> >> ec_basis_trinomial: Indicates representation of a characteristic-2 >> field using a trinomial basis. >> >> ec_basis_pentanomial: Indicates representation of a >> characteristic-2 field using a pentanomial basis. >> >> Notes >> ----- >> The ECBasisType enumeration is submitted as part of the ECParameters >> structure and therefore needs numerical values. It is common to assign >> numerical values starting from 1 to enums and maximum value of 255 >> should be enough, since currently there are only two known basis types >> and it is unlikely to change in the near future. > > Thanks, Juho. Yes, the RFC text is wrong in not assigning enum values > here, and the values that you suggest (1 and 2, with extra value 255 to > clearly state the intended width) are the ones that the specification > would have used. > > Using enum values 0 and 1 would have been equally possible, but this RFC > tends to avoid value 0, except when specifying point compression in > ECPointFormat, where 0 denotes the special "no compression" default. For > ECBasisType, there's no similar special default. > > The implementations I'm aware of so far only provide named curves, i.e. > ECBasisType is never actually encoded on the wire. If anyone knows an > existing implementation supporting explicit characteristic-2 curves, I'd > be glad to hear how it handles this issue -- I'd expect it would be > using the enum values 1 and 2 as suggested here, but in case 0 and 1 are > in actual use somewhere, we'd have to think about maintaining > compatibility. > > Bodo Bodo, Finally getting around to this. The question is whether the enum values are converted to external representation. If they are not then it's okay that they're not there as 4.5 of TLS says: For enumerateds that are never converted to external representation, the numerical information may be omitted. Are they converted? There are two other places where enums aren't given values: enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; and enum { implicit, explicit } PublicValueEncoding; Should these also be changed? spt > > >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4492 (draft-ietf-tls-ecc-12) >> -------------------------------------- >> Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport >> Layer Security (TLS) >> Publication Date : May 2006 >> Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller >> Category : INFORMATIONAL >> Source : Transport Layer Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG > > From turners@ieca.com Wed Feb 23 09:36:11 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF203A6930 for ; Wed, 23 Feb 2011 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THEV8suwjXwD for ; Wed, 23 Feb 2011 09:36:10 -0800 (PST) Received: from nm17.bullet.mail.ac4.yahoo.com (nm17.bullet.mail.ac4.yahoo.com [98.139.52.214]) by core3.amsl.com (Postfix) with SMTP id 102173A68DC for ; Wed, 23 Feb 2011 09:36:09 -0800 (PST) Received: from [98.139.52.193] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 17:36:55 -0000 Received: from [98.139.52.128] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 17:36:54 -0000 Received: from [127.0.0.1] by omp1011.mail.ac4.yahoo.com with NNFMP; 23 Feb 2011 17:36:54 -0000 X-Yahoo-Newman-Id: 973110.93600.bm@omp1011.mail.ac4.yahoo.com Received: (qmail 2415 invoked from network); 23 Feb 2011 17:36:54 -0000 Received: from thunderfish.local (turners@71.191.3.225 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 23 Feb 2011 09:36:54 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 384lqN8VM1l.Ohi7nONO5N1UWNkbxzFBXgDDa0oMwZp7rxq rWVVE1txJ436rHHSkP0qPXIoj6fgtIwNw6Gt8zun7o9GXVxrx_mkfTUCZSz5 Krlw2ZKkUqrsnwFJUaPNNMDE9qdVOA8DeIHoTxGe_oulchjgqifC.IyIY2HQ AZ79mkuDIpMD5.UXirV0W9UGh79Vs3txip13.gpVqHyRzViKu4EpJqDh6FjD HnQYiZldDFTWjJPV_QCAHznVOWK3yKf4Z0tSNABRQPJOQTeahedxj0eYVNfy EZVXolOvYnXkRqEKVv92raFFZsE7JJuj1pAKW66kIpA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6545B6.5080901@ieca.com> Date: Wed, 23 Feb 2011 12:36:54 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <20100723195556.1904FE0698@rfc-editor.org> In-Reply-To: <20100723195556.1904FE0698@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 23 Feb 2011 21:59:53 -0800 Cc: tim.polk@nist.gov, bodo@openssl.org, chris@corriente.net, nelson@bolyard.com, vipul.gupta@sun.com Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (2392) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 17:36:11 -0000 I believe the following is correct and I'm about to hit the verify button unless somebody responds. spt On 7/23/10 3:55 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=2392 > > -------------------------------------- > Type: Editorial > Reported by: Brian Smith > > Section: 5.2 > > Original Text > ------------- > The server's Supported Point Formats Extension has the same structure > as the client's Supported Point Formats Extension (see > Section 5.1.2). Items in elliptic_curve_list here are ordered > according to the server's preference (favorite choice first). Note > that the server may include items that were not found in the client's > list (e.g., the server may prefer to receive points in compressed > format even when a client cannot parse this format: the same client > may nevertheless be capable of outputting points in compressed > format). > > Corrected Text > -------------- > The server's Supported Point Formats Extension has the same structure > as the client's Supported Point Formats Extension (see > Section 5.1.2). Items in ec_point_format_list here are ordered > according to the server's preference (favorite choice first). Note > that the server may include items that were not found in the client's > list (e.g., the server may prefer to receive points in compressed > format even when a client cannot parse this format: the same client > may nevertheless be capable of outputting points in compressed > format). > > Notes > ----- > ec_point_format_list is the field in the Supported Point Formats Extension. elliptic_curve_list is the field in the Supported Elliptic Curves Extension. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4492 (draft-ietf-tls-ecc-12) > -------------------------------------- > Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) > Publication Date : May 2006 > Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > From juhovh@iki.fi Wed Feb 23 11:38:52 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370673A6811 for ; Wed, 23 Feb 2011 11:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9TOJ6ZC+G8z for ; Wed, 23 Feb 2011 11:38:51 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id 0F77F3A67F9 for ; Wed, 23 Feb 2011 11:38:50 -0800 (PST) Received: from vagabond.lan (88.192.41.71) by kirsi2.inet.fi (8.5.133) id 4D621EF000073F5C; Wed, 23 Feb 2011 21:38:56 +0200 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4D65454E.2010208@ieca.com> Date: Wed, 23 Feb 2011 21:37:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AA0DCFD-A70F-429D-B88B-96B649F028EF@iki.fi> References: <20100723083243.410E2E0638@rfc-editor.org> <540319A8-AD8A-49F9-B022-9308A65E5E40@acm.org> <4D65454E.2010208@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Wed, 23 Feb 2011 21:59:53 -0800 Cc: tim.polk@nist.gov, bodo@openssl.org, chris@corriente.net, nelson@bolyard.com, tls@ietf.org, vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (2389) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 19:38:52 -0000 On Feb 23, 2011, at 7:35 PM, Sean Turner wrote: >> Thanks, Juho. Yes, the RFC text is wrong in not assigning enum values >> here, and the values that you suggest (1 and 2, with extra value 255 = to >> clearly state the intended width) are the ones that the specification >> would have used. >>=20 >> Using enum values 0 and 1 would have been equally possible, but this = RFC >> tends to avoid value 0, except when specifying point compression in >> ECPointFormat, where 0 denotes the special "no compression" default. = For >> ECBasisType, there's no similar special default. >>=20 >> The implementations I'm aware of so far only provide named curves, = i.e. >> ECBasisType is never actually encoded on the wire. If anyone knows an >> existing implementation supporting explicit characteristic-2 curves, = I'd >> be glad to hear how it handles this issue -- I'd expect it would be >> using the enum values 1 and 2 as suggested here, but in case 0 and 1 = are >> in actual use somewhere, we'd have to think about maintaining >> compatibility. >>=20 >> Bodo >=20 > Bodo, >=20 > Finally getting around to this. The question is whether the enum = values are converted to external representation. If they are not then = it's okay that they're not there as 4.5 of TLS says: >=20 > For enumerateds that are never converted to external representation, > the numerical information may be omitted. >=20 > Are they converted? >=20 > There are two other places where enums aren't given values: >=20 > enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; >=20 > and >=20 > enum { implicit, explicit } PublicValueEncoding; >=20 > Should these also be changed? The first "other place" is actually exactly the enum which was = originally reported. The ECBasisType indeed is converted to external = representation as can be seen in RFC 4492 section 5.4. struct = ECParameters below the case explicit_char2. PublicValueEncoding instead = is gotten from ClientCertificateType message and doesn't have external = representation. As said in RFC 4492 section 5.7: (This is "explicit" in ECC cipher suites except when the client uses = the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.) The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm) that = aren't given values depend on cipher suite and don't need external = representation. However, without the external representation of = ECBasisType it is impossible for the parser to know if it should only = parse "k" or "k1, k2 and k3" from the struct and it will fail, hence the = errata. Hope this helps, and feel free to correct me if necessary. I wasn't sure = who the question was asked since the email was addressed to Bodo, but = thought to clarify anyway. Juho From SRS0=ynfY=VV=acm.org=bmoeller@srs.kundenserver.de Thu Feb 24 03:19:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79F13A6834 for ; Thu, 24 Feb 2011 03:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.326 X-Spam-Level: X-Spam-Status: No, score=-101.326 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Cbjj1MFguFn for ; Thu, 24 Feb 2011 03:19:53 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id A87523A6A7B for ; Thu, 24 Feb 2011 03:19:52 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MbLNo-1PZvw5125E-00Imhs; Thu, 24 Feb 2011 12:20:41 +0100 Received: by vxg33 with SMTP id 33so289232vxg.31 for ; Thu, 24 Feb 2011 03:20:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.167.166 with SMTP id zp6mr1191504vdb.50.1298546440190; Thu, 24 Feb 2011 03:20:40 -0800 (PST) Received: by 10.220.192.13 with HTTP; Thu, 24 Feb 2011 03:20:40 -0800 (PST) In-Reply-To: <8AA0DCFD-A70F-429D-B88B-96B649F028EF@iki.fi> References: <20100723083243.410E2E0638@rfc-editor.org> <540319A8-AD8A-49F9-B022-9308A65E5E40@acm.org> <4D65454E.2010208@ieca.com> <8AA0DCFD-A70F-429D-B88B-96B649F028EF@iki.fi> Date: Thu, 24 Feb 2011 12:20:40 +0100 Message-ID: From: Bodo Moeller To: =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= Content-Type: multipart/alternative; boundary=bcaec53f8eaf4ac940049d0567a3 X-Provags-ID: V02:K0:GCCLa4YLF3fapTuL0zhLyWByp5wczsQXGHKjO8yGhzb GRmpXLLA6f6RWTJYGAOy6uokB8bYlL5PM6QBxkFefb1d0E/VAV /XMJHvHSbFKYHqgvxabZYg34TStoIuttVhnDatF2roh7BtEZ0A nFbYf1PHxx9bCcXg8dWEdl2SB9G1nU0aIS2i/uPaMBzu1XC4Dn xwk4aKdmP4koxAf4qFaRH3mmDbfoZfXCC4FzX6E+6o= X-Mailman-Approved-At: Fri, 25 Feb 2011 11:30:04 -0800 Cc: tim.polk@nist.gov, chris@corriente.net, nelson@bolyard.com, tls@ietf.org, vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (2389) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 11:21:33 -0000 --bcaec53f8eaf4ac940049d0567a3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 23, 2011 at 8:37 PM, Juho V=E4h=E4-Herttua wrot= e: > >> Thanks, Juho. Yes, the RFC text is wrong in not assigning enum values > >> here, and the values that you suggest (1 and 2, with extra value 255 t= o > >> clearly state the intended width) are the ones that the specification > >> would have used. > > > There are two other places where enums aren't given values: > > > > enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; > > > > and > > > > enum { implicit, explicit } PublicValueEncoding; > > > > Should these also be changed? > The first "other place" is actually exactly the enum which was originally > reported. The ECBasisType indeed is converted to external representation = as > can be seen in RFC 4492 section 5.4. struct ECParameters below the case > explicit_char2. PublicValueEncoding instead is gotten from > ClientCertificateType message and doesn't have external representation. A= s > said in RFC 4492 section 5.7: > > (This is "explicit" in ECC cipher suites except when the client uses the > ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.) > > The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm) that > aren't given values depend on cipher suite and don't need external > representation. However, without the external representation of ECBasisTy= pe > it is impossible for the parser to know if it should only parse "k" or "k= 1, > k2 and k3" from the struct and it will fail, hence the errata. > > Hope this helps, and feel free to correct me if necessary. I wasn't sure > who the question was asked since the email was addressed to Bodo, but > thought to clarify anyway. > Yes, thanks. Just to avoid any confusion, let me clarify the context of my previous statement that "ECBasisType is never actually encoded on the wire": this wa= s referring to my knowledge about *existing implementations*; it's clear from the specification that you need to encode ECBasisType on the wire if you support explicitly specified characteristic-2 curves for ECDHE ciphersuites= . Bodo --bcaec53f8eaf4ac940049d0567a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 23, 2011 at 8:37 PM, Juho V=E4h=E4-Herttua &l= t;juhovh@iki.fi> wrote:
<= div class=3D"gmail_quote">
=A0
>> Thanks, Juho. Yes, the RFC text is wrong in not assigning enum val= ues
>> here, and the values that you suggest (1 and 2, with extra value 2= 55 to
>> clearly state the intended width) are the ones that the specificat= ion
>> would have used.

=
> There are two other places where enums aren't given values:
>
> =A0enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
>
> and
>
> =A0enum { implicit, explicit } PublicValueEncoding;
>
> Should these also be changed?
=A0
=
The first "other place" is actually exactly the enum = which was originally reported. The ECBasisType indeed is converted to exter= nal representation as can be seen in RFC 4492 section 5.4. struct ECParamet= ers below the case explicit_char2. PublicValueEncoding instead is gotten fr= om ClientCertificateType message and doesn't have external representati= on. As said in RFC 4492 section 5.7:

(This is "explicit" =A0in ECC cipher suites except when the clien= t uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechani= sm.)

The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm) that aren= 't given values depend on cipher suite and don't need external repr= esentation. However, without the external representation of ECBasisType it = is impossible for the parser to know if it should only parse "k" = or "k1, k2 and k3" from the struct and it will fail, hence the er= rata.

Hope this helps, and feel free to correct me if necessary. I wasn't sur= e who the question was asked since the email was addressed to Bodo, but tho= ught to clarify anyway.

Yes, thanks.

Just t= o avoid any confusion, let me clarify the context of my previous statement = that "ECBasisType is never actually encoded on the wire": this wa= s referring to my knowledge about *existing implementations*; it's clea= r from the specification that you need to encode ECBasisType on the wire if= you support explicitly specified characteristic-2 curves for ECDHE ciphers= uites.

Bodo

--bcaec53f8eaf4ac940049d0567a3-- From bodomoeller@gmail.com Thu Feb 24 03:51:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C483A6AA8 for ; Thu, 24 Feb 2011 03:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxnwEkZQ8Ray for ; Thu, 24 Feb 2011 03:51:31 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 931F03A6AA3 for ; Thu, 24 Feb 2011 03:51:31 -0800 (PST) Received: by vxg33 with SMTP id 33so309993vxg.31 for ; Thu, 24 Feb 2011 03:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=URN8dLRy6WxGPtCTQuKHIXmtS6Ph6aHmgOB3HN9Mad4=; b=rc1mhPfEwX5ZDQwZot10ACKjMVWoHkcZqwQNByqwY5KBCNQ/pVVgwfi3kuJAf6B91S jYsaGM9ppitYvkLHl1CCseogt9+xa/4N/zT6cca5zM5WKYUT7yhU5aKA50us5VVWRSan SzXoZkc75TopPcxzpAKgef+yIgZPrKdB4mYkA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZINfUVNPT/QsKMXVXft8DG6mjyiavU1Zgp5gwUudEkkGnhuR9U5DXrUNigzL2yyhHF XfcLVcN0P7Nb6VuHfDJ4ygpS8JcdZNmWJD6AsPKk7SB8v5Q9ou8LU/7aTxdYMv/VNdsz /jPqmCc6195QJMh2Cz6znwexGKNMHqk2/GO48= MIME-Version: 1.0 Received: by 10.52.165.164 with SMTP id yz4mr1311278vdb.90.1298548340531; Thu, 24 Feb 2011 03:52:20 -0800 (PST) Sender: bodomoeller@gmail.com Received: by 10.220.192.13 with HTTP; Thu, 24 Feb 2011 03:52:20 -0800 (PST) In-Reply-To: <4D6545B6.5080901@ieca.com> References: <20100723195556.1904FE0698@rfc-editor.org> <4D6545B6.5080901@ieca.com> Date: Thu, 24 Feb 2011 12:52:20 +0100 X-Google-Sender-Auth: xCKZzuGK0syAQ-sw7dV683Xh-OE Message-ID: From: Bodo Moeller To: Sean Turner Content-Type: multipart/alternative; boundary=bcaec53f398f8fa398049d05d8b7 X-Mailman-Approved-At: Fri, 25 Feb 2011 11:30:05 -0800 Cc: tim.polk@nist.gov, chris@corriente.net, nelson@bolyard.com, tls@ietf.org, vipul.gupta@sun.com Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (2392) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 12:28:21 -0000 --bcaec53f398f8fa398049d05d8b7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 23, 2011 at 6:36 PM, Sean Turner wrote: > I believe the following is correct and I'm about to hit the verify button > unless somebody responds. > Yes, this is correct (replace "elliptic_curve_list" by "ec_point_format_list" in the description of the server's Supported Point Formats Extension). Bodo --bcaec53f398f8fa398049d05d8b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 23, 2011 at 6:36 PM, Sean Turner <turners@ieca.com> wrote:
I believe the following is correct and I'm about to hit the verify butt= on unless somebody responds.

Yes, this is correct = (replace "elliptic_curve_list" by "ec_point_format_list"= ; in the description of the server's Supported Point Formats Extension)= .

Bodo


--bcaec53f398f8fa398049d05d8b7-- From kanno.satoru@po.ntts.co.jp Sun Feb 27 22:36:05 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D160E3A6AB3; Sun, 27 Feb 2011 22:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO4MOE09TqRy; Sun, 27 Feb 2011 22:36:05 -0800 (PST) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by core3.amsl.com (Postfix) with ESMTP id A83143A6A96; Sun, 27 Feb 2011 22:36:04 -0800 (PST) Received: from sadoku33.silk.ntts.co.jp (sadoku33 [10.7.18.33]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id p1S6aNkk000760; Mon, 28 Feb 2011 15:36:23 +0900 (JST) Received: (from root@localhost) by sadoku33.silk.ntts.co.jp (8.13.8/NTTSOFT) id p1S6aNC3020307; Mon, 28 Feb 2011 15:36:23 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku33.silk.ntts.co.jp with SMTP id RAA20306; Mon, 28 Feb 2011 15:36:23 +0900 Received: from mail137.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id p1S6aM0M028057; Mon, 28 Feb 2011 15:36:22 +0900 Received: from mail137.silk.ntts.co.jp (localhost [127.0.0.1]) by mail137.silk.ntts.co.jp (8.14.4/NTTSOFT) with ESMTP id p1S6aM3A027672; Mon, 28 Feb 2011 15:36:22 +0900 (JST) Received: from ccmds32 (ccmds32.silk.ntts.co.jp [10.107.0.32]) by mail137.silk.ntts.co.jp (8.14.4/NTTSOFT) with SMTP id p1S6aMxe027669; Mon, 28 Feb 2011 15:36:22 +0900 (JST) Message-ID: <4D6B423D.1010402@po.ntts.co.jp> Date: Mon, 28 Feb 2011 15:35:41 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <20110223172955.27054.7913.idtracker@localhost> <4D654B4D.8020800@gnutls.org> In-Reply-To: <4D654B4D.8020800@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 06:36:06 -0000 (2011/02/24 3:00), Nikos Mavrogiannopoulos wrote: > On 02/23/2011 06:29 PM, The IESG wrote: >> >> The IESG has received a request from an individual submitter to >> consider the following document: - 'Addition of the Camellia Cipher >> Suites to Transport Layer Security (TLS)' >> 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 2011-03-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://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ > > I see that this document defines ciphersuites with a PRF based on > SHA384... However it does not specify the verify_data_length, thus > the default value of 12 applies, and the SHA384 PRF is being truncated > to 96 bits. Is this intentional? If yes, then what is the purpose to > use the SHA384 as PRF? > Hi Nikos, Thank you for your comment. I think that the verify_data_length with a PRF based on SHA384 is specified in RFC5246. As a result, I refer to RFC5246 as well as other documents( e.g., RFC5289, RFC5487, and draft-nsri-tls-aria etc.,) in our document. I think that your comment is not only our draft but all documents specifying the PRF base on SHA384 for TLS. What do you think? Regards, Satoru > regards, > Nikos > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno.satoru@po.ntts.co.jp From n.mavrogiannopoulos@gmail.com Mon Feb 28 00:44:19 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6B63A6AE1; Mon, 28 Feb 2011 00:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quNVPkKBLtTV; Mon, 28 Feb 2011 00:44:18 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 9660F3A6ADE; Mon, 28 Feb 2011 00:44:18 -0800 (PST) Received: by qyk7 with SMTP id 7so2818200qyk.10 for ; Mon, 28 Feb 2011 00:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UymXaXJnuCC627tlVYXTVhz3lxQeur095B1ozZsU4bg=; b=B7NLYoWtFZmYX4IE1+vbGMD6haaWoO5TrTkHAFlSFg6cn5mSXiNKKTea7GrLANWXEj Izu/IigAaXWB7GnHDaGmEfccjNRw3SeqOux3zBtwX8xU8BqQDQjix0aITo5/k1qvdofV 6dcW10tY/9eyqOJeNFWPjTAr31/O6qIQwjjHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=EFcPw+k0vgzTcaGDHTNBmVx2z8ha1pp2Ps5suOjE1I0WlD0NzqjPAqOrwIZ4eUxuI+ 3uagM4LA4iDglCZDtt2Fz3FQ+eZrXg662gQUwYeaXIXh2l65VcIni7dL3xhQOmtd4PdT 4KF6C99x+R4UxUiWY7jU8FTnEb2VPm0Qf6/TI= MIME-Version: 1.0 Received: by 10.229.192.149 with SMTP id dq21mr4003295qcb.57.1298882717179; Mon, 28 Feb 2011 00:45:17 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.20.71 with HTTP; Mon, 28 Feb 2011 00:45:17 -0800 (PST) In-Reply-To: <4D6B423D.1010402@po.ntts.co.jp> References: <20110223172955.27054.7913.idtracker@localhost> <4D654B4D.8020800@gnutls.org> <4D6B423D.1010402@po.ntts.co.jp> Date: Mon, 28 Feb 2011 09:45:17 +0100 X-Google-Sender-Auth: D_Tw3CaUBrjRgfMaDfjpEitKzHA Message-ID: From: Nikos Mavrogiannopoulos To: Satoru Kanno Content-Type: text/plain; charset=UTF-8 Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 08:44:19 -0000 On Mon, Feb 28, 2011 at 7:35 AM, Satoru Kanno wrote: >> I see that this document defines ciphersuites with a PRF based on >> SHA384... However it does not specify the verify_data_length, thus >> the default value of 12 applies, and the SHA384 PRF is being truncated >> to 96 bits. Is this intentional? If yes, then what is the purpose to >> use the SHA384 as PRF? > Hi Nikos, > Thank you for your comment. > I think that the verify_data_length with a PRF based on > SHA384 is specified in RFC5246. > As a result, I refer to RFC5246 as well as other documents( e.g., RFC5289, > RFC5487, and draft-nsri-tls-aria etc.,) in our document. > I think that your comment is not only our draft but all documents specifying > the PRF base on SHA384 for TLS. Yours was the first document I noticed to use SHA384 as PRF. If there are other documents that specify that, and don't set the verify_data_length size then it applies to those as well. (just noticed that applies to RFC5288 as well). regards, Nikos From jsalowey@cisco.com Mon Feb 28 09:34:26 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8F13A6C06 for ; Mon, 28 Feb 2011 09:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ6KXoozbOIT for ; Mon, 28 Feb 2011 09:34:26 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 017E13A6A1D for ; Mon, 28 Feb 2011 09:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=199; q=dns/txt; s=iport; t=1298914527; x=1300124127; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=hLrNqfvwo8RIpsS/89B0mLLn/IsWeVbpj0yGBnCxm6c=; b=NtrE/TH0OFCtU45hmkZRSJayVhvKjThTALCidFQOobvgl1AVpJX/Ok7x Os2ntdU5acpFBXtAnKm8bcGUwHu0ZOekYXFunAeg07RBtgrj9mE7vvx+c qxhlBgzqE5DGL1AOeylGonLXmEsSO6t7JCrkKLKib7CJF+VT56zRegIPI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHAM9ra02rR7H+/2dsb2JhbACYMo4VdKB1mzuFYQSFD4cNgz4 X-IronPort-AV: E=Sophos;i="4.62,241,1297036800"; d="scan'208";a="271835613" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2011 17:35:27 +0000 Received: from [10.33.251.197] ([10.33.251.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SHZQ7v016930 for ; Mon, 28 Feb 2011 17:35:26 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2011 09:36:45 -0800 Message-Id: <960EFA43-C978-4CFD-A9ED-5EB8294D6DD8@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [TLS] Agenda Items for IETF 80 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:34:27 -0000 Please sends the chairs any requests for agenda Items you have for the = TLS meeting in Prague. The TLS meeting is currently scheduled for = Wednesday Afternoon 2 session. =20 Thanks, Joe=