Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

mrex@sap.com (Martin Rex) Thu, 03 November 2016 14:31 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 E9E73129A70 for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 07:31:57 -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 SVF-DH8VGJZX for <tls@ietfa.amsl.com>; Thu, 3 Nov 2016 07:31:55 -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 0A9DB129A71 for <tls@ietf.org>; Thu, 3 Nov 2016 07:31:29 -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 3t8nTW03CMz1J9S; Thu, 3 Nov 2016 15:31:27 +0100 (CET)
X-purgate-ID: 152705::1478183487-00002B31-8339C362/0/0
X-purgate-size: 1984
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 3t8nTV3y1vzl09h; Thu, 3 Nov 2016 15:31:26 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 7B0F71A576; Thu, 3 Nov 2016 15:31:26 +0100 (CET)
In-Reply-To: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Thu, 3 Nov 2016 15:31:26 +0100 (CET)
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: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/25g_cHgswHCcwbf2qCNZ5T9s3yM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Thu, 03 Nov 2016 14:31:58 -0000

Ilari Liusvaara wrote:
>>> 
>>> Hiding the types does have its benefits (and it is also used for
>>> zero-overhead padding scheme).
>> 
>> Nope, ZERO benefits.  But it totally breaks the middleware
>> _at_the_endpoints_!
> 
> Also, things like this should have been discussed like year or two
> ago. Right now it is too late for major changes like this without good
> cryptographic justifications (which AFAICT don't exist).

They WERE brought up back then, and several times in between.
But the TLSv1.3 proposal has still not been fixed so far.
Ignorance does not make problems go away.  Instead, it means that
one will have to fix it later.


Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
which has existed through SSLv3->TLSv1.2 would be a problem.  With the
removal of renegotiation from TLSv1.3, it is even less of a problem to
keep the contenttype in the clear.

The removal of visibility of ContentType in TLSv1.3 will be a complete
non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain
software architectures (including a lot of stuff we've been shipping for the
last 5 years), because it is actively being used to signal state of
the communication channel to the application and to *NOT* break application
architecture that relies on (new) application data remaining visible on
network sockets as "network readable" events.



https://www.ietf.org/mail-archive/web/tls/current/msg13085.html

https://www.ietf.org/mail-archive/web/tls/current/msg13106.html


A similar issue exists for the visibility of Alert ContentTypes
for efficiently detecting client-side connection closure.
This has been described here:

https://www.ietf.org/mail-archive/web/tls/current/msg21123.html


The IETF technical leadership is supposed to prevent backwards-incompatible
changes to be adopted and standardized that provide *ZERO* benefit,
but severely impair interop and consumption.


-Martin