IETF Logo Mail Archive

Re: [TLS] Deprecating alert levels

Kyle Nekritz <knekritz@fb.com> Mon, 17 October 2016 17:34 UTC

Return-Path: <prvs=9098a1fb4e=knekritz@fb.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83273129976 for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 10:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=YiD29ykv; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=R5tcdLn2
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 UtvHNOpCkDeI for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 10:34:11 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E3A129975 for <tls@ietf.org>; Mon, 17 Oct 2016 10:34:10 -0700 (PDT)
Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9HHUOMl001367; Mon, 17 Oct 2016 10:34:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=JXFh1diKTY3uBhW3ndkooCIY8uPciwJDVvnJdHj1oug=; b=YiD29ykv+mMJa7p42yB/uT0oP0x5TtbMygTAKnJ6Tklvn78wWDVMH+pDHAeG4x3Y+9w4 a1KzL3p6rlOkx0UnixrJ9gEiqSQOfawci7OJ+vWqOm6PXQpbIQlvdh8ByR1/VjmMYROC jf6YpSSnRv72Wj8CwrtiarfkCwG2F9FrqtI=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2650pxu0sj-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Oct 2016 10:34:10 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 17 Oct 2016 13:34:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JXFh1diKTY3uBhW3ndkooCIY8uPciwJDVvnJdHj1oug=; b=R5tcdLn2DIf5GBnYuFbz7XEIdPReKjJR+BvCvMBlYZy+y/0xdkCTUXwm5KvrWTANBbbxGOI8zQbg2n3+oG5I5RstZdMm3+sBUj8eg6iWspq3qj7tn1yGyMUvH3up2eZCu12p+o5OXYZGhkVwOmW5BdQXB3DsqiBXTv92kwDMkkY=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1183.namprd15.prod.outlook.com (10.175.2.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 17:34:06 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0659.025; Mon, 17 Oct 2016 17:34:05 +0000
From: Kyle Nekritz <knekritz@fb.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] Deprecating alert levels
Thread-Index: AdImXnNSskDkr/RBRyKiMCb2wmhMDwBNKucAADz34cA=
Date: Mon, 17 Oct 2016 17:34:05 +0000
Message-ID: <MWHPR15MB11829BF852A21F2E9C2B99B6AFD00@MWHPR15MB1182.namprd15.prod.outlook.com>
References: <MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0@MWHPR15MB1182.namprd15.prod.outlook.com> <CABkgnnUDPobAqmQFu+H_2btFgi1s8CGUW_anxSpssu31rp-V1g@mail.gmail.com>
In-Reply-To: <CABkgnnUDPobAqmQFu+H_2btFgi1s8CGUW_anxSpssu31rp-V1g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c091:200::7:61b1]
x-ms-office365-filtering-correlation-id: 1f4af97a-4cec-4bf5-acf0-08d3f6b3cb47
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1183; 20:T4zo+sk/Muj+iOA6XXEznGtP4KIjxCqfzqSvqYL/mX6tQZgkf+fswaCwYxat+Gsp+8K6jmzw/inJEXAhIS2uvKvmzYL7rGKEyjhF2x+rnacJ0ZPKHY+XtGlpkFY++tQrsMwwS8KfEoxksIvB1MEz9thX8thEtL6Z3vmFVb2AR/c=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1183;
x-microsoft-antispam-prvs: <MWHPR15MB11838344575DDB6EA01B861CAFD00@MWHPR15MB1183.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(67672495146484);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:MWHPR15MB1183; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1183;
x-forefront-prvs: 0098BA6C6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(13464003)(24454002)(2900100001)(77096005)(15975445007)(3660700001)(76576001)(15650500001)(10400500002)(5002640100001)(122556002)(92566002)(305945005)(6916009)(110136003)(7696004)(74316002)(5660300001)(87936001)(68736007)(8936002)(105586002)(99286002)(19580395003)(19580405001)(106356001)(7846002)(2950100002)(2906002)(4326007)(50986999)(76176999)(7736002)(3280700002)(54356999)(9686002)(81156014)(81166006)(8676002)(6116002)(86362001)(575784001)(97736004)(189998001)(101416001)(586003)(102836003)(33656002)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1183; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 17:34:05.7000 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1183
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-17_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/56lKruCYiW05Sy4H_ssJkqG9gdI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating alert levels
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 17 Oct 2016 17:34:12 -0000

> You are suggesting that end_of_early_data and close_notify will be marked "fatal".

Yes, technically they would have no alert level (since alert level is deprecated), but as far as bytes on the wire changes with this PR, that's correct.

> could you expand on why it's a problem?

Alert level is not conveying any additional information since there is one (and only one) alert level each alert type must be sent as. Having a separate field that does not convey additional information is only providing an opportunity for implementations to misuse it and create subtle bugs (for example if one implementation ignores warning level alerts, while another incorrectly sends alerts defined as fatal at warning level).

> This list is already missing the warning-level "unrecognized_name" alert, and such a change would imply that all new/unrecognized alerts are going to be treated as fatal forever (i.e. that no new warning-level alerts can ever be defined).

That alert is currently defined as a fatal alert (see section 6.2 in the current draft). RFC 6066 also states "It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable.", which I think illustrates the problem. Allowing new non-fatal alerts to be added later would require that existing clients ignore unknown warning alerts, which I think is somewhat dangerous.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Sunday, October 16, 2016 5:53 AM
To: Kyle Nekritz <knekritz@fb.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating alert levels

I'm sympathetic to this, but just to be clear...

You are suggesting that end_of_early_data and close_notify will be marked "fatal".

WFM.

On 15 October 2016 at 08:07, Kyle Nekritz <knekritz@fb.com> wrote:
> After PR #625 all alerts are required to be sent with fatal AlertLevel 
> except for close_notify, end_of_early_data, and user_canceled. Since 
> those three alerts all have separate specified behavior, the 
> AlertLevel field is not serving much purpose, other than providing 
> potential for misuse. We
> (Facebook) currently receive a number of alerts at incorrect levels 
> from clients (internal_error warning alerts, etc.). I propose 
> deprecating this field to simplify implementations and require that any misuse be ignored.
>
>
>
> PR: https://github.com/tlswg/tls13-spec/pull/693
>
>
>
> Kyle
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_tls&d=DQIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2
> z7jPw&m=D6vgejwavMxoWSed2ANWwkecWIlc1MnHfgXfiejFS8Y&s=-fFwoxaS4TZXNkoZ
> M04oEUCKz283dy6QYRuhlOK0mQo&e=
>

v2.23.0 | Report a Bug | By Email