Re: [TLS] new error alerts?

Dave Garrett <davemgarrett@gmail.com> Fri, 24 July 2015 16:15 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 449701A037B for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 09:15:55 -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 yqCIzIXBLUDS for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 09:15:54 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 D87621A87C0 for <tls@ietf.org>; Fri, 24 Jul 2015 09:15:48 -0700 (PDT)
Received: by qged69 with SMTP id d69so12904767qge.0 for <tls@ietf.org>; Fri, 24 Jul 2015 09:15:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=BMEzeq4njNwnoZUQM4XXbMni1rETKUHxirgmI4gjqq4=; b=w8sU19bEYDwLwnfpxsMfvksFPvWYPRPUU9V2Td2wpwKVQa+fHttvUfrWozKF6nJFqU C8J0u5rnQSL9SmqysHUVFXA6x0LLP4aJIHPWhrg+0HzSfsZByL0zU6xaE5TSs8SIJCrS XE7TzW08YTmqPu6ELw2S7PXlPr3kgUBQyYJutOoHUapc4af86y6VPoyLmtkjQK5AlDtx uSii3hxQS4X+eJEPTEuChjFsnvDgHK6P8K/1S5RbkLgGS0iIBRWUKx4B3NL7ZjYDsG2h OWAk7yrFw/rQn7an/xE9LbEp5L6fJNuNUHUbo1u1Xqq+4yGnUzp5HKD5BD1wH4vW4DDg YQ+g==
X-Received: by 10.140.131.81 with SMTP id 78mr23181150qhd.70.1437754548044; Fri, 24 Jul 2015 09:15:48 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id c88sm4270859qge.26.2015.07.24.09.15.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 24 Jul 2015 09:15:47 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Fri, 24 Jul 2015 12:15:45 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201507222139.46391.davemgarrett@gmail.com> <201507240109.25969.davemgarrett@gmail.com> <BLUPR03MB139601B70F3BA143B15296178C810@BLUPR03MB1396.namprd03.prod.outlook.com>
In-Reply-To: <BLUPR03MB139601B70F3BA143B15296178C810@BLUPR03MB1396.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201507241215.46209.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3MjdYfDsFKeUgVp3cqPtbyS64k4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] new error 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: Fri, 24 Jul 2015 16:15:55 -0000

On Friday, July 24, 2015 01:50:31 am Andrei Popov wrote:
> > I'm proposing renaming "insufficient_security" to "unsupported_cipher_suites", which is explicitly what it's been for since TLS 1.0.
> 
> Not quite. Insufficient_security alert is defined as follows:
> " Returned instead of handshake_failure when a negotiation has
>    failed specifically because the server requires ciphers more
>    secure than those supported by the client.  This message is always
>    fatal."
> 
> This is a very narrow and specific definition. The server says "I know all the cipher suites the client advertises, and consider them too weak". By contrast, unsupported_cipher_suites means something like "I don't have a cipher suite in common with the client". The latter can happen when the client's cipher suites are more secure than the server's.

Then if we wish to keep this as narrow as written, we can just have a separate one for unsupported with no judgment on strength:

insufficient_security(71),  // unchanged
unsupported_cipher_suites(72),  // new
unsupported_groups(73),  // new
client_authentication_failure(74),  // new

e.g. RC4 gets insufficient_security & Camellia gets unsupported_cipher_suites

Sounds good to me, if we prefer this.


Dave