[TLS] new error alerts?

Dave Garrett <davemgarrett@gmail.com> Thu, 23 July 2015 01:39 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 []) by ietfa.amsl.com (Postfix) with ESMTP id B82881ACD18 for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 18:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 92SMW2B_1aG5 for <tls@ietfa.amsl.com>; Wed, 22 Jul 2015 18:39:50 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 EC3D31ACD12 for <tls@ietf.org>; Wed, 22 Jul 2015 18:39:48 -0700 (PDT)
Received: by qged69 with SMTP id d69so82251024qge.0 for <tls@ietf.org>; Wed, 22 Jul 2015 18:39: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:mime-version:content-type :content-transfer-encoding:message-id; bh=DOrftDIqNyPU8lXSjXJPGap9bdEtsihg2uowvnMQt8I=; b=iEDQc3hmLbm6MzsVja5TCMmANdNZ0+IRTc5NXS+9CIEsx3TWLBKnpw76+lzru8JTMX G+3DCoRcm67BQTtDYK75oClQ3VIpTHcvq5eBHw2W1ypQ0o+L8WOtPMbaWts49chzv8NU 7SFzVFbckOfSrcjJlTQIen6Uq9j7DLuhBof5E3lQXLbfWB3sXxtUDt6ESEiwUhu7C3Ny EikIkhIOhK8fLUurHimSsv3Tedg6rlBWWFFNbzEnDnqK/7HnKTRa7JPkmKOAnQDf0FpH H7RLIOBhx4EA81Uv1GVE8nyDliVUgnAJ1SohjE6sOXzw5uBSdv/D8lNnJaf4UzUKXsyq RSkQ==
X-Received: by with SMTP id j2mr8220290qgj.8.1437615588200; Wed, 22 Jul 2015 18:39:48 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id 137sm1678337qhs.5.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jul 2015 18:39:47 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Wed, 22 Jul 2015 21:39:45 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Message-Id: <201507222139.46391.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/g0RBQBcda7qygozfqDkKZKiwXKA>
Subject: [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: Thu, 23 Jul 2015 01:39:52 -0000

Hubert Kairo found quite a few more spots in need of explicit error designations, which have been amended into PR #201.

I just noticed one error in the current draft text that was wrong and added a fix for that as well. The Server Hello section said that lack of acceptable group would result in an "insufficient_security" error, which is incorrect. That error is clearly defined to be for lack of acceptable cipher suite. The Negotiated Groups section says lack of acceptable group is a “handshake_failure” error. I changed the text to state the error for suites, as the other is already noted elsewhere. (this change is now in PR #201) This brings up a problem, however: there is no distinct error for lack of group support. The “handshake_failure” is a bit of a catchall, so there's no way for a client to really know what's wrong if this happens. This is also why I don't want to change the definition of the "insufficient_security" error. Clients rely on these being relatively precise in order to show error messages that are hopefully meaningful enough to get them fixed. As such, I'd like to propose adding a new error just for this and renaming the old one to focus precisely on its long defined meaning. While we're at it, a failure of client authentication doesn't have its own error alert code either.

  enum {
       unsupported_cipher_suites(71),  /* formerly insufficient_security */
       unsupported_dh_groups(72),  /* new */
       client_authentication_failure(73),  /* new */
   } AlertDescription;

Pretty straightforward. Are there any other errors that can't be clearly identified by the returned code? Debugging shouldn't be guesswork. ;)