[TLS] PR#625: Change alert requirements
Eric Rescorla <ekr@rtfm.com> Mon, 05 September 2016 18:03 UTC
Return-Path: <ekr@rtfm.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 0D07C12B271 for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 11:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 NMzvX217Arwq for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 11:03:39 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF8112B0B5 for <tls@ietf.org>; Mon, 5 Sep 2016 11:03:39 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l8so42341025ywb.0 for <tls@ietf.org>; Mon, 05 Sep 2016 11:03:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NBxd5yKLz+A/5mXhWnASkk1N/AlQj5zC1SaauXi9Zpc=; b=wTZk/OjnzTxStf5YQOn0+VJ0lHqB2NWPSKZA5m/9bte0dPz00Lp0NeIydh5MRC11y3 hpIUak6WbPXm/f5Zw5ssK9EkcJ9GScyQ+Tcrd+FIJ0wmvst9JN3KQ1ewpwPiykm0jhdO UbkNXmyo+ejLHDJ453HE4LaByyiK501Mft4d12wWqv8BF5g7zTgKjjpXcu/B8stshUNx zsbtyqlO63VsQNkaAsQMVYIvqepObXZ5ESctp6Mg1V0GrE+m6C93LjJ2YDwjMTSPLfwO DX8dbtdqwKilAlelubMOxU6sxqAXEHwGgDlxXX45AukxxGsXHJS/X9DqgMIvG5josaai spqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NBxd5yKLz+A/5mXhWnASkk1N/AlQj5zC1SaauXi9Zpc=; b=mwAQNrNVLGP+TQUiNImpSlqdjDtAEORc4TLOz32jq566KYhJcTl1Su0v3U2BIBeMy/ 9n+EZUIf4PKSWQdrk6Va4R/CLNB/Cb6Qm9JjMFAheURKKi8V0M9sbku/bvya0pbTqO14 Gv/lEaVvrXN0ErMwZgvIC2UoIy8IHRTafm4D7jUIRmbVB5Z1uqX67KeGLfOjPbGejlSJ bdcs1afXkUvZQWhM22EtjdnClW+GNAOjzLeCB/ZsmzmF0samTQ6hqAjXO0b8HEm3QJih brqBzslUpR/UA2AIJGtl2eXSnVtwu/JAocGzBHwrFbfIt6HQMRbRiOLsNzg7DZY5289T Jf6g==
X-Gm-Message-State: AE9vXwMCN6ZOJhwNHJ4CT8IfmWiShJLfKWe+wbDmRWBnff1cDkMyn/sbWzfvfVrRN5Pt/UL/gMv0ScE5lFrGpA==
X-Received: by 10.129.39.15 with SMTP id n15mr16038359ywn.16.1473098618225; Mon, 05 Sep 2016 11:03:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.48.193 with HTTP; Mon, 5 Sep 2016 11:02:57 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 05 Sep 2016 11:02:57 -0700
Message-ID: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11408d48dc006a053bc67f0f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6Hw2Ie0r3vi14Ijl1rht4vONQXA>
Subject: [TLS] PR#625: Change alert requirements
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, 05 Sep 2016 18:03:41 -0000
PR: https://github.com/tlswg/tls13-spec/pull/625 Currently the TLS spec requires implementations to send alerts under various fatal conditions. However, many stacks actually don't send alerts but instead just terminate the connection. Several people have argued that we should relax the requirement. At the September 2015 interim there was consensus to instead encourage sending alerts and require that if you send an alert, you send a specific one. I've finally gotten around to producing a PR that does this (link above). This PR: - Harmonizes all the language around alert sending (though perhaps I missed a couple of places) - Tries to make which alerts to send clearer in the alert descriptions to avoid having to specify individually how to handle every decision. - Relaxes the requirement as listed above. Note that these are to some extent orthogonal changes; even if we decide to continue mandating sending alerts, that should be listed in one location not scattered around the spec. I know that there wasn't universal consensus on relaxing the requirement to send, so I'll await WG discussion and the chairs decision on how to handle this PR. -Ekr
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz