Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Martin Rex <mrex@sap.com> Tue, 12 January 2010 16:40 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 8D2F23A6A3F for <tls@core3.amsl.com>; Tue, 12 Jan 2010 08:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Level:
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 o7WCSS7xu9C7 for <tls@core3.amsl.com>; Tue, 12 Jan 2010 08:40:43 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 740C93A6A4F for <tls@ietf.org>; Tue, 12 Jan 2010 08:40:43 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0CGediA025332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 17:40:39 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001121640.o0CGedKe007515@fs4113.wdf.sap.corp>
To: DPKemp@missi.ncsc.mil (Kemp David P.)
Date: Tue, 12 Jan 2010 17:40:39 +0100 (MET)
In-Reply-To: <201001121543.o0CFhYuI011143@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 12, 10 10:43:33 am
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] SCSV vs RI when both specified. Was: Updated draft
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: Tue, 12 Jan 2010 16:40:44 -0000

Kemp, David P. wrote:
> 
> Perhaps I misunderstand the issue, but if there is absolutely no
> known security problem in the absence of C->S signaling (ClientHello
> contains neither SCSV nor empty RI), then it would seem that
> C->S signaling is superfluous and should have been omitted from
> the renego spec.  I inferred from its existence that it served
> some useful purpose.

We need the C->S signaling in order to allow the S->C signaling,
because the originial SSL&TLS protocols do not provide sufficient
slack for S->C signaling without prior C->S signaling.

Technically a S->C signaling for the initial handshake would be
sufficient to prevent an updated client from having a client
perform an old renegotiation with an updated server.  Doing
it both ways makes it more robust, and provides additional
room for policy decisions.


> 
> That is not a policy decision embedded in protocol, it is a
> truth in advertising requirement.  If a client's or server's
> policy is that communication is more important than resistance
> to renegotiation attack, than that policy is expressed by accepting
> connections using the SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
> protocols.

A TLS client or TLS server that does _not_ interoperate with an old
TLS implementation on the initial handshake is simply not compliant
to whatever protocol (SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2) is
negotiated.

The new specification about (secure) TLS renegotiation _only_
deprecates an optional feature of the existing protocol and
adds a new optional feature for them.  This spec does _NOT_
change the core protocol.  Otherwise it would not be an
update, but a new protocol.


-Martin