Re: [TLS] Fixing TLS
"SCHWARZ, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Wed, 13 January 2016 10:09 UTC
Return-Path: <albrecht.schwarz@alcatel-lucent.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 C4BB51A037B for <tls@ietfa.amsl.com>; Wed, 13 Jan 2016 02:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 xhKSemG6wDBE for <tls@ietfa.amsl.com>; Wed, 13 Jan 2016 02:09:13 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35DD1A036B for <tls@ietf.org>; Wed, 13 Jan 2016 02:09:13 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id BB791128BF909 for <tls@ietf.org>; Wed, 13 Jan 2016 10:09:08 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u0DA944l012958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tls@ietf.org>; Wed, 13 Jan 2016 11:09:10 +0100
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.142]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 13 Jan 2016 11:09:05 +0100
From: "SCHWARZ, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Fixing TLS
Thread-Index: AQHRTehT2rYBdeSLgEifQoT+VaXxrp75N4MA
Date: Wed, 13 Jan 2016 10:09:04 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1ACDF7F0E17@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz> <5C687CFB-E86A-4458-96D2-D47EFCDBA598@gmail.com> <1452678816.25588.38.camel@redhat.com>
In-Reply-To: <1452678816.25588.38.camel@redhat.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/jrPW3GQH6_8W5w0YwlzxAjsy8mY>
Subject: Re: [TLS] Fixing TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 13 Jan 2016 10:09:15 -0000
> Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill. The primary purpose of a security protocol is to support security as best as possible. Knowing security gaps causes distrust in general. Probably not in the security protocol experts community, but in the overall communications and information technology industry. The quantification of "overkill" should be rated from that trust perspective in my opinion. Albrecht -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos Sent: Mittwoch, 13. Januar 2016 10:54 To: Yoav Nir; Peter Gutmann Cc: <tls@ietf.org> Subject: Re: [TLS] Fixing TLS On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or > 2.0) that this WG is working on right now, why? > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1). Note that these are not security protocols and they don't benefit from a formal analysis of a protocol. Such an analysis takes several years to be done and it often applies to small parts of the protocol. Switching to a new version invalidates all the existing analysis. That is of course not necessarily bad, but as we are moving towards formally verified protocols it is very bad to give these two options: 1. Stay with a formally verified but with known vulnerabilities protocol 2. Switch to a new unknown protocol which has not been studied by as many cryptographers but is _believed_ to solve the issues found in TLS. > Any TLS library that exists now doesn’t have an implementation of > either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to > get an upgraded version of your favorite library. So the upgrade path > is no smoother for either protocol. If this had been brought up > before the work on the current draft started, maybe we would be > convinced. As it is, I don’t see the point. The main problem of TLS 1.2 is that it is vulnerable to cross-protocol attacks and there is no way to mitigate that. There was such an attack described in 2012 and another in 2015 [0]. Whether there will be a new one in 2017 is an open question. Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill. That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite of the code base. Given that the majority of the issues in TLS implementations are in the code bases and not in the protocol, it is very risky to switch to such a new version just like that. For old systems it most likely will never happen and they will remain vulnerable. [0]. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Yoav Nir
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Peter Bowen
- Re: [TLS] Fixing TLS Watson Ladd
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Peter Bowen
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS David Benjamin
- Re: [TLS] Fixing TLS Bill Cox
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Andrei Popov
- Re: [TLS] Fixing TLS Bill Cox
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Tony Arcieri
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Kurt Roeckx
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Dave Garrett
- Re: [TLS] Fixing TLS Eric Rescorla
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Watson Ladd
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Nikos Mavrogiannopoulos
- Re: [TLS] Fixing TLS SCHWARZ, Albrecht (Albrecht)
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Dmitry Belyavsky
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Hubert Kario
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Salz, Rich
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Peter Gutmann
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Martin Rex
- Re: [TLS] Fixing TLS Ilari Liusvaara
- Re: [TLS] Fixing TLS Martin Rex