Re: [TLS] Rethink TLS 1.3

Hubert Kario <hkario@redhat.com> Tue, 25 November 2014 15:25 UTC

Return-Path: <hkario@redhat.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 0C3901A1EEA for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 07:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YYzUA1-89Xdw for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 07:25:23 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 809FB1A0399 for <tls@ietf.org>; Tue, 25 Nov 2014 07:25:17 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPFPGkJ003382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tls@ietf.org>; Tue, 25 Nov 2014 10:25:16 -0500
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAPFPE19001148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Tue, 25 Nov 2014 10:25:15 -0500
From: Hubert Kario <hkario@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 25 Nov 2014 16:25:14 +0100
Message-ID: <5982358.T0UeBgPCAg@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CACsn0c=7fzAmshr7qamiLZdRUNs8kexQPR4E6n3teqNi4HzOjQ@mail.gmail.com>
References: <20141124105948.GH3200@localhost> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <CACsn0c=7fzAmshr7qamiLZdRUNs8kexQPR4E6n3teqNi4HzOjQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4R-a4M8skMmPnzoZkcp49Wdg5LY
Subject: Re: [TLS] Rethink TLS 1.3
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: <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: Tue, 25 Nov 2014 15:25:29 -0000

On Tuesday 25 November 2014 07:14:38 you wrote:
> On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario <hkario@redhat.com>; wrote:
> > On Monday 24 November 2014 09:35:20 Watson Ladd wrote:
> >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <mrex@sap.com>; wrote:
> >> > Nico Williams wrote:
> >> >> Henrick Hellström wrote:
> >> >>> Yes, but the point I am trying to make, is that if the implied goal
> >> >>> is to make TLS resilient even against BEAST/CRIME style attacks, the
> >> >>> threat model should be defined accordingly. It makes little sense to
> >> >>> ask for cryptographic review of the protocol, if it is inherently
> >> >>> unclear exactly what kind of threats the protocol is designed to
> >> >>> withstand.
> >> >> 
> >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of
> >> >> attackers
> >> >> in the Internet threat model.
> >> > 
> >> > Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of the
> >> > ridiculous insecurity of WebBrowsers in their default
> > 
> > configuration.https://tcms.engineering.redhat.com/case/295339/
> > 
> >> So it's possible to get my Paypal login cookie if I browse to a
> >> malicious site on a fully patched browser? Because that's what BEAST
> >> enabled. Are you saying it's fine that SSL v3.0 leaks one byte per
> >> connection? Because that's POODLE. All of this was known in 2004, and
> >> not fixed in TLS 1.2
> > 
> > are you suggesting that AEAD ciphers are vulnerable to them? based on what
> > mechanism?
> > 
> > I mean, sure they are not mandatory or the only TLS 1.2 compatible
> > ciphers,
> > but there are there...
> 
> Fixed means fixed, not "you get to play choose your own ciphersuite,
> where most of the options are wrong". It means aggressively removing
> ciphers and protocols known to be weak. Instead of considering the job
> done when secure options have been added, we should consider it done
> when the insecure options have been removed.

But then you have ADH and AECDH ciphers which can be used securely (and have 
their valid uses) but are insecure for the web use case.

as long as TLS will remain a general protocol, there will be "pick and choose" 
involved

and I prefer situation with one protocol that has some problems than 20 
protocols, each with its own set of idiosyncrasies
-- 
Regards,
Hubert Kario