Original text:
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH <del> exchange for forward secrecy.  As discussed in sec-properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided.  If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed.  Note that these mechanisms do not necessarily follow the same architecture as the ordinary process for incorporating EPSKs described in this draft. </del>  Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for <del> any operation.  TLS version 1.3 RFC8446 follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1> in the specification).  RFC8446 also requires that the PSK identities are at least 1 byte and at the most 65535 bytes in length.  Although RFC8446 does not place strict requirements on the format of PSK identities, we do however note that the format of PSK identities can vary depending on the deployment: </del>  The PSK identity MAY be a user configured string when used in protocols like Extensible Authentication Protocol (EAP) RFC3748.

Reviewer comments:
Closes Issues and .
NAME does this address your comments in ?
Yep, looks great!
(This question is copied from my email with greater context from the draft.) Section 7.1 is the following: "Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy. As discussed in Section 4, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided. If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed. Note that these mechanisms do not necessarily follow the same architecture as the ordinary process for incorporating EPSKs described in this draft." Where was the ordinary process for incorporating EPSKs described? Is "incorporating" a PSK the same as "provisioning" one? If so, several ways were described. What's the problem with these mechanisms (e.g. PAKE) having a different architecture from these ordinary processes? Are they not compatible?
Perhaps this refers to the process in I-D.ietf-tls-external-psk-importer, which takes a provisioned PSK and performs a transformation on it to ensure that it is unique? That can then be incorporated into the key schedule. This is different from the PAKE process, which doesn't pass through the ePSK importer mechanism. Not sure if that was the original intention, but if so we should write clarifying text.
From : Good suggestion. Let's clarify! My interpretation was that it speaks of the future :-) We can clarify this. That seems reasonable. I'll propose text. Dear WG, I've taken a look at the draft and I think while its discussion of the properties and limitations of the external PSKs are good, I think the recommendations in section 7 could use some minor editorial work. In particular "SHOULD be combined with a DH exchange for forward secrecy." I would like to see rephrased to make clear that this is about the TLS PSK Key Exchange Mode. It wasn't immediately clear to me on first read, especially given the next sentence is (maybe) about key establishment outside of TLS. "If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed". I have some questions about the meaning of this sentence. If it's about potential future additions to TLS ciphersuites, then it should be more clear that this doesn't currently exist and will in the future. If it's about designing an ad-hoc key distribution mechanism to be run one time ahead of PSK TLS, then I think we should say so more clearly and provide guidance on how to do this and think through the implications. Section 7.1.1. While it's a good idea to compare byte by byte, humans entering PSK identifiers may run into trouble due to all the ways visually identical strings may not actually be identical. It might be worth calling this out as a consideration. Sincerely, Watson Ladd

Revised text:
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH  <ins> exchange, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3, for forward secrecy.  As discussed in sec- properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided. If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed.  Note that no such mechanisms have yet been standardised, and further that these mechanisms will not necessarily follow the same architecture as the process for incorporating EPSKs described in I-D.ietf-tls-external-psk- importer. </ins> Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for  <ins> any operation.  When PSK identites are configured manually it is important to be aware that due to encoding issues visually identical strings may, in fact, differ. TLS version 1.3 RFC8446 follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1> in the specification).  RFC8446 also requires that the PSK identities are at least 1 byte and at the most 65535 bytes in length.  Although RFC8446 does not place strict requirements on the format of PSK identities, we do however note that the format of PSK identities can vary depending on the deployment: </ins> The PSK identity MAY be a user configured string when used in protocols like Extensible Authentication Protocol (EAP) RFC3748.