Re: [TLS] Minutes from Tuesday (Martin Rex) Mon, 27 October 2014 19:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AA321AD1EE for <>; Mon, 27 Oct 2014 12:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 eCtkyfhe8rnm for <>; Mon, 27 Oct 2014 12:38:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 152901A00F6 for <>; Mon, 27 Oct 2014 12:38:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 08F7571BB9; Mon, 27 Oct 2014 20:38:32 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 01AD94405F; Mon, 27 Oct 2014 20:38:31 +0100 (CET)
Received: by (Postfix, from userid 10159) id EF06C1AF5A; Mon, 27 Oct 2014 20:38:31 +0100 (CET)
In-Reply-To: <>
To: Bodo Moeller <>
Date: Mon, 27 Oct 2014 20:38:31 +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: Mon, 27 Oct 2014 19:38:46 -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.
> That would work too, but the server would then be doing all the work to
> send a ServerKeyExchange even if the client is going to abort the
> connection.

I do believe the server load issue here to be sufficiently close to
marginal to be irrelevant.

Even you write somthing to this effect:

> Well, even just having to fall back to make the connection work indicates
> that something is wrong -- that's not a generally expected way of
> establishing a TLS connection. (Clients can gather some statistics without
> sending TLS_FALLBACK_SCSV if they want to use the connection regardless.)

The problem with having the server (rather than the falling-back client)
abort the connection is that the client has no reliable indicator to
figure out the reason for connection failures,  and have to continue
relying on flawed heuristics.  MSIE has a similar bug in connection
management that FF used to have over several years (and which could often
be observed/reproduced by by hitting <F5> ("reload") quickly several
times on complex pages).  On MSIE, I saw it as a result of complex
pages with Javascript-based navigation that performed (and killed)
background downloading of images.

> It seems that the response mechanism that you propose would allow the
> server to confirm to that client that the server noticed that the client
> noticed that something is wrong. What would really be gained by that,
> compared to what the current TLS_FALLBACK_SCSV protocol offers?

It would leave the decision whether to abort or continue the handshake
with the one-and-only connection peer that is (a) doing the fallback
and (b) in the position to establish another connection and attempt
another handshake, and (c) query the user interactively if something
odd is going on.

I would gladly add a server extension into ServerHello of our TLS
implementation in response to a FALLBACK SCSV, whereas I will entirely
ignore this proposal as is.