Re: [TLS] Minutes from Tuesday (Martin Rex) Fri, 31 October 2014 01:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E69E1A8A45 for <>; Thu, 30 Oct 2014 18:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R9M4Od9yHZ94 for <>; Thu, 30 Oct 2014 18:26:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61C411A8A3A for <>; Thu, 30 Oct 2014 18:26:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 4328B6E99B; Fri, 31 Oct 2014 02:26:22 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 35CBF449BE; Fri, 31 Oct 2014 02:26:22 +0100 (CET)
Received: by (Postfix, from userid 10159) id 2D0721AF6E; Fri, 31 Oct 2014 02:26:22 +0100 (CET)
In-Reply-To: <>
To: Bodo Moeller <>
Date: Fri, 31 Oct 2014 02:26:22 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Cc: "" <>
Subject: Re: [TLS] Minutes from Tuesday
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Oct 2014 01:26:27 -0000

Bodo Moeller wrote:
> Martin Rex <>:
>> Rather than aborthing the TLS handshake, the server ought to include
>> a TLS extension in the ServerHello indicating that he recognized a
>> potentially inappropriate fallback and otherwise continue the TLS handshake
>> in the regular fashion, leaving the decision of whether&how to continue
>> entirely up to those clients who do perform insecure fallbacks.
> I just don't think that the additional benefit (per connection)
> is worth the additional computational effort (per connection), and the
> extra latency: for many clients, there is *no* additional benefit at all.

There is a *HUGE* benefit for clients.  They will be able to properly
recognize accidental fallbacks that should not have happened in the
first place.  Otherwise it takes bug reports and several years before
client connection management failures get fixed.

> I'm also concerned about the mechanism being more error-prone if servers
> don't respond with a fatal alert.  If it's a warning alert (or other
> signal) instead

NO Alert at all.  Regular continuation of the handshake.

> clients will require additional code to handle this properly,
> whereas reacting to a fatal alert is something that all TLS
> implementations already know how to do.

That reaction is called interop failure.  That is the far opposite
of what IETF working groups are supposed to consciously cause to happen
when the alternative would be to make interop succeed.

As I keep saying, the server decides based on the server's policy
whether it is OK to proceed with the handshake and pick his favorite
properties from the parameters proposed by the Client, and then it is
up to the client to determine, based on the client's own policy,
whether the client is OK to continue.

The TLS protocol offers a negotiation of protocol parameters, and it
actually cryptographically protects this negotiation.  It is silly for
a client to propose parameters that it actually does not want to
have negotiated.  

> We could create a client-side signal that allows the client to specify the
> desired AlertLevel, but this again would add further complexity to the
> protocol (by making server behavior more complex).

The Server ought to continue the regular TLS handshake SUCCESSFULLY.
But it could include a ServerHelloExtension in response that tells
the client "if you really think you could do better, and your app
on top contains the megabyte of flawed "downgrade dance" app coding
that makes Poodle so successful, then you may want to reconsider
your ClientHello offer."

Even when falling back all the way to SSL VERSION 2.0 CLIENT-HELLO,
should be safe and spec-compliant for the client to offer
at least { 0x03, 0x01 } aka TLSv1.0 and the mandatory-to-implement
TLSv1.2 cipher suite TLS_RSA_WITH_AES_128_CBC_SHA

and I really do not understand why all those downgrade dancers
didn't fix their code at least when they renego-patched, because
back then we discussed rather extensively how bad it would be if
an attacker would be able to remove a capability from ClientHello
that both client and server support, and the client even believes
to be a necessity.