Re: [TLS] Deprecating alert levels

Hubert Kario <hkario@redhat.com> Mon, 17 October 2016 16:19 UTC

Return-Path: <hkario@redhat.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 86ABE1298AF for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 09:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.353
X-Spam-Level:
X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 CatNVV3HIbs2 for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 09:19:27 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752801298A9 for <tls@ietf.org>; Mon, 17 Oct 2016 09:19:27 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2AD737F3F5; Mon, 17 Oct 2016 16:19:27 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HGJPbM015473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 12:19:26 -0400
From: Hubert Kario <hkario@redhat.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Date: Mon, 17 Oct 2016 18:19:25 +0200
Message-ID: <2433245.jcFcMeBmYW@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com>
References: <MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0@MWHPR15MB1182.namprd15.prod.outlook.com> <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com> <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6937391.kOs8xvOqXM"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 17 Oct 2016 16:19:27 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qEyluR8LKXffMW1M4b0wEJH5rU0>
Cc: 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 16:19:29 -0000

On Monday, 17 October 2016 11:11:43 CEST Benjamin Kaduk wrote:
> 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?

clients sending incorrect levels for the description they send
 
> 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.

the current draft says that any alert except the three defined as warning 
level must be considered fatal and cause connection closure

I don't see how deprecating the field changes anything - the implementations 
won't need to behave differently and data on the wire won't be different

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic