Re: [TLS] Chatter on consensus

Martin Rex <mrex@sap.com> Wed, 27 January 2010 21:02 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 1264A3A69F6 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 13:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 x+DdoE6svvhC for <tls@core3.amsl.com>; Wed, 27 Jan 2010 13:02:07 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7921B3A6828 for <tls@ietf.org>; Wed, 27 Jan 2010 13:02:06 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0RL2JUL007673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 22:02:19 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001272102.o0RL2I9x007631@fs4113.wdf.sap.corp>
To: DPKemp@missi.ncsc.mil
Date: Wed, 27 Jan 2010 22:02:18 +0100
In-Reply-To: <201001271913.o0RJD2B7008022@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 27, 10 02:13:00 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Chatter on consensus
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, 27 Jan 2010 21:02:09 -0000

Kemp, David P. wrote:
> 
> > From: Martin Rex [mailto:mrex@sap.com]
> >
> > These two MUST NOTs and the two unexplained NOT RECOMMENDEDs
> > to which I'm opposed are clear violations of rfc-2119 section 6:
> 
> This is admittedly a strong argument.  However, in my opinion, alignment
> with 2119 must be evaluated in light of:
> 
> > [Nikos]: I believe allowing the sending of both SCSV 
> > and extension might harm interoperability instead.

This is a clear misunderstanding on the issue.

Secure renegotiation requires verification of the contents
of the verify_data contained in the renegotiation_info.
So if the presence of an empty RI or SCSV in a ClientHello
during a handshake that is a renegotiation to the server
confuses a server about having to match the verify_data,
then you have much more serious issues to worry about.

> 
> > [Pettersen]: The SCSV is a temporary fallback, one that 
> > will not be needed when clients enter strict mode, since 
> > when that happens servers have to support the RI extension.

This is also a misunderstanding.  The requirement for the server
to recognize SCSV is PERMANENT, even in -03.  Clients may stop
sending SCSV when they stop sending extension-less ClientHellos
or SSLv2 CLIENT-HELLO, but the requirement for the server to
recognize SCSV is going to stick for just as long as the
support for TLS protocol_versions {0x03,0x00} to {0x03,0x03}


Personally, I believe it is not possible to create an argument
(that is not lame) to justify that violation of rfc-2119 section 6.

As previously mentioned, I have provided an explanation along the
lines of a semi-formal correctness proof that these signals do
not interfere with each other -- it only a bad choice of description
in the document. 


The only reason why this awkward exception was added to the document
is to make it less obvious that not making SCSV mandatory and getting
rid of empty RI on initial handshakes in ClientHello is a poor
engineering decision.


Just as it is often possible to simplify logic circuits to obtain the
results of complex boolean functions, the use of abstract architecture
and methodologies from functional correctness proofing can
help you simplify the results if you, for whatever reason, want
to combine two different implementations of the same feature
of an abstract architecture.

 
> 
> > From: Martin Rex [mailto:mrex@sap.com]
> >
> > It more complicated than that, because SCSV is additionally
> > necessary for sensible behaviour even with -03 when doing
> > old renegotiation on a connection where the initial
> > ClientHello did not use any TLS extensions.
> 
> Say whaaaaat?  When doing old renegotiation, neither SCSV nor RI are
> necessary because by assumption the client, the server, or both do not
> support secure renegotiation.


For me, that's a deja-vu.  I've found myself pretty unsuccessful convincing
people at the abstract architecture level.  I always have to resort to
scaring people with depictions of attack scenarios to get their attention.


In case that you are a TLS implementor, then we DEFINITELY need that
brand-new section 4.2 in the -03 document fixed before publication.

It's been discussed during IETF Last Call of the -01 document:
 Martin Rex    http://www.ietf.org/mail-archive/web/tls/current/msg05151.html
 Marsh Ray     http://www.ietf.org/mail-archive/web/tls/current/msg05155.html
 Pasi Eronen   http://www.ietf.org/mail-archive/web/tls/current/msg05186.html


We in the IETF are supposed to provide the highest possible
interoperability, configuration options for policy and resonable
default settings.

Quoting section 4 from the -03 ("current") version of the WG document:

   4. Backward Compatibility

   Existing implementations which do not support this extension are
   widely deployed and in general must interoperate with newer
   implementations which do support it.  This section describes
   considerations for backward compatible interoperation.


What exact settings the consumer of the technology uses is up to
the consumer.  If you are worried about "original" TLS, then
your browser ought to have regular HTTP and FTP securely disabled?
(my browser does not even provide such a setting...)

>
> If an old server requests a new client to renegotiate, and:
> 1) the client ignores the RECOMMENDED refusal to renegotiate, and
> 2) the old server INCORRECTLY fails to ignore extensions, and
> 3) the client sends an RI extension as RECOMMENDED,
> ... then there may be a handshake failure, which sounds to me like the
> desired outcome in such a broken circumstance.


If that was really the desired outcome, then our browsers would already
have old renegotiation securely removed for months.  Browsers probably
are the most regularly patched pieces of software we have.

No.  A client MUST send either RI or SCSV to an _old_ server on a
permitted old renegotiation so that this handshake can not be
proxied by an MitM into an initial handshake of a _patched_ server.

If the connection is not attack, that signal ends up being totally
ignored.  Which is exactly what the convoluted section 4.2 says.


> 
> If the client instead sends SCSV in order to dodge a handshake failure,
> which is NOT RECOMMENDED, the server is prevented from immediately
> detecting an attack.  Sending SCSV in this circumstance, far from being
> necessary or sensible, sounds to me like reckless behavior - pushing the
> envelope of legacy interoperability.

That NOT RECOMMENDED makes no sense here and violates rfc-2119 section 6.

The general interop recommendation in TLS is that you get the highest
chance of interoperability if a client supplies the same parameters
in a renegotiation ClientHello that it applied in the initial
ClientHello on a connection.  Same for session resume on a new
connection.

If the client didn't send TLS extensinons in the initial ClientHello,
it is a pretty bad advice to start sending TLS extensions in the
renegotiation ClientHello, and it is in conflict with the general
recommendation for what TLS client should do for maximum interop
(send the same parameters in ClientHello).

And if the client does not want to renegotiate, then there is no
ClientHello to be sent but instead either a warning-level
no_renegotiation alert if the clients wants to try continue
talking or a fatal handshake_failure if the client wants to
abort the connection.


> 
> As above, it might enhance interoperability long-term if new clients
> operating in secure renegotiation mode simply failed to renegotiate with
> broken servers.  If I were for changes to -03 (which I am NOT!), it
> would be to change NOT RECOMMENDED to MUST NOT send SCSV in insecure
> renegotiation.

That would not only violate rfc-2119, that would be completely
unreasonable.

I do _not_ mind if you do not care for backwards interop scenarios,
but I would recommend that you get out of the way of those who care
because they must provide it to their customers in a non-disruptive
fashion.  


-Martin