Re: [TLS] Broken browser behaviour with SCADA TLS

mrex@sap.com (Martin Rex) Thu, 05 July 2018 18:18 UTC

Return-Path: <mrex@sap.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 5967F130F78 for <tls@ietfa.amsl.com>; Thu, 5 Jul 2018 11:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 M2eojQ8iLuI9 for <tls@ietfa.amsl.com>; Thu, 5 Jul 2018 11:18:34 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBB4130F76 for <tls@ietf.org>; Thu, 5 Jul 2018 11:18:30 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 41M5hN0mpPzc8; Thu, 5 Jul 2018 20:18:28 +0200 (CEST)
X-purgate-ID: 152705::1530814708-0000081F-9B27ABBF/0/0
X-purgate-size: 2466
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 41M5hM2txXzGpp6; Thu, 5 Jul 2018 20:18:27 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5820E409B; Thu, 5 Jul 2018 20:18:27 +0200 (CEST)
In-Reply-To: <1530757910178.45400@cs.auckland.ac.nz>
References: <1530687136897.97792@cs.auckland.ac.nz> <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <b8ecb2cfdac0495f188baf9df187c075e70c3a58.camel@redhat.com> <CAF8qwaBTHfn7iBEaZ9QQ2ueP09Qn4J2s1sBWhqopTzq7eLF6ww@mail.gmail.com> <1530757910178.45400@cs.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Thu, 5 Jul 2018 20:18:27 +0200 (CEST)
CC: David Benjamin <davidben@chromium.org>, Nikos Mavrogiannopoulos <nmav@redhat.com>, "<tls@ietf.org>" <tls@ietf.org>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20180705181827.5820E409B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B2EqQ3ODNCBBoF8pSrIwYr6xmrI>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 18:18:44 -0000

Peter Gutmann <pgut001@cs.auckland.ac.nz>; wrote:
> David Benjamin <davidben@chromium.org>? writes:
> 
>>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
>>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered
>>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95%
>>of DHE negotiations made by Chrome used a 1024-bit minimum.
> 
> How does Google, rather than the people running the systems being connected
> to, know that 1024-bit DH isn't secure enough for a given environment?  The
> majority of this stuff is running on isolated, private networks or inside VPN
> tunnels for which pretty much anything, including 512-bit keys, are fine.

Silently removing stuff (support for TLS_DHE) is just as bad as silently
adding stuff (automatic, silent and unlimited-times protocol downgrade
dance in the broswer which became famously known as POODLE).


> 
> It's also somewhat disturbing that Chrome now walks straight past a perfectly
> good PFS DHE suite and instead goes to a problematic pure-RSA one instead.

Cough, what?  TLS_DHE_ was known to be a security disaster beyond fixing
a good decade ago (14-May-2007):

   https://www.ietf.org/mail-archive/web/tls/current/msg01647.html

but it needed a LOGJAM demonstration to have folks look at the
crappy implementations in the installed base.

We didn't have support for TLS_DHE in our SSL implementation back then,
and I decided I never want to have it added.  We've added support for
TLS_ECDHE a few years ago, but TLS_DHE remains unsupported.  Probably
most usage scenarios that still offer TLS_DHE today, provide less security
than with static-RSA 2048-bit.


How often does your SCADA devices (=servers) regenerate its DHE params?
If it is using DHparams for several weeks, months or even forever, then
there is essentially no PFS, and static RSA will be equal or better than DHE.
Static RSA-2048 will always be better than DHE-1024.  Simply regenerate
and roll your RSA keys&server cert if it makes you feel good.


btw. which kind of "problematic pure-RSA" are you talking of?
I'm not actually aware of any problem, and I'm much more concerned
about TLS servers with longterm DHE params or longterm ECDHE keys
and equally about servers using session tickets with a longterm session ticket
encryption key, because of the illusion of PFS, which they create but
do not offer.


-Martin