Re: [TLS] draft-dkg-tls-reject-static-dh

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 08 December 2018 03:24 UTC

Return-Path: <dkg@fifthhorseman.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 A8BA9131072 for <tls@ietfa.amsl.com>; Fri, 7 Dec 2018 19:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] 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 Axb9rkHai4ki for <tls@ietfa.amsl.com>; Fri, 7 Dec 2018 19:24:28 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F3C12D4EC for <tls@ietf.org>; Fri, 7 Dec 2018 19:24:27 -0800 (PST)
Received: from fifthhorseman.net (41-139-152-102.safaricombusiness.co.ke [41.139.152.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 5011FF99D; Fri, 7 Dec 2018 22:24:23 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 1C182209EA; Sat, 8 Dec 2018 06:23:01 +0300 (EAT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Nico Williams <nico@cryptonector.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls\@ietf.org" <tls@ietf.org>
In-Reply-To: <1544166850611.133@cs.auckland.ac.nz>
References: <9a9be8fb-9667-0c6a-9fac-cc167f94599f@cs.tcd.ie> <874lbqcgu2.fsf@fifthhorseman.net> <1544164274460.61998@cs.auckland.ac.nz> <20181207064745.GU15561@localhost> <1544166850611.133@cs.auckland.ac.nz>
Date: Sat, 08 Dec 2018 06:22:57 +0300
Message-ID: <87pnucbt2m.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BpR0AbFuzQZBfP0JOB0plH30I-s>
Subject: Re: [TLS] draft-dkg-tls-reject-static-dh
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Dec 2018 03:24:30 -0000

On Fri 2018-12-07 07:14:17 +0000, Peter Gutmann wrote:
> I appreciate that people feel strongly about this, and I support the idea of
> non-ephemeral DHE detection in principal [0] (along with many, many other
> measures to strengthen TLS), but this draft reads a lot like the IETF blowing
> raspberries at ETSI.  

hm, it's true that i'm not happy with ETSI's decision-making process
here, but my goal with the draft is to provide a measure of defense for
TLS clients on the public Internet who might accidentally/unknowingly
come into contact with some errant eTLS server implementation that has
escaped the enterprise data center, and not realize it.  If you want to
suggest ways to reduce the raspberry-blowing-ness of it, i'm all ears.

My initial (unpublished) copy of the draft didn't contain the "Problems
with static DH" section at all, it was just a quick set of guidance on
how to mitigate the risks introduced by this potential ecosystem change.

I added the "Problems" section because i wanted to document the very
real concerns; it's not a raspberry-blowing doc for the sake of
rasberries.

> but getting into an arms race you know you can't win seems like, well,
> workgroup posturing.

Another way that someone who wants to leak secrets could leak them would
be to use a bad FFDHE group and small subgroup during key exchange
(indeed, this can happen by accident in some cases), or by enabling and
encouraging the use of export ciphersuites.  But we discourage people
from doing bad FFDHE at a protocol level in TLS 1.2 (where arbitrary
groups are allowed) by encouraging peers to reject handshakes that are
not in the right-sized subgroup.  If you can detect that the peer is
misbehaving, shouldn't you act on it?  Otherwise, what's the point of
detection?

> [0] "In principal" because there's a fair bit of SCADA gear that does this
>     because it doesn't have the CPU power to generate new DHE values, as I 
>     found out when I turned on non-DHE checking some years ago.

Is this SCADA gear running TLS 1.3?  is it clients and servers both, or
just one or the other?  When was this scan done?  i'd love to see more
documentation about this practice.

        --dkg