IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

Martin Rex <mrex@sap.com> Wed, 02 December 2009 02: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 A7ADA3A6813; Tue, 1 Dec 2009 18:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.191
X-Spam-Level:
X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cBLf3ceFmlLp; Tue, 1 Dec 2009 18:50:10 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 45F5D3A679F; Tue, 1 Dec 2009 18:50:10 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB22nxnH014788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 03:49:59 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912020249.nB22nvQ0007879@fs4113.wdf.sap.corp>
To: stephen.farrell@cs.tcd.ie
Date: Wed, 02 Dec 2009 03:49:57 +0100
In-Reply-To: <4B14FFC0.3040404@cs.tcd.ie> from "Stephen Farrell" at Dec 1, 9 11:36:32 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer
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: Wed, 02 Dec 2009 02:50:11 -0000

Stephen Farrell wrote:
> 
> 7. 6.2 says: "If servers wish to <<avoid attack>> they MUST
> NOT <<do stuff>>" Isn't that equivalent to servers SHOULD
> NOT? I think a SHOULD NOT is better. (And that's the form
> used in section 7.)


This might be confusion with ISO terminology.

   MUST       ==  SHALL
   MUST NOT   ==  SHALL NOT
   SHOULD     ==  RECOMMENDED
   SHOULD NOT ==  NOT RECOMMENDED


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


And btw. the document that standardizes the secure renegotiation
will have to say that it updates RFC-5246, because it needs to.


-Martin

v2.23.0 | Report a Bug | By Email