Re: [TLS] Rethink TLS 1.3

Watson Ladd <> Tue, 25 November 2014 22:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D403C1A854B for <>; Tue, 25 Nov 2014 14:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DFPEI8WDuVDm for <>; Tue, 25 Nov 2014 14:19:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82FE61A86FB for <>; Tue, 25 Nov 2014 14:19:54 -0800 (PST)
Received: by with SMTP id 9so730972ykp.11 for <>; Tue, 25 Nov 2014 14:19:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=crGjIdlQfTJRmdsMYUZtQHW+i+/LIcilhvyLmDtGJTI=; b=p7vaZNNudvYl8wUq4tehKoaFBtfy2ysFrNGQQzLbnStk+yKVgm1L0M/5hWQJPdve8v JMmKcTDcdeF8chPp+ET5o406Sdr+5EqD/QKQgpckG25yh7LhT5ctDinXU+LWBVDX3rg8 JJn5+7O+Y0+OlbtWoGMwsFBNRXWOGyyL9qtI0k8NtmvzQ3EtjpafD7pbBOcGgNk34HPb R2gTUF4tY+lloah/obEntk5pSr8b0DW/bloL9iFkTpVU1vMpRGI2cxNtoH0J9Rx5h11J NmPzKluyM+ix8vvLmcRmuzokPzYO32+vW85BDgA5T+EYCFUY/DF//JjAavSs50eKBCXW f0yQ==
MIME-Version: 1.0
X-Received: by with SMTP id z42mr12887990yhc.49.1416953993764; Tue, 25 Nov 2014 14:19:53 -0800 (PST)
Received: by with HTTP; Tue, 25 Nov 2014 14:19:53 -0800 (PST)
Received: by with HTTP; Tue, 25 Nov 2014 14:19:53 -0800 (PST)
In-Reply-To: <>
References: <20141124105948.GH3200@localhost> <> <> <> <> <>
Date: Tue, 25 Nov 2014 14:19:53 -0800
Message-ID: <>
From: Watson Ladd <>
To: Joseph Salowey <>
Content-Type: multipart/alternative; boundary=089e0139fd447623f10508b64f8a
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 22:19:58 -0000

On Nov 25, 2014 1:10 PM, "Joseph Salowey" <> wrote:
> This thread is wandering a bit off topic.  TLS 1.3 is a work in
progress.  If you have suggestions on how to improve it please create a
Pull Request ( or post the specific
details to the list.  Keep in mind that the discussions on starting over
with TLS 1.3 are not in scope as the Working Group has consensus to follow
the current path.  Also, as the Working Group removes and deprecates less
secure protocol options we need to keep in mind the reality of current
deployments.  Deprecating or removing widely deployed options requires
careful consideration, since these actions may result in a protocol that is
unusable and/or not deployable.

We should never have gotten ourselves into the position of having widely
deployed broken protocols.  Now that we are in that position, we need to
start depreciating post haste, and ensuring we have safe alternatives,
including timing attack resistant ciphers. The sooner we start, the sooner
we finish.

As for improvents, how about finding an existing, conservatively designed
signature based key agreement mechanism with the right properties, and
using it? The current proposal has two distinct client auth mechanisms, one
in the handshake and the other in update.

Making sure the actual proposal is in the draft, and not spread out across
pull requests would make life a lot easier for analyzing the protocol.

It would also be nice to know how each past attack is addressed, or not.
Appendix F needs to incorporate many more implementation dependent issues,
which luckily have been related mostly to now removed options.

Parsing TLS is one of the biggest issues in implementations. I can't
promise to write the tool to auto-generate the parser, but we should be
sufficiently chastised by all those who tried and failed to parse TLS
records with handwritten C to consider not doing it ourselves.

Quality implementations need to be available: currently there are very few,
possibly none, even for TLS 1.2. I understand two implementations of TLS
1.3 are in progress, but one is slow and the other built on NSS. The more
we can simplify the protocol, the better.

We should actively resist adding features unless they are well-understood.
When it comes to TLS 1.2 we need to produce a document explaining which
combinations of features and extensions are safe. There are no less then
four or five ways to deal with Triple Handshake. Implementations need to
disable application access to TLS unique unless one of those fixes is in

TLS implementations tend to be part of the TCB. This means they need to be
simple to make them easy to audit.

None of the above is in the charter.  All of it is far more important for
security then 0 RTT.

Watson Ladd

> Cheers,
> Joe
> On Tue, Nov 25, 2014 at 7:14 AM, Watson Ladd <>
>> On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario <> wrote:
>> > On Monday 24 November 2014 09:35:20 Watson Ladd wrote:
>> >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <> wrote:
>> >> > Nico Williams wrote:
>> >> >> Henrick Hellström wrote:
>> >> >>> Yes, but the point I am trying to make, is that if the implied
>> >> >>> is to make TLS resilient even against BEAST/CRIME style attacks,
>> >> >>> threat model should be defined accordingly. It makes little sense
>> >> >>> 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
>> >> >> in the Internet threat model.
>> >> >
>> >> > Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of
>> >> > ridiculous insecurity of WebBrowsers in their default
>> > configuration.
>> >>
>> >> 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
>> > mechanism?
>> >
>> > I mean, sure they are not mandatory or the only TLS 1.2 compatible
>> > 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.
>> Sincerely,
>> Watson Ladd
>> >
>> > --
>> > Regards,
>> > Hubert Kario
>> --
>> "Those who would give up Essential Liberty to purchase a little
>> Temporary Safety deserve neither  Liberty nor Safety."
>> -- Benjamin Franklin
>> _______________________________________________
>> TLS mailing list