Re: [TLS] Should we require implementations to send alerts?

Brian Smith <brian@briansmith.org> Thu, 17 September 2015 22:37 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2252A1A1BF4 for <tls@ietfa.amsl.com>; Thu, 17 Sep 2015 15:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyuGdLk0Be96 for <tls@ietfa.amsl.com>; Thu, 17 Sep 2015 15:37:30 -0700 (PDT)
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0393F1A01A8 for <tls@ietf.org>; Thu, 17 Sep 2015 15:37:30 -0700 (PDT)
Received: by ioiz6 with SMTP id z6so38323560ioi.2 for <tls@ietf.org>; Thu, 17 Sep 2015 15:37:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Izny7v8xfZjlWPLhNomhIljoOc/uYe3zOft5eBYyAwI=; b=gV4oCBvSUag3nHVn2WimgLVse+TY95h0ODVG3TB4Jm0OukoNYRsgyymOPlNQQ1TiNd BCr/nnG9Ff/sFkvol7bwuMWpgtLljAMZ0eLdBIcK6sKHWmow7PcGt5hI2qTaf8OC1E7J W0i6fbgfhTo+xVZ5vWI0l72xD4AyP5+/4JNXTt8yI/wHx/oeO1eI2gFh5Aa/qrArQjWN AZnl7m0dXfuLS1JZKC/lBJZXrWAOUO2DESHq8UE+qNuB7B/6H8WDa/PY24OyHAW25z+K IviwekFQMEjgVMpP6Z8gmUymeN2Q5MGX557iXQFJ0b4ifrUarIRH4cn2Kj2PwsPo3Zo2 CoGA==
X-Gm-Message-State: ALoCoQnOzTbuR5MA88iZozOxWrD3h+vITxH9717CEDg66Hnxq6LOecuF9eiidCbwWpqKJkc46/as
MIME-Version: 1.0
X-Received: by 10.107.47.221 with SMTP id v90mr10300150iov.185.1442529449453; Thu, 17 Sep 2015 15:37:29 -0700 (PDT)
Received: by 10.79.107.204 with HTTP; Thu, 17 Sep 2015 15:37:29 -0700 (PDT)
In-Reply-To: <201509171815.27842.davemgarrett@gmail.com>
References: <CABcZeBPnO4zn_HkvwLpLC+EVYN8EKOBEsR80oRt3HZgsiNGDoQ@mail.gmail.com> <20150917215515.GY13294@localhost> <CAFewVt5g_+beKQCg4Y+a7b6QcuJSRXcRm+wY+upDYAusJoRa8Q@mail.gmail.com> <201509171815.27842.davemgarrett@gmail.com>
Date: Thu, 17 Sep 2015 15:37:29 -0700
Message-ID: <CAFewVt5bAOihbvfQMAOdHx2Eqnt1gX38sHXUMtYvwOn7iHBAbg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c1508069e899051ff90fdd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fmRRSsURymQ0EbW8ktsv9ZiRDQ4>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Should we require implementations to send alerts?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Sep 2015 22:37:32 -0000

On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote:
> > There's no evidence that the presence or absence of an alert when a
> > connection is closed makes any positive difference in the security of any
> > non-secure fallback mechanism. Keep in mind that the alerts during the
> > handshake are NOT authenticated, and the TLS threat models thus assumes
> > that the attacker can remove or alter them.
>
> The whole handshake is retroactively authenticated upon completion. Just
> because an attacker can muck up the attempt to connect, doesn't mean all
> hope is lost.
>

A fatal alert during the handshake is never authenticated, because (a) the
alert record is the last record sent (i.e. there is no Finished message
sent afterward to authenticate it), and (b) The handshake hashes only cover
Handshake records, not Alert records.


> The primary benefit with the version alert, specifically, is that it
> allows a client to at least have a clue as to what to attempt.
>
> Without alert:
> client tries
> server stares blankly into the void and/or drops abruptly
> now, what does the client do? try again as-is, or try again with old stuff?
>

A conformant TLS 1.3 implementation will not be version intolerant. If the
client does insecure version fallback in response to an alert or connection
close by a conformant TLS 1.3 implementation then it is guaranteed to be
doing the wrong thing.


> Sure, a MitM could try to downgrade by injecting an unauthenticated alert
> into the mix, but the handshake will fail once that is authenticated at the
> end.
>

This is not how the protocol works at all. The alert is unauthenticated,
full stop.

The only time an alert is authenticated is when it is sent after the
Finished message. But then, since such alerts can be triggered by a MitM
who does not have knowledge of the keys, such sending of alerts allows the
MitM to effectively inject known plaintext (the alert record) into the
connection, which runs the risk of facilitating attacks.


> Just as the obvious footnote: it's impossible to make any of this
> resistant to an attacker killing the connection. Just assume that's always
> possible, at minimum with wirecutters. The goal is security or bust. Alerts
> give clients the confidence to actually bust when they have to.
>

In general, the "when to bust" is "always."

Again, there is no such thing as a secure non-secure fallback.

Cheers,
Brian
--
https://briansmith.org/