Original text:
3. Pre-shared Key (PSK) ciphersuites were first specified for TLS in <del> 2005.  Now, PSK is an integral part of TLS 1.3 specification [RFC8846].  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use- cases where pair-wise external PSKs with TLS have been used for authentication.  Note that the following list is non-exhaustive: </del>  Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known with fast open (0-RTT data). Internet of Things (IoT) and devices with limited computational <del> capabilities.  The Constrained Application Protocol (CoAP) RFC7252 is a web transfer protocol intended for resource-constrained IoT devices.  It suggests use of the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite with DTLS for securing communication between CoAP clients and servers.  RFC7925 defines TLS and DTLS profiles for resource-constrained devices and requires compliant devices to support the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite. Wireless Networks.  The Control And Provisioning of Wireless Access Points (CAPWAP) protocol specification RFC5415 mandates support of TLS_PSK_WITH_AES_128_CBC_SHA and TLS_DHE_PSK_WITH_AES_128_CBC_SHA ciphersuites with DTLS for authentication between the centralized Access Controller (AC) and distributed Wireless Termination Points (WTPs).  Use of PSK ciphersuites are Ooptional when securing RADIUS RFC2865 with TLS as specified in RFC6614.  The Generic Authentication Architecture (GAA) defined by 3GGP in TR 133 919 V12.0.0 (https://www.etsi.org/deliver/ etsi_tr/133900_133999/133919/12.00.00_60/tr_133919v120000p.pdf) </del>  mentions that TLS-PSK can be used between a server and user <del> equipment for authentication. </del>  Smart Cards.  The electronic German ID (eID) card supports <del> authentication of a card holder to online services with TLS-PSK. The German Federal Office for Information Security (BSI) describes how TLS-PSK authentication is utilized in the eCard-API-Framework specification (TR-03112-7:https://www.bsi.bund.de/SharedDocs/Downl oads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/TR- 03112-api_teil7.pdf?__blob=publicationFile&v=1).  EMV support for TLS-PSK I-D.urien-tls-psk-emv discusses how the identities and PSK attributes for TLS-PSK can be extracted from EMV cards. </del>  There are also use cases where PSKs are shared between more than two <del> entities.  Some examples are below: </del>  <del> Group chats.s In this use-case, the membership of a group is </del>  confirmed by the possession of a PSK distributed out-of-band to the group participants.  Members can then establish peer-to-peer connections with each other using the external PSK.  It is 3.1. Many industrial protocols assume that PSKs are distributed and <del> assigned by manually via one of the following approaches: typing the PSK into the devices, or via a web server masks (using a TOFU approach with a device completely unprotected before the first login did take place).  Many devices have very limited GUI functionalities.  For example, they only a numeric keypad or even only five buttons.  So when the TOFU approach is not suitable in a setting, entering the key would require typing it on a constrained HMI interface.  Moreover, PSK production lacks guidance, similar to user passwords. </del>  Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol. Secrets may be baked into or hardware or software device <del> components, such as secure enclaves.s </del>  3.2. another example, some systems require the provisioning process to embed application-specific information in either PSKs or their identities.  Identities may sometimes need to be routable, as is <del> currently under discussion for EAP-TLS. </del>  3.3. 5. <del> TODO </del>  6.

Reviewer comments:
Moved links in use cases sections to references and made the text somewhat more concise. Added some initial text on known attacks.

Revised text:
3. Pre-shared Key (PSK) ciphersuites were first specified for TLS in  <ins> 2005.  Now, PSK is an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs with TLS have been used for authentication.  Note that the following list is non- exhaustive: </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known with fast open (0-RTT data). Internet of Things (IoT) and devices with limited computational  <ins> capabilities.  RFC7925 defines TLS and DTLS profiles for resource- constrained devices and suggests the use of PSK ciphersuites for compliant devices. Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614. The Generic Authentication Architecture (GAA) defined by 3GGP </ins> mentions that TLS-PSK can be used between a server and user  <ins> equipment for authentication GAA. </ins> Smart Cards.  The electronic German ID (eID) card supports  <ins> authentication of a card holder to online services with TLS-PSK SmartCard. </ins> There are also use cases where PSKs are shared between more than two  <ins> entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova): </ins>  <ins> Group chats.  In this use-case, the membership of a group is </ins> confirmed by the possession of a PSK distributed out-of-band to the group participants.  Members can then establish peer-to-peer connections with each other using the external PSK.  It is 3.1. Many industrial protocols assume that PSKs are distributed and  <ins> assigned manually via one of the following approaches: typing the PSK into the devices, or via web server masks (using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place).  Many devices have very limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </ins> Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol. Secrets may be baked into or hardware or software device  <ins> components, such as secure enclaves. </ins> 3.2. another example, some systems require the provisioning process to embed application-specific information in either PSKs or their identities.  Identities may sometimes need to be routable, as is  <ins> currently under discussion for EAP-TLS-PSK. </ins> 3.3. 5.  <ins> The TLS external PSK authentication makes the implicit assumption that each PSK is known only to one client and one server, which do not switch roles with the same PSK. As discussed in use-cases, there are use cases where multiple clients or multiple servers share a PSK.  In such cases, TLS only authenticates the entire group.  Not only can a compromised group member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  This rerouting is a type of identity misbinding attack Sethi. Selfie attack Selfie is a special case of the rerouting attack against a group member that can act both as TLS server and client. In the selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint. </ins> 6.