Re: [TLS] Rethink TLS 1.3

mrex@sap.com (Martin Rex) Mon, 24 November 2014 17:26 UTC

Return-Path: <mrex@sap.com>
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 5B9B61A6FF2 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 09:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 2KmMLS848TAl for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 09:26:33 -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 AF3D71A6FDC for <tls@ietf.org>; Mon, 24 Nov 2014 09:26:33 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 978EF3A0F3; Mon, 24 Nov 2014 18:26:31 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 8C7C841356; Mon, 24 Nov 2014 18:26:31 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 845CB1B004; Mon, 24 Nov 2014 18:26:31 +0100 (CET)
In-Reply-To: <CACsn0cnKqkHxw0Hudw0OGM1mVxZKJhj04ig2G3KtURtWhYTacw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 24 Nov 2014 18:26:31 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20141124172631.845CB1B004@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4N4QckV6HcRGRU9UylmwCP48ipo
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: 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: <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 17:26:38 -0000

Watson Ladd wrote:
> Henrick Hellström <henrick@streamsec.se> wrote:
>>
>> 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.

Actually, all versions of TLS, including SSLv3 still provide the
properties you've just described today.

Every problem that has been described so far was an (ab)use of the
orginal SSL&TLS protocols beyond its stated design goals based on
flawed assumptions what TLS should additionally provide or what
the above should be interpreted to cover as well.

-Martin