Re: [TLS] Minutes from Tuesday

Bodo Moeller <> Tue, 28 October 2014 11:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8A7C31A1BCC for <>; Tue, 28 Oct 2014 04:11:58 -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 OGaGlV4gajYI for <>; Tue, 28 Oct 2014 04:11:54 -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 42DD21A1B9E for <>; Tue, 28 Oct 2014 04:10:41 -0700 (PDT)
Received: from ( []) by (node=mreue102) with ESMTP (Nemesis) id 0M8hmN-1Y4Igf3EZv-00wFtu; Tue, 28 Oct 2014 12:10:39 +0100
Received: by with SMTP id a41so179268yho.25 for <>; Tue, 28 Oct 2014 04:10:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id q24mr1998252yhg.131.1414494635634; Tue, 28 Oct 2014 04:10:35 -0700 (PDT)
Received: by with HTTP; Tue, 28 Oct 2014 04:10:35 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 28 Oct 2014 12:10:35 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a11c1c9fc4b3ac2050679b270"
X-Provags-ID: V02:K0:SA+tfHfwj2mgPPFYZVJOvwKdAv1uNUEztUvnAXnQVlq pTj2UoykBjXm60Lb94h/8BP2P/DHlTzwk6yfuqJ7f8tzuMiPcy utvxo/9QxwfccKN6KPsytjksFu89GL9dVfy1Q4Gzkx+BCqulO9 hzjZ4al8q4DK6bp1njsMLP+3H3YqZIQC1rBUy9mB5Lg6fwgC7R IyIxonfDfkfWK3gkHnAmukMwDffRz3ItbTPsphDt8m//qP2B3b CDexvCpjT0l74worWQdtSLtqDLYeLupA9UNkr5LJuMEe+EjFr6 XkV+zM+p0SuLhxvYpIS3acPpwM5MbrPNQxh7mAm4Bhcknb2dbe FurF+R2hcLyzLtVGNYb8ZUzyUdCaVkDDyb+mu67h1pLU27hosi rof202732SszomxW8vKxJMcCvki8QIoxF0y0hzzMiyLONQzDYi j3hVN
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, 28 Oct 2014 12:55:05 -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
> > connection.

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

Normally, yes (after all, TLS_FALLBACK_SCSV isn't expected to be seen *at
all* as long as everything works well). The kind of scenario I'm thinking
of is one with clients on bad wireless networks, which can lead to rather
frequent spurious handshake failures followed by (inappropriate) fallback
retries.  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.

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, 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.

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 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,

You have the fatal alert telling you that the current protocol version with
TLS_FALLBACK_SCSV wasn't right.

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

You can basically do the same thing with the TLS_FALLBACK_SCSV mechanism,
it just may require an additional connection.

Fallback retries always *are* a kludge, hence I want to keep the
TLS_FALLBACK_SCSV mechanism very simple and easy to support rather than
optimizing for special scenarios.