Re: [TLS] Industry Concerns about TLS 1.3

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 24 September 2016 21:45 UTC

Return-Path: <ilariliusvaara@welho.com>
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 2372C12B05A for <tls@ietfa.amsl.com>; Sat, 24 Sep 2016 14:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 2LP8xinHjpiq for <tls@ietfa.amsl.com>; Sat, 24 Sep 2016 14:45:26 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5FF12B054 for <tls@ietf.org>; Sat, 24 Sep 2016 14:45:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 81DF513621; Sun, 25 Sep 2016 00:45:23 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id xFk8F7sQdj-H; Sun, 25 Sep 2016 00:45:23 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3A261283; Sun, 25 Sep 2016 00:45:23 +0300 (EEST)
Date: Sun, 25 Sep 2016 00:45:19 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20160924214519.GA8903@LK-Perkele-V2.elisa-laajakaista.fi>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <201609221529.42449.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <201609221529.42449.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/S7l4kX-FtPeRqBC2cXpo5h4_RsI>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
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: Sat, 24 Sep 2016 21:45:28 -0000

On Thu, Sep 22, 2016 at 03:29:42PM -0400, Dave Garrett wrote:
> 
> Yes, all of these other channels are protected using TLS... which you
> do not control in any way. Also, many sites/services already prioritize
> FS cipher suites, so the deprecation of plain RSA key exchange doesn't
> actually affect the vast majority of people. (e.g. Facebook & Twitter
> both prefer ECDHE with NIST P-256) Within this very argument is
> already the argument that supervision at endpoints is required here.
> he security on the pipe is irrelevant. I don't see how you can make a
> point to bring this up but think keeping plain RSA KE suites is a
> useful solution.

Well, if you have client and server that both have RSA KE enabled
(even if not preferred), you can do something like this:

- Intercept ClientHello. Strip any FPS ciphersuites and any associated
  extensions, strip EMS and ALPN but keep client_version and
  client_random the same.
- The server will select RSA KE.
- Intercept Certificate message and replace it with MITM cert.
- Intercept ClientKeyExchange decrypt the key and re-encrypt with the
  original server key.
- Compute the session key and log it.
- Intercept the ClientFinished message and replace it with fixed
  version.
- Intercept the ServerFinished message and replace it with fixed
  version.
- Get off the active path, becoming passive.
- Log the data transfer on the connection, and later decrypt it if
  desired.

The keys will match, because they only depend on randoms (which
were preserved) and the encrypted secret (which was preserved too).
The EMS was stripped because it would break this.

The MITM proxy knows the secrets needed to fix the Finished messages.

Preferring FS won't help, because MITM proxy can downgrade the
crypto negotiation.


(And it is not like one can easily get the keys without either
replacing the cert or knowing the RSA private key corresponding to
it).




-Ilari