Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

<Pasi.Eronen@nokia.com> Thu, 28 January 2010 17:07 UTC

Return-Path: <Pasi.Eronen@nokia.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 8C4773A6AA5 for <tls@core3.amsl.com>; Thu, 28 Jan 2010 09:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level:
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[AWL=0.299, 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 tkvv+78JzEDv for <tls@core3.amsl.com>; Thu, 28 Jan 2010 09:07:29 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 67B343A6AA3 for <tls@ietf.org>; Thu, 28 Jan 2010 09:07:29 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SH7Q53017669; Thu, 28 Jan 2010 19:07:45 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 19:07:27 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 19:07:27 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 28 Jan 2010 18:07:27 +0100
From: <Pasi.Eronen@nokia.com>
To: <mrex@sap.com>
Date: Thu, 28 Jan 2010 18:07:26 +0100
Thread-Topic: Metadiscussion on changes in draft-ietf-tls-renegotiation
Thread-Index: AcqgJ3oOucVUVi77QP28Y+4ZYmc8fgADvY+w
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758412272FD@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758411DE69C@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Jan 28, 10 11:22:54 am <201001281437.o0SEbOG9014103@fs4113.wdf.sap.corp>
In-Reply-To: <201001281437.o0SEbOG9014103@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
X-OriginalArrivalTime: 28 Jan 2010 17:07:27.0985 (UTC) FILETIME=[5EA53E10:01CAA03C]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
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: Thu, 28 Jan 2010 17:07:30 -0000

Martin Rex wrote:

> > "Now"? "Addition"?
> >
> > I would like to remind you that version -01 of the document also
> > very clearly prohibited sending the SCSV in secure renegotiation
> > ClientHello, and also used upper-case RFC 2119 keywords in that text.
> 
> It could be that we are refering to different versions of -01, the
> one on tools.ietf.org doesn't have a MUST NOT send, and in
> particular, it does not have a MUST abort when received.
>
> If you think that there an implied MUST NOT in there -- I can see
> explicit MUSTs to the contrary in -01 and more so in -02!

There are different styles of writing specification text; some people
prefer to use upper-case RFC 2119 keywords as much as possible; others
prefer normal English.

The TLS main specification (RFC 5246) is clearly in the latter camp,
and mostly avoids using RFC 2119 key words. For example, when
describing the processing of received ClientHello, the text just says:

   "The server will select a cipher suite or, if no acceptable choices
   are presented, return a handshake failure alert and close the
   connection."

For an implementor, this means the same thing as "MUST select a cipher
suite from the list sent by the client or, [...] , MUST return a handshake
failure...". The lack of RFC 2119 keywords doesn't mean that a
compliant server could, e.g., use a cipher suite that was not proposed
by the client, or do something else completely.

The relevant text from -01 version was quoted in my email on January
26, and I'm not going to repeat it here.  The text does not in any way
contradict the "MUST generate either [..]  or [..] in every
ClientHello" in Section 5; text elsewhere in the document explains
when the different cases apply. For example, that sentence taken alone
would allow sending just the SCSV (without RI) in secure renegotiation; 
something that's clearly forbidden elsewhere in the document.

Best regards,
Pasi