Subject: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS

From: John Mattsson <[email-masked]>
Date: Sat, 7 Mar 2020 00:02:58 +0000

Hi,

I am happy to report that 3GPP just took the decision to forbid support of MD5 and SHA-1, as well as all non-AEAD and non-PFS cipher suites in TLS. The changes apply to all Rel-16 3GPP systems that use TLS and DTLS, which are quite many.

3GPP had already mandaded support of TLS 1.3, forbidden support of TLS 1.1, and mandated minimum key lengths of 2048 for RSA/FFDH and 255 for ECC. 3GPP will likely mandate support of DTLS 1.3 soon after it has been published.

I hope this inspire other organisations to do the same.

The changes [2][3] were approved today and an updated complete version of the new 3GPP TLS profile can be found here [1]. Any comments or suggestions on the 3GPP TLS profile are very welcome.

Cheers,
John

[1] https://github.com/EricssonResearch/CBOR-certificates/raw/master/3GPP%20TLS%20Profile%206%20march%202020.pdf

[2] http://www.3gpp.org/ftp/TSG_SA/WG3_Security/TSGS3_98e/Docs/S3-200332.zip

[3] https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_98e/Inbox/Drafts/draft_S3-200333-r1.doc

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Mar 2020 18:57:40 -0800

This is great news. Thanks for helping make it happen!

-Ekr

On Fri, Mar 6, 2020 at 4:03 PM John Mattsson <john.mattsson=
[email-masked]> wrote:

> Hi,
>
> I am happy to report that 3GPP just took the decision to forbid support of
> MD5 and SHA-1, as well as all non-AEAD and non-PFS cipher suites in TLS.
> The changes apply to all Rel-16 3GPP systems that use TLS and DTLS, which
> are quite many.
>
> 3GPP had already mandaded support of TLS 1.3, forbidden support of TLS
> 1.1, and mandated minimum key lengths of 2048 for RSA/FFDH and 255 for ECC.
> 3GPP will likely mandate support of DTLS 1.3 soon after it has been
> published.
>
> The changes [2][3] were approved today and an updated complete version of
> the new 3GPP TLS profile can be found here [1]. Any comments or suggestions
> on the 3GPP TLS profile are very welcome.
>
> Cheers,
> John
>
>
> [1]
> https://github.com/EricssonResearch/CBOR-certificates/raw/master/3GPP%20TLS%20Profile%206%20march%202020.pdf
>
> [2]
> http://www.3gpp.org/ftp/TSG_SA/WG3_Security/TSGS3_98e/Docs/S3-200332.zip
>
> [3]
> https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_98e/Inbox/Drafts/draft_S3-200333-r1.doc
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 7 Mar 2020 10:35:39 -0500

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

--amr

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 7 Mar 2020 11:16:47 -0500

--amr

On 2020-03-06 7:02 PM, John Mattsson wrote:
> [1]https://github.com/EricssonResearch/CBOR-certificates/raw/master/3GPP%20TLS%20Profile%206%20march%202020.pdf
>
> [2]http://www.3gpp.org/ftp/TSG_SA/WG3_Security/TSGS3_98e/Docs/S3-200332.zip
>
> [3]https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_98e/Inbox/Drafts/draft_S3-200333-r1.doc
>

---

From: "John Levine" <[email-masked]>
Date: 7 Mar 2020 21:23:34 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

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

>> I am happy to report that 3GPP just took the decision to forbid support of MD5 and SHA-1, as well as all non-AEAD and non-PFS cipher suites in
>TLS. The changes apply to all Rel-16 3GPP systems that use TLS and DTLS, which are quite many.
>>
>> 3GPP had already mandaded support of TLS 1.3, forbidden support of TLS 1.1, and mandated minimum key lengths of 2048 for RSA/FFDH and 255 for
>ECC. 3GPP will likely mandate support of DTLS 1.3 soon after it has been published.
>>
>> The changes [2][3] were approved today and an updated complete version of the new 3GPP TLS profile can be found here [1]. Any comments or
>suggestions on the 3GPP TLS profile are very welcome.
>>
>> Cheers,
>> John
>>
>>

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 8 Mar 2020 10:46:58 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 8 Mar 2020 14:56:21 +0000

On 08/03/2020 14:46, Tony Rutkowski wrote:
> initially in the GOSIP standards and then in ITU/ISO standards.

That's false. I've seen it repeated a few times but it
remains false. Mostly, this falsehood seems to be repeated
in tandem with efforts one could interpret as attempts
to create FUD about Internet related security.

TLS started in the IETF as a compromise between Netscape
and Microsoft proposals for how to secure HTTP.

X.509 started as part of X.400, then X.500 and is used by
TLS. Today, I would bet almost all implementers never need
to look beyond RFC5280 for X.509. And I hope it stays that
way until we somehow figure out how to retire X.509.

S.

---

From: "John Levine" <[email-masked]>
Date: 8 Mar 2020 12:29:43 -0400

In article <[email-masked]> you write:
>to create FUD about Internet related security. ...

If anyone wants to confirm that this is FUD, you can find the 
case documents here:

 https://www.courtlistener.com/docket/4369665/trueposition-inc-v-lm-ericsson-telephone-company/

R's,
John

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 8 Mar 2020 12:35:56 -0400

Stephen,

It is not false.  It is simply largely unknown because of subsequent 
IETF related narratives that choose to omit the history.  The documents 
are available online - although portions remain classified.  A request 
is pending for their declassification and release.  You can find some of 
the details in the links in this article. 
http://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/

Ruth Nelson - who led some of the important components - appeared at 
last October's NSA Crypto History Symposium.  She filled in some of the 
details and the work was recognized by those there. Whit was also there 
also there and gave a great presentation. Unfortunately, women in this 
field seem not to get the credit they deserve.

--tony

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 8 Mar 2020 16:59:40 +0000

On 08/03/2020 16:35, Tony Rutkowski wrote:
> It is not false. 

We disagree. SDNS != TLS. TLS was SSL with the middle
S standing for socket, which wasn't part of SDNS or
GOSIP that I recall.

> It is simply largely unknown because of subsequent
> are available online - although portions remain classified.  

Hah, that's funny. And with the classified documents
defense of the falsehood, I'm done debunking this.

S.

> A request

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 8 Mar 2020 15:41:24 -0400

Hi Stephen,

Amusing attempt to rewrite history.  Your disagreement means nothing, 
fortunately, and folks can claim FUD all they want.

The reality is that the actions in this group are facing increasing 
exposure to antitrust, tort, consumer protection, and tax-related 
actions.  If you don't want to be cautious, then lawyer up...or at least 
get ISOC to buy you more insurance. :-) Oh, is it clear who is covered 
by the insurance?

cheers,
tony

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 8 Mar 2020 14:10:48 -0700

Hi Folks.

This isn't a topic for this working group list.  Please take the discussion
elsewhere.

Thanks,

Joe