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

mrex@sap.com (Martin Rex) Thu, 10 November 2016 17: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 4197E12948B for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 09:31:00 -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 RQD4Ap1xm05q for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 09:30:58 -0800 (PST)
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 548D312947E for <tls@ietf.org>; Thu, 10 Nov 2016 09:30:58 -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 smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3tF97N6YM3z1J35; Thu, 10 Nov 2016 18:30:56 +0100 (CET)
X-purgate-ID: 152705::1478799056-0000521C-AC3B6C46/0/0
X-purgate-size: 2293
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 3tF97M57tRzGny8; Thu, 10 Nov 2016 18:30:55 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A50691A57D; Thu, 10 Nov 2016 18:30:55 +0100 (CET)
In-Reply-To: <4d10cc42-6a44-5c97-a246-56c31ac7fef1@akamai.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Date: Thu, 10 Nov 2016 18:30:55 +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: <20161110173055.A50691A57D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_UjfqeINfhohQ10Afwh7Lplu0-g>
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:31:00 -0000

Benjamin Kaduk wrote:
[ Charset windows-1252 unsupported, converting... ]
> On 11/10/2016 11:13 AM, Martin Rex wrote:
> >
> > 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.
> 
> My understanding was that our current knowledge of what capabilities
> traffic analysis makes possible and the countermeasures against them is
> quite poor, certainly not to the level where rigorous proofs are
> possible.  So, I fear we must be operating "in the dark" in this regard
> for the near future.


Proving that something is secure can be pretty difficult, that is correct.

Proving that something is insecure can be pretty trivial (one counterexample
is sufficient).

For someone who does this formal proofing stuff regularly, it may already
be possible today to formally proof that hiding the ContentType can not
possibly provide any value.


Where is the value with hiding the ContentType of SSL Alerts?

We know that at least one implementations notoriously _not_ sends any alerts
before closing connnections.  The installed base has somehow managed
to live with it.  But it's often painful to figure out the cause of
handshake failures, and to distinguish a certain kind of server
accept()ing and silently closing a connection after hitting a bug
(or policy) from an overzealous firewall (NAT or "transparent internet proxy").

So if your implementation has anything to hide, performing a dirty
socket closure (resulting in a TCP RST) will be *MUCH* more effective
in hiding information from observers than hiding the TLS Alert ContentType.

Silent connection closures are certainly much more effective for leaving
rightful communication peers (&helpdesk &support) in the dark about why
the heck communication is failing.


-Martin