IETF Logo Mail Archive

Re: [TLS] new error alerts?

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 24 July 2015 23:26 UTC

Return-Path: <Andrei.Popov@microsoft.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 6651F1ACECB for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 16:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 LurwleIbhSnL for <tls@ietfa.amsl.com>; Fri, 24 Jul 2015 16:26:37 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EEB61ACE94 for <tls@ietf.org>; Fri, 24 Jul 2015 16:26:37 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 23:26:19 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Fri, 24 Jul 2015 23:26:19 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Dave Garrett <davemgarrett@gmail.com>
Thread-Topic: [TLS] new error alerts?
Thread-Index: AQHQxZ/bGudh2TqShEeKMw5Vn1emwZ3p6+uQgAAmpoCAAAhMIIAAseCAgAB2viA=
Date: Fri, 24 Jul 2015 23:26:18 +0000
Message-ID: <BLUPR03MB1396E0A79CD4D83C6EF2FF6D8C810@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <201507222139.46391.davemgarrett@gmail.com> <201507240109.25969.davemgarrett@gmail.com> <BLUPR03MB139601B70F3BA143B15296178C810@BLUPR03MB1396.namprd03.prod.outlook.com> <201507241215.46209.davemgarrett@gmail.com>
In-Reply-To: <201507241215.46209.davemgarrett@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [85.70.249.143]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:bjDsVWSPde64TcgIcnPhYGLTFkrG5+lmEKyMLMQEniWQf2x3GttmMAKbn/Uh7UJ2W1wMX4tWNrtP/mKo61buwxJuUiMIyHD4YSF6Qsn57aCWlw/JZ7WqchpeQTK+jP0mLtTnPsvqJbC/+cBNzMZRWA==; 24:euByTTiTvM7ecccFPm0ZGtGafbp8o4W16LLFZTeLDeMIGjRRkRjJuruf2Ux0mMuZrPORpfiLhez/dI2Co9H1X8r0c1bkke+N0YWnQvqTDeM=; 20:VBdkm9S/l0nnzXLaYzJZ/b/v3uO3mmXS0PvPiWtHNjsa7+yATlTqqPDKCrG3feAm3Qv/CUz/2y5RYehYjJYEYA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <BLUPR03MB13966965B0029F8EA2615B5C8C810@BLUPR03MB1396.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396;
x-forefront-prvs: 0647963F84
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(54356999)(77156002)(106116001)(93886004)(77096005)(102836002)(189998001)(99286002)(66066001)(5002640100001)(33656002)(76176999)(5003600100002)(110136002)(87936001)(2950100001)(46102003)(5001920100001)(2656002)(5001960100002)(19580405001)(76576001)(122556002)(19580395003)(10090500001)(1411001)(50986999)(86362001)(40100003)(92566002)(74316001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 23:26:18.9478 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ROM6qgV7gMP0RAMMQ0FsCSPbXH8>
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 23:26:39 -0000

Yes, this sounds good to me too.

Cheers,

Andrei

-----Original Message-----
From: Dave Garrett [mailto:davemgarrett@gmail.com] 
Sent: Friday, July 24, 2015 6:16 PM
To: Andrei Popov
Cc: Eric Rescorla; tls@ietf.org
Subject: Re: [TLS] new error alerts?

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

v2.23.0 | Report a Bug | By Email