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/
- [TLS] Should we require implementations to send a… Eric Rescorla
- Re: [TLS] Should we require implementations to se… Martin Thomson
- Re: [TLS] Should we require implementations to se… Eric Rescorla
- Re: [TLS] Should we require implementations to se… Geoffrey Keating
- Re: [TLS] Should we require implementations to se… Martin Thomson
- Re: [TLS] Should we require implementations to se… Salz, Rich
- Re: [TLS] Should we require implementations to se… Viktor Dukhovni
- Re: [TLS] Should we require implementations to se… Eric Rescorla
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Andrei Popov
- Re: [TLS] Should we require implementations to se… Hanno Böck
- Re: [TLS] Should we require implementations to se… Florian Weimer
- Re: [TLS] Should we require implementations to se… Salz, Rich
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Florian Weimer
- Re: [TLS] Should we require implementations to se… Henrik Grubbström
- Re: [TLS] Should we require implementations to se… Florian Weimer
- Re: [TLS] Should we require implementations to se… Salz, Rich
- Re: [TLS] Should we require implementations to se… Viktor Dukhovni
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Jim Schaad
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Florian Weimer
- Re: [TLS] Should we require implementations to se… Hubert Kario
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Martin Thomson
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Nico Williams
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… David Benjamin
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Martin Rex
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… David Benjamin
- Re: [TLS] Should we require implementations to se… Hubert Kario
- Re: [TLS] Should we require implementations to se… Hubert Kario
- Re: [TLS] Should we require implementations to se… Brian Smith
- Re: [TLS] Should we require implementations to se… Benjamin Kaduk
- Re: [TLS] Should we require implementations to se… Tony Arcieri
- Re: [TLS] Should we require implementations to se… Dave Garrett
- Re: [TLS] Should we require implementations to se… Bill Frantz
- Re: [TLS] Should we require implementations to se… Kurt Roeckx
- Re: [TLS] Should we require implementations to se… Kurt Roeckx
- Re: [TLS] Should we require implementations to se… Viktor Dukhovni
- Re: [TLS] Should we require implementations to se… Hubert Kario
- Re: [TLS] Should we require implementations to se… Hubert Kario