[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, 5 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