Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

mrex@sap.com (Martin Rex) Mon, 09 July 2018 22:20 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 31B1B130DC3 for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 15:20:19 -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 oFa14dciAXJF for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 15:20:16 -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 45474130E92 for <tls@ietf.org>; Mon, 9 Jul 2018 15:20:12 -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 41PfsP50vQz42; Tue, 10 Jul 2018 00:20:09 +0200 (CEST)
X-purgate-ID: 152705::1531174809-0000081F-091DFC3F/0/0
X-purgate-size: 1962
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 41PfsM5VL8zGpYp; Tue, 10 Jul 2018 00:20:07 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AF5BD409B; Tue, 10 Jul 2018 00:20:07 +0200 (CEST)
In-Reply-To: <CY4PR21MB0774BE80A4424D41D0C8C4138C440@CY4PR21MB0774.namprd21.prod.outlook.com>
References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <CAHbuEH5J-F2cKag02Vx416jsy1N6XZOju28H99WAt71Pc5optg@mail.gmail.com> <CABcZeBN4RPt_=zu-PTPeaYbQ4KxC8DAf=a7359pZDjYavpxecw@mail.gmail.com> <CABcZeBMzweULuOfxe_Dp7n6M7Lt77_1Qq92=KzfmuBeShUSCDQ@mail.gmail.com> <CY4PR21MB0774BE80A4424D41D0C8C4138C440@CY4PR21MB0774.namprd21.prod.outlook.com>
To: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>
Date: Tue, 10 Jul 2018 00:20:07 +0200 (CEST)
CC: Eric Rescorla <ekr@rtfm.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.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: <20180709222007.AF5BD409B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Sy_mkCOcT0F379AFoE_13Cu_MUg>
Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 09 Jul 2018 22:20:19 -0000

Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org> wrote:
>
> On the recent Windows versions, TLS 1.0 is negotiated more than 10%
> of the time on the client side (this includes non-browser connections
> from all sorts of apps, some hard-coding TLS versions),
> and TLS 1.1 accounts for ~0.3% of client connections.

"On recent Windows versions" sounds like figure might not account
for Windows 7 and Windows Server 2008R2, about half of the installed
base of Windows, and where the numbers are likely *MUCH* higher.

When troubleshooting TLS handshake failures, I sometimes trying
alternative SSL/TLS clients on customer machines through remote support,
and it seems when I run this command on a Windows 2012R2 server:

        powershell "$web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1

it connects with TLSv1.0 only, and this is a client-side limitation.

To make it use TLSv1.2, I would have to use

        powershell "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 ; $web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1

i.e. explicit opt-in.


I already have a long list of stuff that uses TLSv1.0 for outgoing
communication by default, and that list is constantly growing, and that
is not just stuff running with JavaSE 1.6 or JavaSE 1.7.
Btw. lots of J2EE Servers are still on JavaSE 1.6, without the
non-public TLSv1.2-capable update.


We also had customer incidents about hardware stuff, they called it "RF Gun",
probably some RFID scanner, that seems to be limited to TLSv1.0 and
TLSv1.0 cipher suites (either 3DES-EDE-CBC-SHA or RC4-128).


I would really hate it to see the IETF enter the "planned/forced obsolence"
market, growing the dumpsters of electronic equipment that would still work
just fine, but has to be retired for the sole purpose of economic growth.


-Martin