IETF Logo Mail Archive

Re: [TLS] Deprecating alert levels

Benjamin Kaduk <bkaduk@akamai.com> Mon, 17 October 2016 16:11 UTC

Return-Path: <bkaduk@akamai.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 AB2571295EA for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 09:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Level:
X-Spam-Status: No, score=-3.131 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 AkrHfBbiUi5t for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 09:11:45 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 98BB8129538 for <tls@ietf.org>; Mon, 17 Oct 2016 09:11:45 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8032E423706; Mon, 17 Oct 2016 16:11:44 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 53602423705; Mon, 17 Oct 2016 16:11:44 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476720704; bh=/8WPuEAPeR1NcKSLLpl3DssWK4eX/cBn4QSuBN254Vs=; l=2402; h=To:References:From:Date:In-Reply-To:From; b=tY9pfs7Ati8/crGPCEddyOHOWYZuvD6kRs5mLfnrUj43+oG1WQnT88e5iywtbfBjO VoyWtU9ZNZ5U6+BZuTsIKlABesEXExWBOsvPh+Lnz9/g2OG1nxWJRfsSQbbrTsKGU+ eL7TqMKi8xVGwOmb3+8646qQA5rCOYyvq2XwbEbY=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1C8A61FC88; Mon, 17 Oct 2016 16:11:44 +0000 (GMT)
To: Hubert Kario <hkario@redhat.com>, tls@ietf.org
References: <MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0@MWHPR15MB1182.namprd15.prod.outlook.com> <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com>
Date: Mon, 17 Oct 2016 11:11:43 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com>
Content-Type: multipart/alternative; boundary="------------593E7E0532312EDA3BA768B8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WwZHjdCAqYrx5Yhc-xFoTNMjvQQ>
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 16:11:46 -0000

On 10/17/2016 06:20 AM, Hubert Kario wrote:
> On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz 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.).
> could you expand on why it's a problem?
>

Why what is a problem?

My understanding is that at present, the AlertLevel is not reliable
(that is, some noticeable fraction of clients send nonsense) and so the
change in PR 693 is merely documenting existing best practice.

-Ben

v2.23.0 | Report a Bug | By Email