Re: [TLS] Minutes from Tuesday

Bodo Moeller <> Tue, 21 October 2014 16:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D0E611A890F for <>; Tue, 21 Oct 2014 09:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6ACzmwasFtP3 for <>; Tue, 21 Oct 2014 09:19:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4917F1A8904 for <>; Tue, 21 Oct 2014 09:19:55 -0700 (PDT)
Received: from ( []) by (node=mreue004) with ESMTP (Nemesis) id 0LeyNP-1YTkcJ3GVL-00ql3H; Tue, 21 Oct 2014 18:19:53 +0200
Received: by with SMTP id a41so1734142yho.37 for <>; Tue, 21 Oct 2014 09:19:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id h34mr4380741yhq.199.1413908391567; Tue, 21 Oct 2014 09:19:51 -0700 (PDT)
Received: by with HTTP; Tue, 21 Oct 2014 09:19:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 21 Oct 2014 18:19:51 +0200
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a11c1db2a6ca9c40505f13310"
X-Provags-ID: V02:K0:TxcrrPUdYcWe4bcozobDtII8+I1GnBhm+uzuw363HfN JdWS6ynPJsTse79xMtJue0zOJUVXQt0kwpTayXbRS6IIwy4EBP XjCpQj5px30mI4bjgsZLzvSfdUBYSp9O7QyDWtajZ8ardDDk4p iaHrrueH27oXQ8BVXNGZEj4ehEAa0TrrQITd3Mt7GpZ5aaEb/w o+NCy/T5t5yIkfcR8omV+ReIsA2wlpRrkhRf2knPp69YpOvwMc oADhXhY+mwSpqFwPafHm3svKFuR0diNhY+7fdptdxJWDU17FDg UoapyfLhAldwjp4Im+za+W6Zdb3ULTwpH8KL3KFD9pkXyu9rw8 /8W69nYKvqr21U+AURHbYWZw/zlRlUxpD2HUssShtc8LLx9Q+5 Di0znowUaQTZsJX0tUxSgRXDb1dBrIsPagRPFh5COlsT3/xcWp /KhtK
X-UI-Out-Filterresults: notjunk:1;
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: Tue, 21 Oct 2014 16:19:57 -0000

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

This would also allow clients (browsers probably) to gather real data
> on potentially incorrect fallbacks, [...]

And it would then be a decision of the (fallback-performing) clients
> whether and when to start hard-failing, once they've sorted out their
> connection management and figured out how to deal with false positives
> in their fallback heuristics.

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.)
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?