Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Scott Schmit <i.grok@comcast.net> Sun, 13 March 2016 21:23 UTC

Return-Path: <i.grok@comcast.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35912D848 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 14:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 a-EVPKdj9wBl for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 14:23:56 -0700 (PDT)
Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67F212D821 for <tls@ietf.org>; Sun, 13 Mar 2016 14:23:55 -0700 (PDT)
Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-10v.sys.comcast.net with comcast id VZPd1s0024s37d401ZPvoF; Sun, 13 Mar 2016 21:23:55 +0000
Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-po-01v.sys.comcast.net with comcast id VZPj1s00H2Ekl4801ZPpGv; Sun, 13 Mar 2016 21:23:53 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id u2DLNhWJ032185 for <tls@ietf.org>; Sun, 13 Mar 2016 17:23:43 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.15.2/8.15.2/Submit) id u2DLNhMv032184 for tls@ietf.org; Sun, 13 Mar 2016 17:23:43 -0400
Date: Sun, 13 Mar 2016 17:23:42 -0400
From: Scott Schmit <i.grok@comcast.net>
To: tls@ietf.org
Message-ID: <20160313212342.GA27160@odin.ulthar.us>
References: <56E54B85.4050204@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="bg08WKrSYDhXBjb5"
Content-Disposition: inline
In-Reply-To: <56E54B85.4050204@cs.tcd.ie>
User-Agent: Mutt/1.5.24 (2015-08-30)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457904235; bh=2KxL8rS+1vpKN6iHkkBmLefZqVw6j5FWTapFAwNewTA=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=Z56yd/Lvw5P4l4u/nUZTv83BYQbeMWShCDSxYqIgwCiXQV+uVDKuMfp10ButAvr3D 1kZcclzziKcBSjxV1YzqfRb+ipPsW/AQC53GSNvQUC2Cj8a6MPEpmqJg8KJZjetwaX c4yEwL7PfGsaGqcq67VbVpxpVAIJnrb8ynZl/406dxGTdqUFEyGgtkqbszB0YBRDg4 kH6GDiLE9gwveWYjjdtC7LvmB1KL5yAn2eY1Drtg0jq33doK5Wmil2w5grRCql8zbr 2uzenMxPVXetxbCki8AOdHhvKtyHOw5QaJm0t2qgynCdju7dY1/gHhLh2M1l/WTnCS UzjY8tiQlgbzw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HmTkPh7eHFoLbQElFTaV0Omb7PM>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 13 Mar 2016 21:23:58 -0000

On Sun, Mar 13, 2016 at 11:14:13AM +0000, Stephen Farrell wrote:
> First, with no hats, if the WG were to have a poll on whether
> or not to include 0rtt in TLS1.3, then as a participant in the
> work here, I'd be firmly arguing to leave it out entirely. I
> really think an over-emphasis on reducing latency for browsers
> is going to bite us (and the Internet) in the ass in the same
> ways that emphasising interop over security has in the past with
> fallbacks to older, worse versions of TLS/SSL, with all their
> inherent flaws and bits of e.g. crappy "export" crypto support.
> Absent 0rtt, TLS1.3 seems to me to be an excellent step forward
> in security. With 0rtt, I think it also becomes a dangerous
> implement. So, that's my personal opinion, while not wearing an
> AD hat.

I think you're exactly right.  Let's look at the vulnerabilities in TLS:
- Renegotiation attack
  - Optimization to establish a new TLS session without reestablishing a
    TCP/IP connection.  Broken repeatedly despite analysis, etc.
  - TLSv1.3's answer?  Drop renegotiation.
- BEAST
  - CBC chained off the last block sent so that an explicit IV need not
    be sent on the wire.  Another optimization.
  - TLSv1.3's answer?  Drop CBC.
- CRIME / BREACH
  - Compression was supported to speed up connections (less data to
    process/transfer).  Optimization, again.
  - TLSv1.3's answer?  Drop compression.
- Lucky Thirteen / Padding timing attacks / POODLE
  - Years later, servers are still vulnerable because insecure
    algorithms & versions remain enabled, even with the publicity around
    POODLE
  - TLSv1.3's answer?  Drop the bad cipher suites and offering < 1.0.
- RC4
  - RC4 is known to be weak, but it continues to be widely used
  - SSL/TLS included it because analysis said it was secure as used.
  - TLSv1.3's answer?  Drop RC4.
- FREAK / Logjam (downgrade attacks)
  - This happened because TLS vendors left obsolete export algorithms
    implemented, and server admins left them enabled.
  - TLSv1.3's answer?  Drop the insecure cipher suites.
- DROWN
  - Why is this even an issue?  Because people STILL haven't turned off
    SSLv2 *twenty* *years* after it was known to be insecure!!
  - TLSv1.3's answer?  Drop compatibility with SSLv2.

So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?

What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

If almost everyone should turn it off, why are we including it?

Most server admins won't be reading the TLSv1.3 spec.  They're going to
see "shiny feature added specifically in this version that makes it
faster!" with *maybe* a warning that there are risks, which they'll
dismiss because "if it was so insecure, they wouldn't have included it
in the protocol in the first place."  Unless 0-RTT can be fixed, it
looks like an attractive nuisance.

Let's leave it out.

-- 
Scott Schmit