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

Marsh Ray <marsh@extendedsubset.com> Tue, 12 January 2010 15:17 UTC

Return-Path: <marsh@extendedsubset.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 91D543A6910 for <tls@core3.amsl.com>; Tue, 12 Jan 2010 07:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9+nDkj1vLTpO for <tls@core3.amsl.com>; Tue, 12 Jan 2010 07:17:36 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A4BAF3A6853 for <tls@ietf.org>; Tue, 12 Jan 2010 07:17:36 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NUiUv-000PVW-PZ; Tue, 12 Jan 2010 15:17:33 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5633C6076; Tue, 12 Jan 2010 15:17:31 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19blLw6rwBFbR5MtSqxV6zrxl0QOfsfNaU=
Message-ID: <4B4C928C.5050105@extendedsubset.com>
Date: Tue, 12 Jan 2010 09:17:32 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <201001121440.o0CEe7k1026688@fs4113.wdf.sap.corp>
In-Reply-To: <201001121440.o0CEe7k1026688@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "Kemp David P." <DPKemp@missi.ncsc.mil>, 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
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 15:17:37 -0000

Martin Rex wrote:
> 
> There is absolutely _NO_ known security problem and no vulnerability for
> a server to accept an initial handshake with the existing SSLv3, TLSv1.0,
> TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
> message does neither contain SCSV nor an empty extension RI.

Baloney!

> The possibility for an "attack" where an old client's renegotiation
> handshake is proxied into the initial handshake of a server is of
> no concern to the server.

TLS is a network data security protocol. Both parties have an interest
in the security of the connection.

If a client has the attacker's data in his input buffer, then a
legitimate server's handshake provides a certificate which the client
interprets as authenticating the previous data, the attacker has stolen
the servers credentials!

(Interpreting TLS credentials over a connection this way was previously
thought to be a valid and secure thing to do, and is made so by the RI
extension.)

> That's purely a client issue and has the
> prerequisite that the client completely botches the server authentication
> on the initial handshake

TLS specifies no requirement for the client to authenticate the server
on the initial handshake. It is completely within the spec for a client
to negotiate an anon-anon connection which is then upgraded to anon-cert
or cert-cert.

Regardless, this necessary requirement for security (that a client must
fully validate and verify the server's certificate during and not after
every handshake) is non-obvious and basically undocumented for
application developers.

Heck, most of us didn't even know renegotiation existed or that our SSL
stacks would do it automatically. There are surely applications coded by
competent and conscientious developers which do not behave this way only
because no one was aware of the need to do so. And that need only exists
because TLS renegotiation was vulnerable to a MitM attack before this fix!

> and is equivalent in effectiveness to XSRF, XSS
> and server impersonation -- something that protected TLS renegotiation
> can not protect from.

You can't have it both ways. You can't say there's "absolutely _NO_
known security problem" and that "protected TLS renegotiation can not
protect from" it.

But in fact, there is an attack. The good news is that having both
endpoints patched to support RI, or just one endpoint patched and
configured in strict-secure mode, does protect your connection from this
attack.

- Marsh