Re: [TLS] Updated draft

"Robert Dugal" <rdugal@certicom.com> Fri, 18 December 2009 12:11 UTC

Return-Path: <rdugal@certicom.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC333A6A18 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 04:11:31 -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=[AWL=0.000, 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 vyr3KElmXe6i for <tls@core3.amsl.com>; Fri, 18 Dec 2009 04:11:30 -0800 (PST)
Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 39F9B3A67E3 for <tls@ietf.org>; Fri, 18 Dec 2009 04:11:29 -0800 (PST)
X-AuditID: 0a666446-b7ba5ae000003caa-6e-4b2b716114d2
Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 66.7E.15530.1617B2B4; Fri, 18 Dec 2009 07:11:14 -0500 (EST)
Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 07:11:13 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
Date: Fri, 18 Dec 2009 07:10:29 -0500
Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net>
In-Reply-To: <4B2A73C7.7030505@pobox.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Updated draft
Thread-Index: Acp/Q9x5TdGgr/rmRe+ruOj96MCGpwAlVOoQ
References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com>
From: Robert Dugal <rdugal@certicom.com>
To: TLS Mailing List <tls@ietf.org>
X-OriginalArrivalTime: 18 Dec 2009 12:11:13.0558 (UTC) FILETIME=[31532B60:01CA7FDB]
X-Brightmail-Tracker: AAAABAAAAZESGurlEhrsOBIa7Dk=
Subject: Re: [TLS] Updated draft
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2009 12:11:32 -0000

I would also like to see that change in the draft. 

To increase interoperability with existing servers I would like the option to send SCSV 
in the initial ClientHello and only send the TLS extension in renegotiation handshakes.
This will make it easier for applications as they won't have to make a decision as to 
whether the server is TLS extension intolerant.

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
rdugal@certicom.com
direct        905.501.3848
fax             905.507.4230
www.certicom.com


-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Michael D'Errico
Sent: Thursday, December 17, 2009 1:09 PM
To: TLS Mailing List
Subject: Re: [TLS] Updated draft

s/signalling/signaling/g

In section 4 it says:

    Because the SCSV is equivalent to an empty "renegotiation_info"
    extension, any ClientHello used for secure renegotiation MUST include
    the "renegotiation_info" extension and not the SCSV.

I would rather see the text say that "an RI extension takes precedence
over the SCSV" than to say that you must not send SCSV when you send RI.
It is easier for a client to simply include SCSV in every ClientHello.
It is also trivial for a server to handle this, as I pointed out in my
last message.

Mike



Eric Rescorla wrote:
> I've just submitted a new draft that is intended to enact most of
> Pasi's message as well as the noncontroversial editorial comments
> people have raised. Here is what I know still needs work:
> 
> - The final resolution to what's sent in the legacy renegotiation
>   case (see Pasi's message and the text I sent earlier).
> - New text for the identity section in Security considerations.
>   (Pending closure on the list).
> - Make a pass through for clarity for implementors. 
>   (Also, I have some text here that Pasi contributed that I
>   need to work in).
> 
> If you think you made a comment which is noncontroversial
> that didn't make it in and/or I screwed up incorporating your
> comment, please let me know and I'll try to fix.
> 
> For some reason, the submission tool is forcing manual 
> submission. In the interim you can find it at:
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt
> 
> Thanks,
> -Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.