Re: [TLS] Chatter on consensus

Martin Rex <mrex@sap.com> Thu, 28 January 2010 00:54 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 0DCF13A6768 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 16:54:25 -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=[AWL=0.000, 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 vj50pD+fV-Md for <tls@core3.amsl.com>; Wed, 27 Jan 2010 16:54:24 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 009B13A6877 for <tls@ietf.org>; Wed, 27 Jan 2010 16:54:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0S0sbRf004722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 01:54:37 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001280054.o0S0sbjo022469@fs4113.wdf.sap.corp>
To: DPKemp@missi.ncsc.mil
Date: Thu, 28 Jan 2010 01:54:37 +0100
In-Reply-To: <201001272306.o0RN6xOx027395@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 27, 10 06:06:58 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Chatter on consensus
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 00:54:25 -0000

Kemp, David P. wrote:
> 
> For secure renegotiation, if you eliminate the MUST NOT in section 3.5,
> then you must add a configuration somewhere (either hard coded or as a
> configuration option) that determines how the software will behave.

I'm sorry, I completely lost you.

Removing that MUST NOT simplifies the architecture, the protocol
and the implementations.  Guaranteed.  You will find out when
you implement this.

Discussing this at the theory level is much more difficult,
and likely the reason why there is so much discussion and
disagreement.

I know that pretty well.  I completely foobared the implementation
guidance in the initial version (-00) of my draft, because I hadn't
sufficiently thought about implementing it.

It is possible to do it at the theoretical level, though.
That's what I did with the -03 document when I implemented
it exactly according to my own spec in OpenSSL-0.9.8l.


>
> For insecure renegotiation, backwards interop scenarios can be supported
> non-disruptively in 3 different ways in accordance with -03, but they
> can also be supported non-disruptively in a 4th way, by following the
> RFCs for TLSv1.0-v1.2 and ignoring -03.
 
I'm sorry, I can not follow.

Insecure renegotiation is what happens, if you do not abort renegotiation
in the consistent absence of secure renegotiation.

I do not understand what you are refering to with "in three different ways".

There are a number of constraints that need to be checked, and it
is up to the implementer whether he implements each check individually
with its own error handling and own error number, or wether he
combines certain conditionals, error handling and error codes.

The MUST NOTs and the NOT RECOMMENDEDs I'm objecting to are
completely invisible at both, the API level and in the policy configuration
that determines which kind of interoperability should be allowed.


-Martin