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
>
>