>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 <[email protected]>
Date: Friday, 30 December 2022 at 17:57
To: John Mattsson <[email protected]>
Cc: [email protected] <[email protected]>
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: *[email protected] <[email protected]>
> *Date: *Friday, 30 December 2022 at 09:47
> *To: *John Mattsson <[email protected]>, John Mattsson
> <[email protected]>
> *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
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to