Original text:
(EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF <del> to be used with the PSK MUST also be provisioned.  Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in RFC4086.  Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder. The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie-Hellman key establishment. </del>  2.3. the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs <del> established via the ticket mechanism (NSTMessage), this is the Hash used for the KDF on the connection where the ticket was established. </del>  For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is defined.  The server must ensure that it selects a compatible PSK (if used first. Any ticket MUST only be resumed with a cipher suite that has the same <del> KDF hash as that used to establish the original connection, and only if the client provides the same SNI value as in the original </del>  connection, as described in Section 3 of RFC6066. Note: Although the resumption master secret depends on the client's Expand functions as defined for HKDF RFC5869, as well as the functions defined below: <del> The Hash function and the HKDF hash are the cipher suite hash algorithm.  Hash.length is its output length in bytes.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. </del>  Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.

Reviewer comments:
HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm.

Revised text:
(EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF  <ins> hash algorithm to be used with the PSK MUST also be provisioned. Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in RFC4086.  Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder.  The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie- Hellman key establishment. </ins> 2.3. the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs  <ins> established via the ticket mechanism (NSTMessage), this is the KDF Hash algorithm on the connection where the ticket was established. </ins> For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is defined.  The server must ensure that it selects a compatible PSK (if used first. Any ticket MUST only be resumed with a cipher suite that has the same  <ins> KDF hash algorithm as that used to establish the original connection, and only if the client provides the same SNI value as in the original </ins> connection, as described in Section 3 of RFC6066. Note: Although the resumption master secret depends on the client's Expand functions as defined for HKDF RFC5869, as well as the functions defined below:  <ins> The Hash function used by Transcript-Hash and HKDF are the cipher suite hash algorithm.  Hash.length is its output length in bytes. Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero- length HashValue (indicated by "") is passed to HKDF-Expand-Label. </ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.