Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
Tony Rutkowski <rutkowski.tony@gmail.com> Sun, 08 March 2020 14:47 UTC
Return-Path: <rutkowski.tony@gmail.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 1BFE73A0B56 for <tls@ietfa.amsl.com>; Sun, 8 Mar 2020 07:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HBr1O3wMYoEu for <tls@ietfa.amsl.com>; Sun, 8 Mar 2020 07:47:00 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840E63A0B55 for <tls@ietf.org>; Sun, 8 Mar 2020 07:47:00 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id h16so5223971qtr.11 for <tls@ietf.org>; Sun, 08 Mar 2020 07:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=iVQhgEaynfTdYFwmRqbEm7RHuy1Hc0b2G/7ILZMYtx0=; b=DlxPMT08tByBeSS7x0SgXQddgIM8q/abDz466ABounScgg7/1H+9/Og8QmZ1jHq6Fy wTr9VUaDQx4h21hAsAvjDllO4Gcfz2eEM3VYYUc2g9is+NXg9FYwSYFyv44od3SS7cME 7zuh6VWEGqI7ijFMZOVxfubu1LQM0zXI2WSF+LHRPdL5a9xF0ezojwdJy7DIoJU7JJ/i y5Yjw8aTZn/ptMyruUYRV7KSHANP5YGjJUGNEO8p6mF7n8augum2aCmu53ixwN7sh36H GlyZDAI+dJJDNroOrzo8Uy0JawPb0iU8UgN+MpANayIHLpGT/a6qSE99uJWXm0o/O0iw GIJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iVQhgEaynfTdYFwmRqbEm7RHuy1Hc0b2G/7ILZMYtx0=; b=TpxJPVE2loEf8mA+NXsQJgLPvAvD2JvOhIOTG2gZx8XTnfut8OYJ/fDPi/GPAzHY56 x1m6BCZkuHK0s65G6YlzcKwUBZWKQZ6v3l11ub1V+EXflJzLQdze1BupB89V5lQlDsHJ ICB8TU6aLmiV0uHpk0udYTwEKDOvZffgypgldZPlySMBqQh5oggPY0JPJxbNkQhVE+o1 GjaPza48RVUtXBjezGxOlYwfjbpYKqEYV0+w86GZb+O5MtR7rYjgu+4pdz8v1m946thA 1eTd6oxiowWxNSm1B+N/J9AHcuC09fakPgCOKAdoi6LcpCxD2HL50EV2kExbq2B65RzT Nsxg==
X-Gm-Message-State: ANhLgQ0V9W28egWGTZnaV2lTe7b7saU/8Gw5GxB/CNDe/60nb8pDzNwu QM9GKb8vWkbK1+pgZ32Zx9VXGSjiLtg=
X-Google-Smtp-Source: ADFU+vtXyc84FQ8l/OPPQp2AgKuv1Dpzy9l/Fdjxc0FJAJfjoZeHUdgkndMiIHsVr7o+6+j+XNt0cQ==
X-Received: by 2002:ac8:6a0b:: with SMTP id t11mr5290699qtr.111.1583678819216; Sun, 08 Mar 2020 07:46:59 -0700 (PDT)
Received: from [192.168.1.53] (pool-70-106-222-98.clppva.fios.verizon.net. [70.106.222.98]) by smtp.gmail.com with ESMTPSA id r46sm4868104qtb.87.2020.03.08.07.46.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Mar 2020 07:46:58 -0700 (PDT)
From: Tony Rutkowski <rutkowski.tony@gmail.com>
To: John Levine <johnl@taugh.com>, tls@ietf.org
References: <20200308022334.38A4315968F3@ary.qy>
Message-ID: <22080d70-f7d0-64a0-730e-ce9e98813e10@gmail.com>
Date: Sun, 08 Mar 2020 10:46:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200308022334.38A4315968F3@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uD0RHxBvBHcQpzeFTAigtYWPeSc>
Subject: Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS
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: Sun, 08 Mar 2020 14:47:02 -0000
Hi John, There are several orders associated with the settlement agreement - which is relevant here. You need a PACER account to access the docket. It was a complicated case that stretched over several years and cost ETSI a considerable amount of money - and involved several companies. Trueposition in its complaint alleged that the 3GPP SA standards were being manipulated through a conspiracy among the named parties to exclude Trueposition from the marketplace. The other parties must have incurred similar or greater expenses. The case reshaped the antitrust environment for standards setting bodies. See http://sullivanlaw.net/standard-setting-org-may-be-liable-for-antitrust-violations-of-member-leaders/. When the IETF role shifted from government/academic to public markets in the early 90s, the antitrust exposure increased significantly and the Internet Society purchased insurance to cover those in the IETF decision making process. Presumably, that still exists. Circa 2012, the IETF briefly visited the subject of antitrust culpability with a group that exchanged some email and hosted a BOF and then went quiet. See https://datatracker.ietf.org/wg/antitrust/about/ The Trueposition v. Ericsson case occurred after that point and was ground breaking. Antitrust law in this arena continues to evolve. Even individuals can be held accountable. Over the past year, the competition enforcement bodies on both sides of the Atlantic have made it clear they are concerned about anti-competitive actions in the internet sector and have established investigatory task forces. TLS is particular has a history going back to 1986 when the platform was first announced by the USG and the TLS specification was instantiated initially in the GOSIP standards and then in ITU/ISO standards. The are many TLS variants and platforms that produce revenue in the marketplace and bring competition to the industry. It seems best to avoid increased antitrust exposure by potentially restraining TLS competition via standards body activities and suggesting that certain platforms are "mandates." --tony On 2020-03-07 9:23 PM, John Levine wrote: > In article <b08c7a20-6949-4776-18d8-58f4c6e3970a@netmagic.com> you write: >> -=-=-=-=-=- >> >> One comment. Perhaps some caution might be advised in light of the >> antitrust court order in /Trueposition v. Ericsson/. Ref. Order in Case >> No. 2:11-cv-4574, (U.S. E.D. Pa, 14 Jul 2014). > That's a single page dismissing 3GPP from the case. Really? > > https://ia800306.us.archive.org/15/items/gov.uscourts.paed.426719/gov.uscourts.paed.426719.296.0.pdf > > R's, > John > >
- [TLS] 3GPP forbids support of MD5, SHA-1, non-AEA… John Mattsson
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Eric Rescorla
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Tony Rutkowski
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Tony Rutkowski
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… John Levine
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Tony Rutkowski
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Stephen Farrell
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… John Levine
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Tony Rutkowski
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Stephen Farrell
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Tony Rutkowski
- Re: [TLS] 3GPP forbids support of MD5, SHA-1, non… Joseph Salowey