Re: [TLS] Rethink TLS 1.3

Bodo Moeller <> Tue, 25 November 2014 16:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 818261ACD6F for <>; Tue, 25 Nov 2014 08:26:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.637
X-Spam-Level: *
X-Spam-Status: No, score=1.637 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XognET5IxQKY for <>; Tue, 25 Nov 2014 08:26:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D562B1ACD72 for <>; Tue, 25 Nov 2014 08:26:45 -0800 (PST)
Received: from ( []) by (node=mreue102) with ESMTP (Nemesis) id 0MPp7i-1XpTSz228g-004yfE; Tue, 25 Nov 2014 17:26:43 +0100
Received: by with SMTP id wp4so708998obc.11 for <>; Tue, 25 Nov 2014 08:26:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id sz9mr16517134obc.31.1416932801413; Tue, 25 Nov 2014 08:26:41 -0800 (PST)
Received: by with HTTP; Tue, 25 Nov 2014 08:26:41 -0800 (PST)
In-Reply-To: <20141124101744.GC3200@localhost>
References: <> <> <> <20141124101744.GC3200@localhost>
Date: Tue, 25 Nov 2014 17:26:41 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a11c32d0a4c90720508b160e6"
X-Provags-ID: V02:K0:143zWH0VsEBKlc9srDi5lnU+ZkGFju0+vffnF7WyiLC /S5E9EaTTrGld6lPHXe+El1cxdcqyLjNvu2aCWkGDrLau90Zwj WUjQNEIGVm3QwXdqVZCoKtO/WUHzNYy2245TJBGpBtpWBHlPeu sTCj1B7sT30bilGiXuFdfYpklHLqFWt/GKR3ck7zuHNEqeMZOa vdrvCTbXeA/hDMMT9rePrHHVvdwQsA5DEe84amfKGq0ASi9hJZ ID1AG9ok8k5nj4B0AzGKh53w8vOZ+mTyauboqIjP1OiTBd/cAE nscMvVYqPv2vP+gvJ+KoxyoYRMmRS39hnK37CYuT8b3XKOwFvA h5TotEFnQzs7BpQ7gaOu4lQgtIdhmFGrgXp9bDlYg5kD93tGWN /YtELsQmNj+UFRy/BR+w4SEbXfHGfPePdDQhgKbJ0zCh7tbumN N6KTK
X-UI-Out-Filterresults: notjunk:1;
Subject: Re: [TLS] Rethink TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Nov 2014 16:26:50 -0000

Nico Williams <>:

> 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:

This is sort of true, and sort of isn't.

If you look at RFC 3552 ("The Internet environment has a fairly well
understood threat model. In general, we assume that the end-systems
engaging in a protocol exchange have not themselves been compromised.
Protecting against an attack when one of the end-systems has been
compromised extraordinarily difficult. [...] By contrast, we assume that
the attacker has nearly complete control of the communications channel over
which the end-systems communicate.") and the goals of TLS according to RFC
5246 ("Cryptographic security: TLS should be used to establish a secure
connection between two parties"), it's true that this can be read as
covering all kinds of attacks, because it is sufficiently vague. But then
if you look at the *specific* examples of attacks in RFC 3552, it becomes
quite clear that classes of attacks including BEAST weren't really
considered back then.

I don't agree with claims elsewhere in this thread that such attacks
violate the premise of RFC 3552 of end-systems being uncompromised.  If a
system is designed to tunnel externally provided data (some of which may be
provided by an attacker) through TLS, this makes it vulnerable to BEAST,
but I think it's a far fetch to call such a system "compromised" by
design.  Yes, "Cross Site Request Forgery" style attacks can be used to
exploit the security weaknesses, but if the protocols were offering secure
channels according to an appropriate definition, then the weaknesses
wouldn't be an issue (even if the attacker can use scripting languages to
partially remote-control the systems under attack).  [Also, if you believe
that POODLE *requires* this attack setting, you just lack imagination. The
*full* POODLE attack assume this setting, but if an attacker can obtain
just a single byte of your password, that's a breakage too.  Cf. for
inspiration for a setting not involving any Javascript or other scripting

As we know from the cryptographic literature, however, properly formalizing
the needed security properties can be as hard as (or even harder than)
achieving them.  Everyone reading papers dealing with formal security
proofs for cryptographic schemes will, on occasion, have run into some
formally defined security notion that looks quite reasonable at first, but
on closer inspection turns out to have problems -- e.g., assumes something
that is in fact unsatisfiable, or insufficient, or even both.  The security
claims that TLS should fulfill, for example, may seem somewhat clear, but
only if you don't actually go into all the details.

Accordingly, I don't think it is meaningful to blame *either* the threat
model *or* TLS for the shortcomings.  The lack of clearness about the
security goals can reasonably be blamed on both.