Re: [TLS] PR#625: Change alert requirements

mrex@sap.com (Martin Rex) Wed, 07 September 2016 20:42 UTC

Return-Path: <mrex@sap.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 1422F12B2BB for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 13:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 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, 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 gLp1DU6PFc9d for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 13:42:26 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E5D12B213 for <tls@ietf.org>; Wed, 7 Sep 2016 13:42:26 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3sTwPr1jfsz1Hm7; Wed, 7 Sep 2016 22:42:24 +0200 (CEST)
X-purgate-ID: 152705::1473280944-000046BC-75E7C0C4/0/0
X-purgate-size: 1468
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3sTwPq4vZRzksV4; Wed, 7 Sep 2016 22:42:23 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A10D61A54F; Wed, 7 Sep 2016 22:42:23 +0200 (CEST)
In-Reply-To: <cf508e03511947a898e98eb3c273f780@usma1ex-dag1mb1.msg.corp.akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Wed, 7 Sep 2016 22:42:23 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160907204223.A10D61A54F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iFU563oAI_5neAx5JHNl_i0NWZI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR#625: Change alert requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 07 Sep 2016 20:42:28 -0000

Salz, Rich wrote:
>
> I've been reading this.
> 
> I think we should get rid of the "abort" concept.  There's a clean
> shutdown and there's everything else which is an abrupt or unclean
> closing of the connection.  The "send alert" and "close connection"
> concepts are separable and I think we should do that.
> 
> I think writing things this way will make it more clear.
> And then we can bikeshed over which alerts are MAY MUST SHOULD,
> knowing all along that ECONNRESET means the other side gave up.

For TLS handshake failures, the presence of Alerts on-the-wire can
significantly facilitate troubleshooting.

For terminating application data flows after successful TLS handshakes
an ECONNRESET may actually be preferable to graceful TLS closure alerts
in certain scenarios (but this means that applications will have to
perform proper application-level end-of-data signaling).

If the backend uses a multi-tier architecture (such as a reverse proxy
in a DMZ), then its easier to notice (and process) ECONNRESET than
a TLS closure alert, and cancel processing of the active request
in the backend.

This becomes even more important when the stupid idea of hiding the
content type is not removed from TLSv1.3/TLSv2.0.  Recognizing
ECONNRESET is trivial.  Peeking and recognizing a pending TLS Alert
is doable in TLS up to v1.2, but this is going to be a royal PITA
in an Alert-ContentType-concealing TLSv1.3/TLSv2.0.


-Martin