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

mrex@sap.com (Martin Rex) Thu, 10 November 2016 17:13 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 94223129410 for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 09:13:56 -0800 (PST)
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 oIEWJ624nncx for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 09:13:55 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3230A1293F0 for <tls@ietf.org>; Thu, 10 Nov 2016 09:13:55 -0800 (PST)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3tF8lj5JlDz25Nk; Thu, 10 Nov 2016 18:13:53 +0100 (CET)
X-purgate-ID: 152705::1478798033-00003836-432DB077/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 mail07.wdf.sap.corp (Postfix) with ESMTP id 3tF8lj1ycbzGnyV; Thu, 10 Nov 2016 18:13:53 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 37D451A57D; Thu, 10 Nov 2016 18:13:53 +0100 (CET)
In-Reply-To: <58fd43a5-fd20-b93c-fae0-845646a8062f@akamai.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Date: Thu, 10 Nov 2016 18:13:53 +0100
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: <20161110171353.37D451A57D@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UFxEzC2rV9y2CrX9kIUkcRpJjus>
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, 10 Nov 2016 17:13:56 -0000

Benjamin Kaduk wrote:
[ Charset windows-1252 unsupported, converting... ]
> On 11/09/2016 11:42 AM, Martin Rex wrote:
> > Nobody so far has provide a single example of *REAL* value.
> > For the hiding of ContentType to provide real value, the prerequisites are:
> >
> >   (1) this value will be _unconditionally_ provided in TLSv1.3
> >
> >   (2) this value can be demonstrated to be a real security issue in TLSv1.2,
> >       for existing usage scenarios, where hiding of ContentType is not
> >       available
> >
> > Anyhing less is no value, just an illusion of value.
> 
> Thanks for clarifying your position.  I don't think many of the other
> people in the thread are using the same definition of "value", which has
> led to a lot of confusion.
> 
> However, I'm not convinced that the concrete benefit needs to be
> mandatory-to-use in TLS 1.3 to be considered to provide value.


There is a concept called "provable correctness", and folks (such as
those from the miTLS implementation) are using this approach to check/prove
whether TLS provides certain security properties (rather than just
assuming that these properties are provided).

If hiding of ContentType has *real* value, then this property will be
formally provable.  If the properties that someone asserts as value
can be proven to not exist (one counterexample is sufficient),
then the value is an illusion / obscurity, and definitely not real value.


-Martin