Re: [TLS] Accept draft-turner-ssl-must-not-02 as WG item

Martin Rex <mrex@sap.com> Wed, 15 September 2010 19:26 UTC

Return-Path: <mrex@sap.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 0CA383A69B4 for <tls@core3.amsl.com>; Wed, 15 Sep 2010 12:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.108
X-Spam-Level:
X-Spam-Status: No, score=-9.108 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 2i3tZeLTSe0K for <tls@core3.amsl.com>; Wed, 15 Sep 2010 12:26:30 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D07F13A6986 for <tls@ietf.org>; Wed, 15 Sep 2010 12:26:29 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8FJQkiq005952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Sep 2010 21:26:46 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009151926.o8FJQjWp009193@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Wed, 15 Sep 2010 21:26:45 +0200 (MEST)
In-Reply-To: <E1Ovj4f-0007mZ-4a@wintermute02.cs.auckland.ac.nz> from "Peter Gutmann" at Sep 15, 10 03:54:21 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Accept draft-turner-ssl-must-not-02 as WG item
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 15 Sep 2010 19:26:31 -0000

Peter Gutmann wrote:
> 
> Martin Rex <mrex@sap.com> writes:
> 
> >Personally I can not think of a reason to move away from what rfc-5246
> >appendix E.2 says.
> 
> I can.  That language has been in there more or less forever, and it's had
> pretty much zero effect in encouraging implementations to drop the SSLv2
> handshake (some implementations gradually have over time, but probably not
> because of text that says "well, you know, it would be really uncool if you
> kept sending SSLv2 hello's for the next twenty years").  Without a clear MUST
> NOT for the server to finally get clients to switch off SSLv2 hellos, we're
> never going to get rid of these things.

 client MUST NOT negotiate or use SSL 2.0  is fine with me
 client MUST NOT send SSL 2.0 CLIENT-HELLO is fine with me
 server MUST NOT negotiate or use SSL 2.0  is fine with me

but

 server SHOULD NOT accept SSL 2.0 CLIENT-HELLO as the first message
 of a TLS handshake is not sensible and is in clear
 conflict with rfc2119 section 6.

What is written in new RFC affects new implementations at best,
and no amount of cursing, praying and MUST NOT-specifying is going
to change the behaviour of the installed base.  So the only effect
this change could result in is interop problems with a fraction
of the installed base.

The only time when this is permissible per rfc-2119 section 6 is
when retaining this feature on the server would cause harm to
this server -- and there is no harm for the server to accept
an SSL 2.0 CLIENT-HELLO as the first message of a TLS handshake.

Mind you that the existing specification already leaves it to
the discretion of implementors, vendors and server admins to
cause these interop problems if they choose to be so mean.
But the current spec does not unreasonably suggest to do this.



The OEM SSL implementation that we started shipping in 2000/2001
never contained an implementation of SSLv2, but it did contain the
option for the server to accept a SSL 2.0 CLIENT-HELLO as the first
message of an SSLv3 handshake (as described in rfc-5246 appendix E.2),
and for the client side to send an SSL 2.0 CLIENT-HELLO as the first
message of an SSLv3 handshake.

Our servers have since been accepting SSL 2.0 CLIENT-HELLOS as the
first handshake message.  There is no point for clients that don't
even implement SSLv2 to send an SSL 2.0 CLIENT-HELLO, other than
testing with the server side, so hardwired the client to never
send an SSL 2.0 CLIENT-HELLO for our apps in 2001.  This
matches rfc-5246 appendix E.2 just fine.

AFAIK, Firefox had been sending SSL 2.0 CLIENT-HELLO by default
up until 3.0.[0123?] versions and prior.  I'm still using a few
Linux Installations with Firefox 2.0 and one with Firefox 1.5 today.
(with no plugins, active content disabled and only for a small number
 of sites, behind a home NAT and a junkbuster that adjust User-Agent:),
and I'm likely going to use it like that for a couple of more years,
and there would be no benefit to waste several days to upgrade these
environments.  They're magnitudes safer than Joe Averages Windows with
MSIE with active content, plenty of plugins (acrobat,shockwave,flash)
ICQ, Messenger and surfing the entire internet.

Actually, with every day going by, the risks associated with
my old installations decrease further, while the risk of fairly new
installations are monotonically increasing every day.


-Martin