Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

Nelson B Bolyard <nelson@bolyard.me> Thu, 03 December 2009 01:35 UTC

Return-Path: <nelson@bolyard.me>
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 27E123A6358 for <tls@core3.amsl.com>; Wed, 2 Dec 2009 17:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level:
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 eXh2JYO8Wdcf for <tls@core3.amsl.com>; Wed, 2 Dec 2009 17:35:25 -0800 (PST)
Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 054A63A67A2 for <tls@ietf.org>; Wed, 2 Dec 2009 17:35:24 -0800 (PST)
Received: (qmail 24660 invoked from network); 3 Dec 2009 01:35:13 -0000
Received: from unknown (24.5.142.42) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 03 Dec 2009 01:35:13 -0000
Message-ID: <4B1715D0.5010107@bolyard.me>
Date: Wed, 02 Dec 2009 17:35:12 -0800
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp>
In-Reply-To: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer
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: Thu, 03 Dec 2009 01:35:26 -0000

On 2009-12-02 16:38 PST, Martin Rex wrote:
> Nelson B Bolyard wrote:
>>> Hold on now, is there any reasonable interpretation of
>>> draft-ietf-tls-renegotiation which "codifies the behavior of those
>>> non-conformant servers"?
>> Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF*
>> (rather than in addition to) the RI extension is such an attempt.
>> Such proposals now exist.
> 
> It is not the first of it's kind.
> 
> The first is called rfc-5246, which is at proposed standard for a year
> and contains a broken TLS extensions definition called signature_algorithm,
> where the Server _uses_ the extension but MUST NOT confirm its use
> through ServerHello.

There are other client hello extensions that are not defined to be
acknowledged by the server.  that's irrelevant.


> What we're doing (looking at EKRs wording) is, that we are defining
> the MCSV to be "an emtpy TLS extension RI"

No, and EKR's spect doesn't say that.  EKR's spec says that the server
responds to the two in the same way.

> But given that definition, that MCSV _is_ an empty "TLS extension RI"

No.  Not _is_.  It is convenient to your argument to imagine that it _is_.
but it is not.

> then it is fairly logical to _not_ completely ignore this provision in
> TLS extensions:
> 
>   There MUST NOT be more than one extension of the same type.

That's right.  The set of encoded extensions may not contain more than
one of the same type.  But a cipher suite is a not an encoded extension,
even when the server chooses to respond to it as if it was.


>> And some server vendors believe they have every right to reject client
>> hellos that include any hello extensions. 
> 
> Unfortunately, implementations of SSLv3 have that right.

Or rather, one or two out of many still do.  The vast majority of SSL 3.0
implementations ignore all extensions, and have for at least a decade.

> It was a pretty bad idea from the IETF TLS WG to never publish
> an updated SSLv3 spec as an informational RFC that officially
> included the forward compatibility provision.

The IETF TLS WG never officially published any SSLv3 spec.

>> They now vociferously propose
>> that we design the solution to the renegotiation vulnerability so that,
>> even after they have patched their servers for this vulnerability, their
>> servers can CONTINUE to reject client hellos with hello extensions.
>> That's the issue here.
> 
> You're barking up the wrong tree.
> 
> This is about clients that have to remain interoperable with servers
> that have _NOT_ been patched yet, SSLv3 Servers, SSLv2 Servers as well
> as servers that are never going to be patched.
> 
> For software vendors it is a sad fact of life that they can not
> recklessly ship hotfixes that will kill existing usage scenarios
> in productive environments of their customers.  In particular not
> for scenarios that have been interoperating fine for so many years,
> and with no substantial justification for a disruptive change.

Hmm.  So software vendors cannot discontinue SSL2 support?
Oh wait, they all DID!
And for the very reason that SSLv2 was deemed insecure.

>>> This is an urgent bug fix, not an upgrade, and as such most of us share
>>> the goal of causing absolutely minimal disruption to existing systems.
>>>
>>> Sometimes even perfectly-conformant clients are asked to connect to TCP
>>> port numbers on which a few *gasp* imperfect servers are listening.
>>> Since this sometimes results in a hung connection, the condition can
>>> only be detected after a (relatively) long timeout.
>> Those servers MUST be patched now.  It's a simple thing to patch them to
>> be tolerant of (that is, to IGNORE) client hellos.
> 
> This is completely unrealistic even for newest server under full maintenance
> that you can upgrade to the most recent TLS version.

There's absolutely no need to upgrade to any newer version than the version
they already claim to support.  They just need to ignore hello extensions,
and learn to correctly negotiate whatever version they claim to support
when they receive a hello with a higher version number, just as the SSL 3.0
spec always required.

Ignoring extensions is typically a ONE LINE CHANGE.  It's typically taking
a line of code that complains if the length of the message is not exactly
equal to some computed value, and changing it to allow "greater than or
equal to".

THat fix is a MUCH smaller change than any of the rest of the change
required for the vulnerability fix, and it ansolutely eliminates all need
for so-called extensionless client hellos.  It means that ANY client that
recieves a hello with BOTH a MCSV and an RI extension can do the right thing
and not require a "fall back" just because an RI was present.

> The servers and clients are all over the place and belong to thousands
> of entirely different organisations and will be subject
> to completely independent update schedules and extremely varying
> amounts of testing/validation before upgrading productive servers.

That one line of code is going to require MUCH less testing than the rest
of the patch for this vulnerability.

>> But they steadfastly refuse.  Instead they demand that we retroactively
>> modify the definition of TLS to explicitly recognize and legitimize
>> this extension-intolerant behavior.
> 
> How about facing the real world and real world problems for an instant?

I am facing the real world problem: namely, servers that do not conform
for years, then later demand that standards be retroactively modified to
recognize and accept their behavior as having been right all along, and
demand that future protocol changes preserve their right to continue to
be non-conforming, thereby forcing fallback behavior on clients.

>> If it effectively requires that new client products MUST implement fallback
>> to be interoperable with conformant servers, then it most certainly does
>> codify that behavior.
> 
> You're getting it backwards again.
> 
> The fallbacks are already implemented.
> It would be unwise to leave the fallbacks vulnerable to downgrade attacks,

If servers that are invulnerable do not require fallbacks, because they
ignore extensions, and only servers that are vulnerable require fallbacks,
then only clients that fall back are vulnerable.