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
- [TLS] Deprecating alert levels Kyle Nekritz
- Re: [TLS] Deprecating alert levels Martin Thomson
- Re: [TLS] Deprecating alert levels Eric Rescorla
- Re: [TLS] Deprecating alert levels Hubert Kario
- Re: [TLS] Deprecating alert levels Benjamin Kaduk
- Re: [TLS] Deprecating alert levels Hubert Kario
- Re: [TLS] Deprecating alert levels Eric Rescorla
- Re: [TLS] Deprecating alert levels Martin Rex
- Re: [TLS] Deprecating alert levels Dave Garrett
- Re: [TLS] Deprecating alert levels Kyle Nekritz
- Re: [TLS] Deprecating alert levels David Benjamin
- Re: [TLS] Deprecating alert levels Hubert Kario
- Re: [TLS] Deprecating alert levels Hubert Kario
- Re: [TLS] Deprecating alert levels Martin Rex
- Re: [TLS] Deprecating alert levels Joseph Salowey
- Re: [TLS] Deprecating alert levels Eric Rescorla
- Re: [TLS] Deprecating alert levels Martin Thomson
- Re: [TLS] Deprecating alert levels Martin Thomson
- Re: [TLS] Deprecating alert levels Kyle Nekritz
- Re: [TLS] Deprecating alert levels Olivier Levillain