Re: [TLS] Updated draft

Marsh Ray <> Fri, 18 December 2009 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C2DC3A6991 for <>; Fri, 18 Dec 2009 08:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zNUbTQwuox2v for <>; Fri, 18 Dec 2009 08:37:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7398E3A68AD for <>; Fri, 18 Dec 2009 08:37:19 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NLfpA-0003LL-Cg; Fri, 18 Dec 2009 16:37:04 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 8E2D86678; Fri, 18 Dec 2009 16:37:01 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/HX9xh+JSxslD4wP/x7LNWQSyQz2uAqVI=
Message-ID: <>
Date: Fri, 18 Dec 2009 10:37:00 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Robert Dugal <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List <>
Subject: Re: [TLS] 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: Fri, 18 Dec 2009 16:37:20 -0000

Robert Dugal wrote:
> Oops, you're right. I misstated what I'd like the draft to allow. 
> What I'd like is the option to always send the SCSV in the
> ClientHello and on renegotiation requests send the SCSV + RI
> extension in the ClientHello.

That certainly sounds like a reasonably minor change to make...but it isn't.

I don't recall seeing anyone propose wording changes that would allow
such behavior, except in the context of the other proposals which are
fundamentally different in that they modify the inputs to the PRF. It's
possible that some concrete wording was suggested and is in one of the
1340 emails in my TLS folder.

Currently, the SCSV achieves its primary objective with a very simple
definition. It has "exactly the same semantics as an empty
'renegotiation_info' extension".

IMHO, proponents of other semantics for SCSV should be able to produce
an equally straightforward description of what they are, or show
something truly magical to justify complicating the description. Saving
an 'if' statement somewhere, partially fixing a multiply-broken
scenario, or avoiding extensions handling in some non-general case don't
sound like they justify the extra complexity.

Personally, I'd prefer that we don't propose (and re-propose) design
features at this point. We have to ship a fix for this open security
vulnerability, and I think the current design is squarely in the "good
enough" department. I.e. it fixes the problem and doesn't make anything
else significantly worse.

If anyone sees a security flaw or attack against a correct
implementation of draft-ietf-tls-renegotiation-02, please please speak up.

- Marsh