Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

Marsh Ray <> Sat, 30 January 2010 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2C3D3A67CF; Sat, 30 Jan 2010 14:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RLyimwQ7rQlG; Sat, 30 Jan 2010 14:08:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A3A253A67B6; Sat, 30 Jan 2010 14:08:22 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NbLUn-0004k6-KQ; Sat, 30 Jan 2010 22:08:49 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 1831C6048; Sat, 30 Jan 2010 22:08:48 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/L2SjdR9WaJRcZsho7O5pDchH7bo/SKC4=
Message-ID: <>
Date: Sat, 30 Jan 2010 16:08:47 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Stefan Santesson <>
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
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
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: Sat, 30 Jan 2010 22:08:23 -0000

Stefan Santesson wrote:
> I totally agree in principle. However, if a renegotiating client sends a
> full RI extension with valid data AND the client also sends SCSV, then what
> security problem is introduced by allowing the renegotiation (i.e. Not
> aborting)
> No matter how hard I try, I can't find the security problem and I can't find
> the interoperability advantage.
> Hence, the "MUST abort" requirement seems like an unmotivated restriction.
> I'm not saying that we have to change the current draft, I'm just curious to
> understand the real benefits of this requirement.

In a sense it allows a consistent definition of the semantics of SCSV:
The presence of SCSV is equivalent to an empty RI extension. Under such
a definition, the presence of multiple conflicting RIs (especially an
empty RI during a renegotiation) is clearly an abort-able offense!

This "permitted, though NOT RECOMMENDED" practice of sending SCSV during
insecure renegotiation can be (charitably) thought of as not changing
the semantics of SCSV, but instead being a sneaky manipulation in order
to probe the target server to double check that he's still not upgraded.
 This probably does not add any real security (MitM could just drop the
RI from the Server Hello and the client might not be able to detect it
until after he sent his Finished message). Seems like implementations
wishing to use this kind of trickery could do so without it having been
explicitly permitted by the spec.

> Again, based on what I have seen, I would not be surprised.
> I don't think being accountable to the market is a very strong threat

Seriously, got anything better in mind? Security researchers dropping
0-days maybe?

> if a
> safe adjustment to a more liberal processing helps customers to avoid
> interop problems while maintaining the security of the protocol.
> Hence, if there IS a security threat that motivates this, then it is
> extremely important to spell it out in the clear.

At one time some there seemed to be some ambiguity in the specs (or at
least some interpreted it that way) as to whether or not extension data
on the Hellos was actually to included in calculations for the Finished
message verify_data. Perhaps some vendors included it and some did not,
and no one noticed at the time because there were no extensions defined.
I vaguely recall somebody suggesting on this list that (for
interoperability of course) some implementation calculated the
verify_data both ways and accepted either one that matched.

If this is in fact the case, it seems plausible that there might be
implementations (of older specs like SSLv3) out there for which
extension data can be dropped or changed by MitM.

I wonder if considerations for these systems has anything to do with it?

- Marsh