Re: [TLS] Rethink TLS 1.3

Henrick Hellström <henrick@streamsec.se> Sun, 23 November 2014 00:34 UTC

Return-Path: <henrick@streamsec.se>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BA41A19EA for <tls@ietfa.amsl.com>; Sat, 22 Nov 2014 16:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 h7CGakNxOo-3 for <tls@ietfa.amsl.com>; Sat, 22 Nov 2014 16:34:01 -0800 (PST)
Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id 257D21A19E9 for <tls@ietf.org>; Sat, 22 Nov 2014 16:34:00 -0800 (PST)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP; Sun, 23 Nov 2014 01:33:56 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 91A2A1DE89; Sun, 23 Nov 2014 01:33:56 +0100 (CET)
Message-ID: <54712B74.70609@streamsec.se>
Date: Sun, 23 Nov 2014 01:33:56 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= <henrick@streamsec.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0ckmYrx+S--pP6P7VgjsmqQsoYnp+m-9hTPT-OJ9waUtkA@mail.gmail.com> <5470742A.8020002@streamsec.se> <CACsn0cnKqkHxw0Hudw0OGM1mVxZKJhj04ig2G3KtURtWhYTacw@mail.gmail.com>
In-Reply-To: <CACsn0cnKqkHxw0Hudw0OGM1mVxZKJhj04ig2G3KtURtWhYTacw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2R2KY3BfphL6FLDamOalsYzOTCs
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Rethink TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
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: <http://www.ietf.org/mail-archive/web/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: Sun, 23 Nov 2014 00:34:03 -0000

On 2014-11-22 23:15, Watson Ladd wrote:
> On Sat, Nov 22, 2014 at 3:31 AM, Henrick Hellström <henrick@streamsec.se>; wrote:
>> On 2014-11-22 01:57, Watson Ladd wrote:
>>>
>>> Was the TLS 1.3 draft written by a cryptographer? No.
>>> Has it been reviewed by cryptographers? Unclear.
>>> Are the mechanisms secure? Unknown.
>>> Is it easy to analyze TLS 1.2? No.
>>> Was TLS 1.2 secure? No.
>>> Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains
>>> unincluded, but the record layer is finally fixed.
>>
>>
>> I think such discussions would benefit from the basic premise that "secure"
>> is a relative notion. It is completely pointless to ask if a protocol is
>> secure or not secure, unless you first present an exhaustive list of
>> security claims. That is, you can't ask if TLS 1.3 is secure or not, without
>> first describing what security is to be expected from different scenarios.
>
> It's clear what the security claims of TLS are be: a TLS connection
> between two parties ensures that data sent between them isn't
> intercepted or manipulated, and that they are who they claim to be.
> This is a fairly standard notion, clearly present in research by the
> late 80's, and intuitively sensible.
>
> Of course, past versions of TLS haven't provided it.

OK, but in such case, the problem with BEAST would be the browser 
implementation dependent violation of same-origin policy constraints, 
and not part where the CBC state is predicted. Your requirements imply a 
strict same-origin policy. If such a policy is violated, the problem is 
that SSL/TLS is used in a scenario that transcends its security claims, 
and not that the protocol is flawed.