Re: [TLS] Rethink TLS 1.3

Henrick Hellström <henrick@streamsec.se> Mon, 24 November 2014 10:31 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 756FA1A1EF9 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 02:31:12 -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 ThQn2NF_qdeZ for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 02:31:10 -0800 (PST)
Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id 57DEE1A1EEF for <tls@ietf.org>; Mon, 24 Nov 2014 02:31:09 -0800 (PST)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 24 Nov 2014 11:31:05 +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 6E6531DE89; Mon, 24 Nov 2014 11:31:05 +0100 (CET)
Message-ID: <547308E2.6060809@streamsec.se>
Date: Mon, 24 Nov 2014 11:30:58 +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: Nico Williams <nico@cryptonector.com>, Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0ckmYrx+S--pP6P7VgjsmqQsoYnp+m-9hTPT-OJ9waUtkA@mail.gmail.com> <5470742A.8020002@streamsec.se> <CACsn0cnKqkHxw0Hudw0OGM1mVxZKJhj04ig2G3KtURtWhYTacw@mail.gmail.com> <20141124101744.GC3200@localhost>
In-Reply-To: <20141124101744.GC3200@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fF5eIjCdPTV8-nmrkF34prtwo-o
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: Mon, 24 Nov 2014 10:31:12 -0000

On 2014-11-24 11:17, Nico Williams wrote:
> On Sat, Nov 22, 2014 at 02:15:30PM -0800, Watson Ladd wrote:
>> 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.
>
> It's the standard Internet threat model.  Aside from needing to be
> updated for massive adversay capabilities, the standard Internet threat
> model has held up well.  What hasn't held up is TLS:
>
>> Of course, past versions of TLS haven't provided it.
>>
>>> In a sense, *every* protocol has the potential of becoming broken,
>>> unless it is unambiguously defined what is proper and improper usage
>>> of the protocol.
>
> We don't have a crystal ball.  All we have is fairly decent (but almost
> certainly incomplete) public understanding of cryptography, and a
> fairly decent idea of today's applications' needs.  We can imagine the
> near future and plan accordingly, but further out we run into trouble.
>
> I don't think we necessarily need, e.g., an explicit statement that
> resistance to BEAST/CRIME style attacks is required: the standard
> Internet threat model implies it.

Actually, no, it doesn't. The Internet threat model is based on the 
premise that both ends are uncompromised. If the client is allowing 
third party javascript to connect to arbitrary HTTPS servers, 
impersonating the client that runs the script, that client is compromised.