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

"Kemp, David P." <> Tue, 12 January 2010 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A6D53A6A0D for <>; Tue, 12 Jan 2010 07:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XSGEbMld-D+S for <>; Tue, 12 Jan 2010 07:43:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D5323A67D6 for <>; Tue, 12 Jan 2010 07:43:36 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Jan 2010 10:43:33 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
Thread-Index: AcqTlUE7l7NkR4APTM+Z+mGuQ8t4MQAAF6wA
References: <> from "Kemp, David P." at Dec 30, 9 12:52:35 pm <>
From: "Kemp, David P." <>
To: <>
X-OriginalArrivalTime: 12 Jan 2010 15:44:05.0171 (UTC) FILETIME=[12206830:01CA939E]
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jan 2010 15:43:37 -0000

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.

If a renegotiation attack exists (which I also infer from the
urgent discussions over the past several months), then either
a client or a server may wish to guarantee that it is not
subject to that attack.

The only way to provide that guarantee is for the new protocol
spec to require that both client and server support the new
protocol or abort the connection.  If the attack could be
prevented by modifying only clients, then the spec would not
have required modifications to the installed base of servers,
and vice versa.

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


-----Original Message-----
From: Martin Rex [] 
Sent: Tuesday, January 12, 2010 9:40 AM
To: Kemp, David P.
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Kemp, David P. wrote:
> Amazon and Google are free to accept SSLv2 as well as
> (minor MSbit unset) if they perceive the benefit of communicating to
> greater than the risk of being attacked.   That has no bearing on
> whether the protocol spec for TLSv1.x-patched requires aborting
> connections with bozo endpoints, which of course it should.   Service
> providers/consumers can make their own choice of which protocol
> and ciphersuites to accept, with the knowledge that more restrictive
> choices will lock out some endpoints.   It has always been thus.

I don't understand what you mean.

If by "accept TLSv1.x-unpatched" you mean initial handshakes with the
installed base of SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 without the
renegotiation protection then your assertion is flawed.

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

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.  That's purely a client issue and has the
prerequisite that the client completely botches the server
on the initial handshake and is equivalent in effectiveness to XSRF, XSS
and server impersonation -- something that protected TLS renegotiation
can not protect from.