Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt

Rob Dugal <RDugal@certicom.com> Wed, 05 July 2006 11:33 UTC

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 <bmoeller@acm.org>
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: <OFA7588972.5C871003-ON852571A2.003DCFD0-852571A2.003F946E@certicom.com>
From: Rob Dugal <RDugal@certicom.com>
Date: Wed, 05 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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0309096121=="
Errors-To: tls-bounces@lists.ietf.org

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
_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls