Re: [TLS] Confirming consensus about one

Martin Rex <mrex@sap.com> Wed, 27 January 2010 17:18 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 2DFEC3A6816; Wed, 27 Jan 2010 09:18:01 -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 gMhFNGxu6WIB; Wed, 27 Jan 2010 09:18:00 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 11E0828C137; Wed, 27 Jan 2010 09:17:59 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0RHI2MG010224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 18:18:02 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001271718.o0RHI1de023338@fs4113.wdf.sap.corp>
To: nelson@bolyard.me (Nelson B Bolyard)
Date: Wed, 27 Jan 2010 18:18:01 +0100 (MET)
In-Reply-To: <4B606E82.8080905@bolyard.me> from "Nelson B Bolyard" at Jan 27, 10 08:49:06 am
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, ietf@ietf.org
Subject: Re: [TLS] Confirming consensus about one
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, 27 Jan 2010 17:18:01 -0000

Nelson B Bolyard wrote:
> 
> On 2010-01-27 07:37 PST, Martin Rex wrote:
> > Yoav Nir wrote:
> 
> >> Actually it's easier to hard-code the ciphersuite list on the client,
> >> because it never changes with most applications. Adding logic to
> >> differentiate between initial handshakes and repeated handshakes
> >> complicates the code (though not by much)
> > 
> > It more complicated than that, because SCSV is additionally necessary
> > for sensible behaviour even with -03 when doing old renegotiation
> > on a connection where the initial ClientHello did not use any
> > TLS extensions.
> 
> I think you meant to write "necessary to prevent vulnerable renegotiation on
> a connection where the initial ClientHello did not use any TLS extensions".
> If that is what you meant, please confirm.

It is necessary to actually perform an old-renegotiaion successfully
while at the same time preventing an attacker from being able to
proxy that old renegotiation into a renegotiation handshake of
an updated server that still allows backwards-interoperable
old renegotiation for old clients.

> 
> What you wrote sounds more like you were expecting "old renegotiation" to
> succeed.

Correct, I am expecting that.

That is a configuration option that implementations (hotfixes into
installed base, early during the transition) are likely required
to offer.

That we recommend to discontinue old-style renegotiation is
a totally different issue.

>
> If you were indeed expecting that, then why does SCSV play any
> role in that at all?

The purpose of SCSV is to reliably prevent any undesired renegotiations
from being possible.  The only handshakes where you can reliably
distinguish desired from undesired is those between updated clients
and updated servers.  

If an implementation of TLS offers a configuration option to allow
old-style reneogitation for interop with installed base old servers,
then we should an can limit that fallback to old servers.  This is
what the brand-new section 4.2 tries to explain (although it is
in dire need of editorial fixes in order to become comprehensible).


-Martin