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

Martin Rex <mrex@sap.com> Thu, 28 January 2010 18:50 UTC

Return-Path: <mrex@sap.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 587F03A695B for <tls@core3.amsl.com>; Thu, 28 Jan 2010 10:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 vKahqSvyjHRH for <tls@core3.amsl.com>; Thu, 28 Jan 2010 10:50:15 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 147503A67F2 for <tls@ietf.org>; Thu, 28 Jan 2010 10:50:14 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0SIoWVB026056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 19:50:32 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001281850.o0SIoVl4000492@fs4113.wdf.sap.corp>
To: Pasi.Eronen@nokia.com
Date: Thu, 28 Jan 2010 19:50:31 +0100 (MET)
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758412272FD@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Jan 28, 10 06:07:26 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
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
Reply-To: mrex@sap.com
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 18:50:16 -0000

Pasi.Eronen@nokia.com wrote:
> 
> 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.


If "MUST send either empty TLS extension or SCSV" would "clearly"
mean a mathematical X-OR, then this should have been changed in -03.

-03 clarifies that it does _NOT_ imply X-OR, but Inclusive OR.

As you can see in the WG discussion, some implementors did _NOT_
read this to mean X-OR, and some asked for spelling out that it
means Inclusive OR.


The document quality, and in particular the inconsistencies in
the document were just to numerous to make any assessments which
specific semantics someone may have "confirmed" by humming for
the -01 document in the Last Call.


If anything, the explicit MUSTs are a much more reliable indicator
of what is meant, and that says that a server must accept both
signals in a client hello.  The rest is just inconsistent wording.


The use of the label TLS_RENEGO_PROTECTION_REQUEST is also a strong
indicator that Eric's attempt at defining what this represents
is not necessarily final or completely accurate.


And from the message that *I* am getting here, the explicit MUSTs,
that require to accept SCSV Inclusive-OR on every ClientHello
is considered a "substantial" characteristic, where a changes
requires consensus, while an initial attempt to describe the
characteristics is an editorial issue and could be changed
mostly at discretion of the author.


-Martin