Re: [TLS] new error alerts?

Andrei Popov <> Fri, 24 July 2015 02:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9A43E1ACED8 for <>; Thu, 23 Jul 2015 19:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uhQ3DCuEklrJ for <>; Thu, 23 Jul 2015 19:53:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 374411B29DD for <>; Thu, 23 Jul 2015 19:53:01 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 24 Jul 2015 02:52:59 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T5J7JnBYLJmb0I7ztwIqUO1Z7Na2N7ahNbH01TWYvd0=; b=oCq6X9A3OcKeytBvuaKxm3bsBUUfGCE56LxKGoTLtjpO3UPnXCFNT3Rsdx4kfy1HbOaXp1pT7fK5s3BcBCr5aKUHCrAJLkUNVXxByJsat37lfluiMRN7yNod75WisqURUHPv1TIiaEPErftRtQkInBLRv907XRQFJ2tWQL1zmUw=
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 24 Jul 2015 02:52:59 +0000
Received: from ([]) by ([]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 02:52:59 +0000
From: Andrei Popov <>
To: Eric Rescorla <>, Dave Garrett <>
Thread-Topic: [TLS] new error alerts?
Thread-Index: AQHQxZ/bGudh2TqShEeKMw5Vn1emwZ3p6+uQ
Date: Fri, 24 Jul 2015 02:52:59 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:6yK7KJ+i0dhguhtAOn0DJpCY2zVgP6qj/KIl7N9nj0dFje+UfqD8T25t0+aAJ3lqK+rGmr5/SWbmduHAnYVUWUl7JPGlcns5gylG/k050wBDEWpcvMVRBe+21BXQgffCYMDl8t68ZrS1eLw4NdnxyA==; 24:sVu8GRZXCQmpUHMqoDinGN8VOLib/RPS6hPBL9ScvV46c5ptFXQ3LG1YL+kcr/DMFRe0VDcbrEPSaqaTYzK7O4d5iisuMrU4/Zq9oDnJr7Q=; 20:ht2YDs0xt5TFk2UtvLc/VE0WUpyZpUiUL+26pMnWnoaeeADVKRJUTHe+CtF3YSkW/uNBc9nB3LqEcBoz4Hr9BQ==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB183;
blupr03mb1393: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393;
x-forefront-prvs: 0647963F84
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(19580395003)(19625215002)(50986999)(54356999)(5003600100002)(76576001)(19300405004)(40100003)(16236675004)(77156002)(33656002)(19617315012)(19580405001)(76176999)(7110500001)(2900100001)(86362001)(189998001)(92566002)(2950100001)(5001770100001)(15975445007)(74316001)(106116001)(5001920100001)(2420400003)(19609705001)(102836002)(2656002)(77096005)(66066001)(5002640100001)(5001960100002)(87936001)(99286002)(10090500001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396750B52053B7AEFF418B68C810BLUPR03MB1396namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 02:52:59.8788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB183; 2:wpM+QbFf7KgIrkc4JFiNZqw7hDckahuyeW8bhiD8KgDu4VEcFRqZ6f/nL4pEWOsRsQbe32QmIkOInjI+WjvyHk0Nh+/z3TNgLcptOCI7FSiqVSkg8oo5jX/iqx/Gvm4hvV04WL1pvywF0g3NRL80CLse1l8rBg96M9UxoGj6ycY=; 3:I5HKZysmMWOGGqgvSZpEbEUdG9P+F3EyTlqiu+BGs6O43xCpY211Puv6lSNsCNNROzq+DbQJO1QKlJI924HsVzuw9u1ym2haP55zRR15okUMBk2OUy2AVc6el/Ho0OAzKbeeef4KX2zhQdH8ToH+jA==; 25:aSBR2PYndqtutB8AilvQATTvYtpuKt59lD/TF68cztWjUo3xotgSsKwKTif/+Sdf+26iiw4pHGOzDVtGa/PAPvGK/ko9QI1cSHZ8uXqtc6r1qxYjwNDzEYHibLkm+6E9iaeWivWm7RpC6gx4sCkACgAY65Ekw4ZrqofLxhiDHSxSV21cjaQ3yNkqp+Hy/SSjIbACTmVc9aN/pIBYDM0CXhFXj+PN+iy1T6MAhPuUT7z18aG6MsJjPYsvamaUdwDbLksCAp7mx5W/z9UZ/8D9mA==
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB183; 20:I7N5XzfyNiStTL9gRjob9HgHaN+XwmQdJSkSfH/AhAXgQ5SXU6FEWUCzAjCASW34eg58gn4kw7fSRF2/qzB78HJIpRtNU9XmVlq9CB09aOqxWHX3fFuBN0ofvTwNckrt1mo8pje1j0sDkOs/8krDZRdoGRie0OOLcGY2B8BJdgyR2OyjFmGNGK73RLHNbck7i6M/Js43xH+rDwDpoZLu1IhkZVMZkulqxvWmsDKfsPhGWWvWRtcDUf484OgZrpJ71tqy+VP7Y/Btal04ja96rvY+N53DOuLZqjtD3fIqGRs/xwHvqRzJlkigL1uIkbcp5YlxjCvBW7QvQH0ZQqiG9kVYRiEKfBmT/Wbn++kjHw8onOYN/nqt0fKE0KBwMZSyxgAIG8HmBSmQj64WVfoc1iyeErgPtxkVMFGqdOWj6KCREFh+NVulbtan2LRfSeM9lG8hExnmr1cjSd9Pnk3KsDpkXg09HEu5ktJWd0z2JjHZ+oS6tCJ2SK+JksuYyxSN; 23:MSuWALtWyNPwQ9LCeKNeUOxc8ztI5jjTTz7/D5yNzoBz3bl/lALNHzGE+cFDtn+tcrea96SKz/887xdknp8rHpHE2fIZDSp+NkpWQuSI/EqHYMC0CvkmUSPO3T5XM/5Onkz36fAb+qQXeHCOZ282xJNN9pZTIplqGT4V92R4NV60gNMm/PxmVk56scbIoWLP
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] new error alerts?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2015 02:53:07 -0000

Rather than renaming and otherwise modifying the meaning of the existing alerts, would it be better to define new, more granular alerts in 1.3? We can’t ascribe new meanings to alerts generated by the code we’ve shipped in the past.

From: TLS [] On Behalf Of Eric Rescorla
Sent: Friday, July 24, 2015 1:32 AM
To: Dave Garrett
Subject: Re: [TLS] new error alerts?

It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.


On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett <<>> wrote:
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. ;)

TLS mailing list<>