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

Dave Garrett <davemgarrett@gmail.com> Thu, 17 September 2015 23:09 UTC

Return-Path: <davemgarrett@gmail.com>
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 131F51A8547 for <tls@ietfa.amsl.com>; Thu, 17 Sep 2015 16:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 m4ybyChaTFsO for <tls@ietfa.amsl.com>; Thu, 17 Sep 2015 16:09:57 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 4B41D1A802A for <tls@ietf.org>; Thu, 17 Sep 2015 16:09:57 -0700 (PDT)
Received: by qkcf65 with SMTP id f65so13162079qkc.3 for <tls@ietf.org>; Thu, 17 Sep 2015 16:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=ahxjOw3c0XE82IyS90unqp1Z/h63jCfBmUlG9VQ6zrE=; b=UEGHl1MBVlfwKOsPGp9eWTz0XahRk6OrpXbjesKSh87d6MQF/k3tCG5hHvLCQivrGG HXQd76OXl53v4ObzsdCidLYomcWO7Vi++mkpGWHPmdkqRDeYd5rknPP/UWk0oMQ/xryg Kp7oXG5m11HELZgMlmIvQEM4kq4QcYArK3YaGQz0Ofl3HFP9+jSJ9EbHZPr/KpadVi0c P2Tlh64gZx75pT3BthaRAk5FD9NtD5Kb9dAIam1tDVY4lkFEhMj+S46T+UEcCqoYJo2Y LtVjp/ajnRkH4hN1G7TfeBtMsGCLPIRB0HlykmsFBB9zkzzouzjt60L0AwbsqeGvCPHa fMqw==
X-Received: by 10.55.17.129 with SMTP id 1mr3146842qkr.25.1442531396497; Thu, 17 Sep 2015 16:09:56 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id f92sm2312170qgf.3.2015.09.17.16.09.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Sep 2015 16:09:55 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, Nico Williams <nico@cryptonector.com>, Brian Smith <brian@briansmith.org>
Date: Thu, 17 Sep 2015 19:09:53 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CABcZeBPnO4zn_HkvwLpLC+EVYN8EKOBEsR80oRt3HZgsiNGDoQ@mail.gmail.com> <CAFewVt6JAY20iXGZhufFRHSUrs5kVzP_CO2VmR5c1vaM-D_KZQ@mail.gmail.com> <20150917205004.GW13294@localhost>
In-Reply-To: <20150917205004.GW13294@localhost>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201509171909.53981.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_XTzxgDhBvSxU3lh_fsGCs9q_YI>
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 23:09:59 -0000

On Thursday, September 17, 2015 04:50:06 pm Nico Williams wrote:
> Do we think that silent connection closings wouldn't also lead to
> version fallback?
> 
> "Let's try this.  Nope, didn't work.  Let's try this other thing...
> Nope, didn't work.  ..."
[...]
> I hope the browsers won't implement reconnect version fallbacks again,
> ever.

The unfortunate truth, is that once any fuzziness is allowed, everyone has to become fuzzy to adapt. The one browser that uses an insecure fallback is the one people says "works", and everyone else is "broken". Vendors do not have the strength to resist this.

Also, this is all a confusing mess. Nobody can say with a straight face that this is clean and straightforward. We'd need to make a new protocol to try that. Version fallback needs SCSV to be safe (which I forgot to mention in a previous email), the session hash extension is needed to avoid certain MitM, there's a renegotiation fix extension... if we want to get this working at all, we need the information feedback to react to. This cannot be improved to an ideal state. TLS MUST be replaced at some point if we want to make things better here.

To note again, because this thread is also now a bit of a mess, I'm not entirely against the notion of restricting what alerts _clients_ send. That's a related but different matter, as far as I'm concerned. To work in this current environment, though, servers need to report proper errors for anyone to attempt to work without expecting developers to resort to unsafe kludges really quickly. They shouldn't, but we know they do.


Dave