Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 27 August 2016 14:38 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 CB2FB12D5A9 for <tls@ietfa.amsl.com>; Sat, 27 Aug 2016 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 hLGFR51KZ4Ty for <tls@ietfa.amsl.com>; Sat, 27 Aug 2016 07:38:32 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23312D59A for <tls@ietf.org>; Sat, 27 Aug 2016 07:38:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 0EDEDD79E for <tls@ietf.org>; Sat, 27 Aug 2016 17:38:31 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 06tq9J72mI4L for <tls@ietf.org>; Sat, 27 Aug 2016 17:38:30 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 74E80C4 for <tls@ietf.org>; Sat, 27 Aug 2016 17:38:30 +0300 (EEST)
Date: Sat, 27 Aug 2016 17:38:20 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20160827143820.leudxrgh2abm5fpg@LK-Perkele-V2.elisa-laajakaista.fi>
References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <CADMpkc+vbkWz_TQ2Ch5JfaVRPse4qeXPPitsBV=d2yDtSx4eLA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <m260qwppxa.fsf@localhost.localdomain> <CAF8qwaB-p1X6vcKZ7=GfPe_hWxOB+g4T2mKaugpbYAKNJngJ7g@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mu88_cRCNNf_6IG3UY0OuMWZ4oY>
Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
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, 27 Aug 2016 14:38:35 -0000

On Sat, Aug 27, 2016 at 01:27:15PM +0000, Peter Gutmann wrote:
> David Benjamin <davidben@chromium.org> writes:
> 
> >TLS 1.3 will resolve this with the new cipher suite negotiation, but I agree
> >this makes the specification basically undeployable with TLS 1.2. This issue
> >also got brought up here:
> >https://www.ietf.org/mail-archive/web/tls/current/msg18697.html
> 
> Hmm, good point.  So reading between the lines of the various comments on this
> issue, the feeling seems to be "ignore this RFC".  That more or less answers
> my question, I'll leave it out of TLS-LTS apart from mentioning it as another
> source of DH groups.

The bad thing about allowing server to specify arbitrary group is that
the group can be such that the client does not like it. E.g.

- Too short modulus
- Bad modulus
- Used subgroup not big enough.

The first one is essentially what kills the DH in TLS 1.2.
 
> >Barring unforeseen problems, Chrome will also lose DH in the next release.
> 
> Which will be yet another headache for people working with SCADA devices, who
> are seeing themselves locked out more and more from being able to admin their
> systems when browser vendors arbitrarily decide to deprecate long-established
> mechanisms. 

It is not "arbitrarily". Thinking back, every TLS-related deprecation I
am aware of is because at least one of:

- The mechanism is known to have serious security issues.
- The mechanism causes serious usability issues.
- Virtually nobody uses it (and any use is probably due to misconfig).

And with browsers, deprecating stuff takes way more time than it should
because of "compatiblity".

Most of this is because of bad design. Back in 2002 we would have had
all the technology necressary to design stuff that would still be
standing 14 years later in 2016, with no hint of breaking in near
future. Sure, it would be relatively slow, but that's no security
issue.

TLS is full of bad decisions (many inherited from SSL v3) that are
still haunting us, and it takes pretty much radical redesign (a.k.a.
TLS 1.3) to fix it.

> Couldn't Chrome include an optional legacy mode that just works with existing
> systems, perhaps triggered by access to a device at an RFC 1918 address?
> There really is, in some cases, nothing available any more that will talk to
> entire families of SCADA devices because browsers assume the only thing that
> matters is the public WWW and won't accommodate anything that isn't.

Even supporting systems like that is serious security issue. Basically
if one even supports weak crypto, there usually are ways to enable it
when it should not be enabled, totally compromising security.

Whitness the multitude of attacks against TLS that exploit support
for weak crypto or bad protocol versions. Even if "disabled".

> (At some point someone's going to figure out they can make a lot of money by
> taking Firefox 3.0, rebranding it, and selling it as an embedded device
> management solution, because it'll talk to all the things that current
> browsers won't any more).

Well, I'm not aware of anything stopping anyone from doing that...


-Ilari