IETF Logo Mail Archive

Re: [TLS] Proposal for hybrid solution using most of the ideas

Chris Newman <Chris.Newman@Sun.COM> Thu, 26 November 2009 17:44 UTC

Return-Path: <Chris.Newman@Sun.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 9509A28C113 for <tls@core3.amsl.com>; Thu, 26 Nov 2009 09:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 1wDJXlc+BG9R for <tls@core3.amsl.com>; Thu, 26 Nov 2009 09:44:14 -0800 (PST)
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 4C8833A67E4 for <tls@ietf.org>; Thu, 26 Nov 2009 09:44:14 -0800 (PST)
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAQHi7aR014444 for <tls@ietf.org>; Thu, 26 Nov 2009 09:44:07 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTQ0050097H4S00@fe-sfbay-10.sun.com> for tls@ietf.org; Thu, 26 Nov 2009 09:44:07 -0800 (PST)
Received: from vpn-129-150-242-97.sfbay.sun.com ([unknown] [71.92.75.71]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTQ0041699GJ000@fe-sfbay-10.sun.com>; Thu, 26 Nov 2009 09:44:06 -0800 (PST)
Date: Thu, 26 Nov 2009 09:43:29 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
In-reply-to: <200911210002.nAL02CEx007574@fs4113.wdf.sap.corp>
Sender: Chris.Newman@Sun.COM
To: mrex@sap.com
Message-id: <8D2529C4D76F7E4B2AC769A4@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <200911210002.nAL02CEx007574@fs4113.wdf.sap.corp>
Cc: tls@ietf.org
Subject: Re: [TLS] Proposal for hybrid solution using most of the ideas
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, 26 Nov 2009 17:44:15 -0000

--On November 21, 2009 1:02:12 +0100 Martin Rex <mrex@sap.com> wrote:
> Chris Newman wrote:
>>
>> --On November 19, 2009 22:23:43 +0100 Martin Rex <mrex@sap.com> wrote:
>> > Asking SSLv3 implementations to improve on their extensions-intolerance
>> > is still OK.  Requiring them to implement generic TLS extensions
>> > is not, because it has nothing to do with the problem and is
>> > an unnecessary complexity for the fix.
>>
>> What if we require SSLv3 compatible clientHello and SSLv3 serverHello to
>> list RI first and at least ignore additional extensions, waiving the
>> requirement for full extension support for SSLv3-only implementations?
>
> I don't see how this would solve the problem.

This would solve the problem of SSLv3-only implementations that must be 
upgraded to address this issue being difficult to upgrade to full TLS with 
general extensions support.  That's a problem I believe may be worth 
solving for this particular security vulnerability.

It also addresses the very real problem that having two ways to negotiate 
the same thing is bad design and there have been proposals to negotiate via 
different protocol elements in SSLv3 than in TLS.

> How to you interoperate with installed base SSLv3 and TLSv1.0 that
> is extensions-intolerant without being vulnerable to downgrade attacks?

The alleged extensions-intolerant servers were broken when they were first 
released and it is unfortunate their failure to comply with standards was 
not identified and fixed sooner.  Since they must be upgraded to either be 
made secure or identified as secure, why not fix the standards-compliance 
bug (failure to tolerate extensions) at the same time?  Seems a lot cleaner 
and safer than kludging crap into critical fields in the ServerHello.

So this is a problem that I do not consider worth solving -- indeed I 
prefer solutions that break implementations that already demonstrated an 
inability to follow published standards.  As a pragmatist, I'd consider an 
exception if a particular implementation was widely deployed and difficult 
to upgrade, but we'd need to see a list of these non-compliant servers to 
make that evaluation.  If nobody is motivated enough to produce that list, 
I assume none of them are problematic.

		- Chris

v2.23.0 | Report a Bug | By Email