Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5d4-0008FI-7e; Wed, 05 Jul 2006 07:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5d2-0008Cy-Sp for tls@ietf.org; Wed, 05 Jul 2006 07:33:12 -0400 Received: from [66.48.18.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5d0-00039E-I8 for tls@ietf.org; Wed, 05 Jul 2006 07:33:12 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 34A8B10027FF3; Wed, 5 Jul 2006 07:32:53 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18611-78; Wed, 5 Jul 2006 07:32:51 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 50A2410027FF1; Wed, 5 Jul 2006 07:32:51 -0400 (EDT) In-Reply-To: <20060704094106.GA22002@iota.site> To: Bodo Moeller Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Wed, 5 Jul 2006 07:32:09 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/05/2006 07:32:19 AM, Serialize complete at 07/05/2006 07:32:19 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0309096121==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0309096121== Content-Type: multipart/alternative; boundary="=_alternative 003F9468852571A2_=" This is a multipart message in MIME format. --=_alternative 003F9468852571A2_= Content-Type: text/plain; charset="US-ASCII" Bodo Moeller wrote on 07/04/2006 05:41:06 AM: > On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote: > > > A quick and totally unscientific survey of what some widely used > > SSL/TLS implementations do: > > > > - OpenSSL (0.9.8) > > - When configured in "both SSLv3 and TLSv10 allowed" mode, > > sends V2 ClientHello. > > This is the behavior of OpenSSL versions up to 0.9.7g. Versions > 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 > format Client Hello message with version number {03,01} in both > fields. The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour would be to encode the minimum protocol {03,00} in the record's protocol field and the highest protocol {03,01} in the client_hello message's protocol field. A server that understands only SSLv3 could reject a client hello message that uses a record protocol of TLSv1. To negotiate with an SSLv2 server the client must send an SSLv2 client hello so why would the situation be any different for SSLv3/TLSv1? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com --=_alternative 003F9468852571A2_= Content-Type: text/html; charset="US-ASCII"
Bodo Moeller <bmoeller@acm.org> wrote on 07/04/2006 05:41:06 AM:

> On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote:
>
> > A quick and totally unscientific survey of what some widely used
> > SSL/TLS implementations do:
> >
> > - OpenSSL (0.9.8)
> >   - When configured in "both SSLv3 and TLSv10 allowed" mode,
> >     sends V2 ClientHello.
>
> This is the behavior of OpenSSL versions up to 0.9.7g.  Versions
> 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3
> format Client Hello message with version number {03,01} in both
> fields.  

The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour would be to encode the minimum protocol {03,00} in the record's protocol field and the highest protocol {03,01} in the client_hello message's protocol field. A server that understands only SSLv3 could reject a client hello message that uses a record protocol of TLSv1. To negotiate with an SSLv2 server the client must send an SSLv2 client hello so why would the situation be any different for SSLv3/TLSv1?






-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com
--=_alternative 003F9468852571A2_=-- --===============0309096121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0309096121==--