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

Benjamin Kaduk <bkaduk@akamai.com> Thu, 10 November 2016 17:16 UTC

Return-Path: <bkaduk@akamai.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 2CE14129434 for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 09:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 MKLgNb7IBm5d for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 09:16:26 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E18D9129410 for <tls@ietf.org>; Thu, 10 Nov 2016 09:16:25 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 403C743347D; Thu, 10 Nov 2016 17:16:25 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2487B43340F; Thu, 10 Nov 2016 17:16:25 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478798185; bh=q+rbfuL3QxNtecOiatE1DtGXjbu93Dg+g/BlN0l1adQ=; l=2499; h=To:References:Cc:From:Date:In-Reply-To:From; b=Ok76EFytLfjBFi3ZtdDujgZSd73kRIkPW+vxLUQ/h/j669nR6pN5ED0+XSoK9ny1A u1duOnFbHn99zj4UEG9Roa+Kgx4zmtw3bN95LvK1W2udY3OuBdTCZ+T3rJzw/jstCV mdyZmeQW7CPy5AkwI2vHaqAV2+PiJCMMahDRA/gk=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id D4AD71FC93; Thu, 10 Nov 2016 17:16:24 +0000 (GMT)
To: mrex@sap.com
References: <20161110171353.37D451A57D@ld9781.wdf.sap.corp>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <4d10cc42-6a44-5c97-a246-56c31ac7fef1@akamai.com>
Date: Thu, 10 Nov 2016 11:16:24 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161110171353.37D451A57D@ld9781.wdf.sap.corp>
Content-Type: multipart/alternative; boundary="------------1FEFC25E29C36D6048A59B0C"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1ra0rMvrOl1nnvdlQ4XrkuyUNlg>
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
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:16:27 -0000

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.

-Ben