[TLS] Issue 472: Remove non-closure warning alerts

Eric Rescorla <ekr@rtfm.com> Sat, 09 July 2016 12:49 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 8EA2912D107 for <tls@ietfa.amsl.com>; Sat, 9 Jul 2016 05:49:55 -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 yZvJWAq7N1xN for <tls@ietfa.amsl.com>; Sat, 9 Jul 2016 05:49:54 -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 EB09C12D0DE for <tls@ietf.org>; Sat, 9 Jul 2016 05:49:53 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l125so57824104ywb.2 for <tls@ietf.org>; Sat, 09 Jul 2016 05:49:53 -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=ixvZ0S3rly5Zpeq+LAjvCz/U4KEszBcwPzwSezMj6KU=; b=INh8R7kloGWegijer9u2FN3bqOdiaFkaUZLtnL+KspWut5louXlIW1rafaKylk6xFD tzyO+DI1mmDR7BcEdHsuAp3+Y0M35OHL7VobHd4Iz6ol53E66ezwPyev5OmV9ZKrhBeX /AB97FM6Unu4cWd+bKbLwNF0MDlmkUKdQo65OSgsmqZKmRGdafsWOfITckWu/xPYndYO x64uD7iO0kgB71PO4Kj9HvEKb6p4C/JnOPY0ImNqZG0qPxpLIdMAXyNbky/KR0ITzQBV 6ldhUiceEKkyXKfeV7sipMLaYeOA23OSpiOcuOivQpHlsqHIuD/ay+Zwekq2UCoDGz/+ cZfA==
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=ixvZ0S3rly5Zpeq+LAjvCz/U4KEszBcwPzwSezMj6KU=; b=VQ1gy9AMc25hDF5VMYKz1ojocWbilWLvIs2YwOXRxjmcmGJcA4EiHCnX06t2yDTQHX 9pC3XB/b2KhDEoz0qGjXjNlBrRIJlOHzkW0PRtqheAl3oVHBj+p0SRycdD69j59T74QL wSxRFFjqAdPK6Q+Q3EiwoO0k/XCK31sQGsW+IUaR15rsql86Oa2DDFMU1Q47aeij7Oan EkQU6I+GZTOo+IHM7ThlDexi+EkI1UNWn13CUY9fSTNcVwc05n5PCp1Gd/DqmMbmK7X6 /3TDdoIyIddM5IMGIzhOmybicdJhRCia3WW/sJZWhC3NhMwKbTLwczw1KMRV2gZ0ol+C fkMQ==
X-Gm-Message-State: ALyK8tJ5hjelsi2gaspOkC51hO9LOQAKMn0hSBdbPU04h3CcikCpchPdz4I5rQ3wMbSzj3Iam5S8a5KtLNcddw==
X-Received: by 10.37.126.1 with SMTP id z1mr7430542ybc.57.1468068592953; Sat, 09 Jul 2016 05:49:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Sat, 9 Jul 2016 05:49:13 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 09 Jul 2016 05:49:13 -0700
Message-ID: <CABcZeBOMVo=oQ2mReHCLfbP6SjbhCyD2wSEDzidSRX1AYFewLA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e1a46fd7ae90537335a13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0uD9bf2etKagyFEGsi0N3RjnNQo>
Subject: [TLS] Issue 472: Remove non-closure warning alerts
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: Sat, 09 Jul 2016 12:49:55 -0000

In general, TLS stacks handle warning alerts badly aside from the defined
alerts
that are explicitly non-fatal ("close_notify", etc.). Many just close the
connection
so it's not safe to send one.

I would suggest that we instead adopt the following semantic:

- All alerts mean connection close.
- Fatal means that you should report an error to the application
  (e.g., return -1 in a sockets-style API) and abort immediately.
- Warning means that you should report a "normal" end of data
  (e.g., return 0 in a sockets-style API) except in the case of
end_of_early_data
  and in the case of close_notify, send your own close_notify
- Any alerts except the ones specifically listed as "warning" MUST be
treated
  as fatal regardless.

This is more or less what people do anyway.

If people are in favor of this, I will prepare a PR.

-Ekr