Re: [TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt

[John Mattsson <[e-mail]>]

>discussion gets this time shorter.
Let’s hope so. I think quite a lot of things have happened since 2020. BSI decision that psk_ke can only be used until 2026, as well as a lot more discussion of exfiltration attacks and zero trust principles. I hope the working group can have a vote.

>Are there considerations how that affects similar simple OSCORE variants?
Yes, no difference there, OSCORE keyed without ECDHE or 3GPP AKA without ECDHE are equally bad security practice. In the case of OSCORE, the problem is rather the key management protocols like ACE rather than OSCORE, which is similar to the TLS record protocol. I have been equally critical of ACE. As soon as draft-ietf-ace-edhoc-oscore-profile is published I will write a contribution to 3GPP suggesting that use of RFC 9203 should be phased out asap.

John

From: Achim Kraus <[e-mail]>
Date: Friday, 30 December 2022 at 17:57
To: John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
Hi John,

I'm not sure, are there any new arguments for this since this discussion

https://mailarchive.ietf.org/arch/msg/tls/WoBwUCqEMcFhvIHN6neo5W4Urg4/

in 2020?
Maybe, if the new arguments are highlighted, the discussion gets this
time shorter.

"Malicious actors can get access to long-term keys in different ways"

Are there considerations how that affects similar simple OSCORE variants?

best regards
Achim

Am 30.12.22 um 09:58 schrieb John Mattsson:
> Hi,
>
> I submitted a new version of draft-mattsson-tls-psk-ke-dont-dont-dont.
> psk_ke is likely the weakest part of TLS 1.3 and German BSI has already
> made a deadline for its deprecation. It is long overdue to change the
> "Recommended" value for psk_ke to "N".
>
> This is a major update to earlier versions and adds a lot of background
> and motivation. The earlier version was never posted to the list. I plan
> to request presentation time at IETF 116.
>
> Cheers,
>
> John
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Friday, 30 December 2022 at 09:47
> *To: *John Mattsson <[e-mail]>, John Mattsson
> <[e-mail]>
> *Subject: *New Version Notification for
> draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
>
>
> A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
> has been successfully submitted by John Preuß Mattsson and posted to the
> IETF repository.
>
> Name:           draft-mattsson-tls-psk-ke-dont-dont-dont
> Revision:       02
> Title:          Key Exchange Without Forward Secrecy is NOT RECOMMENDED
> Document date:  2022-12-30
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt <https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt>
> Status:
> https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/ <https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/>
> Html:
> https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.html <https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.html>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont <https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont>
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-02 <https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-02>
>
> Abstract:
>     Massive pervasive monitoring attacks using key exfiltration and made
>     possible by key exchange without forward secrecy has been reported.
>     If key exchange without Diffie-Hellman is used, static exfiltration
>     of the long-term authentication keys enables passive attackers to
>     compromise all past and future connections.  Malicious actors can get
>     access to long-term keys in different ways: physical attacks,
>     hacking, social engineering attacks, espionage, or by simply
>     demanding access to keying material with or without a court order.
>     Exfiltration attacks are a major cybersecurity threat.  The use of
>     psk_ke is not following zero trust principles and governments have
>     already made deadlines for its deprecation.  This document updates
>     the IANA PskKeyExchangeMode registry by setting the "Recommended"
>     value for psk_ke to "N".
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls