Re: [TLS] How to wade through Hello extensions was: The MCSV hack is a compliment

Martin Rex <mrex@sap.com> Thu, 10 December 2009 20:10 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 ABF843A6A36 for <tls@core3.amsl.com>; Thu, 10 Dec 2009 12:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Level:
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zkbA6hOCUQDZ for <tls@core3.amsl.com>; Thu, 10 Dec 2009 12:10:27 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2F2BA3A659B for <tls@ietf.org>; Thu, 10 Dec 2009 12:10:26 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBAKABp3002166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 21:10:11 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912102010.nBAKAAbI002844@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Thu, 10 Dec 2009 21:10:10 +0100
In-Reply-To: <4B214209.6020304@extendedsubset.com> from "Marsh Ray" at Dec 10, 9 12:46:33 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org, James@Manger.com.au
Subject: Re: [TLS] How to wade through Hello extensions was: The MCSV hack is a compliment
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: Thu, 10 Dec 2009 20:10:28 -0000

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > Marsh Ray wrote:
> > >
> > > It also requires the use of an extension.
> > 
> > No, it does NOT.
> > 
> > draft-mrex-tls-secure-renegotiation-03 uses additional data following
> > the compression_method in ServerHello for Server->Client signaling.
> > See Section 4.4 last two paragraphs of that draft.
> > 
> > That extra data is designed to be compatible with TLS extensions,
> > but it can be processed like a static 6-octet string by extensions-free
> > implementations.
> 
> Hmmm, an additional six bytes after a hello:
> 
> 0x00  0x04  0xFF  0x01  0x00  0x00
> 
> I'd call that an extension.

To an extension-less TLS client and TLS server this is a fixed, 6-octet
piece of binary data.

To extensions-aware TLS clients and TLS servers this is a single
TLS extension.

To avoid confusion with TLS extension RI, my openssl patch uses 0xff 0x02
(the I-D itself only contains TBD).


> 
> The only difference is that in draft-ietf-tls-renegotiation it contains
> useful payload data on renegotiation handshakes.

TLS extension RI uses an _much_ more complex sematic, which has been
causing the obvious confusion among implementers what to send on the
renegotiation ClientHello in a backwards interop scenario, and some
are actually fighting for the wrong answer.


> 
> Hmm, let's see how long it takes me to write this in C++.

In good mission-critical software, the error handling is 70-80% of
the code.  Your code avoids this issue for the most part.

Your approach is doing what I call module testing.
There should be more test vectors, in particular defective
test vectors, plus checking that the error handlings works
correctly (completely missing in your example).

If your error handling is using C++ exceptions, that this part
can _NOT_ be tested by module testing in this fashion (that would
only work embedded in the actual TLS implementation that does
the exceptinon processing.

What you didn't count so far is all the work that is necessary to
automate this testing, in particular if you want to do module
testing on the code when it is part of the TLS implementation,
which might include test scripts, Makefiles, new test targets, ...


Btw. unconditional assert() is something that you _DEFINITELY_ do not
want in mission critical software.  A crash/core-dump is not
permitted behaviour in productive environments.  Instead, if
you detect a situation that prevents you from continuing,
the code should try to fail sensibly and gracefully, which means
returning an error and trying to write a log/trace entry reporting
the situation.

If you have a server running with 200 concurrent user sessions,
and there is one situation where one of your libraries gets
called with a NULL object handle, you do _NOT_ want to crash
the entire server, causing all 200 users to loose all their
current state (including unsaved data), but instead, you
report an error to the caller and write a log/trace file entry.

When stuff like this happens at a customer site, it might be an
indicator that the callers above your code might not have sufficient
test coverage.

If you need to be able to run a debugger on the customers machine
in order to analyze an error a complex piece of application software,
then there are some environments where you will have a hard time
selling (or create a huge amount of maintenance costs).


Personally, I like the "writing code" part also  _much_ more
than the writing TESTs part (in particular because the latter
is several times more work).  When you are forced to write
your own tests (or take _full_ responsibility when your code
breaks at the customers site), then you may start writing code
in a fashion that it is easily testable, robust and failSAFE.


-Martin

Off-topic: using C++ for something that is a toolkit for consumption
by others is a decision you will regret badly after some years on
almost every Unix platform. (hints: shared libraries, dynamic runtime
loading, global symbol space -- there are tons of platfrom-specific
suprises waiting to be discovered).