Draft: draft-ietf-tls-external-psk-guidance

Commentary: Closes Issues and . 
 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 does n'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 .
Paragraph (version A):
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 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.
Paragraph (version B):
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, 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.
Paragraph (version B):
Section 5.1 of RFC4279 mandates that the PSK identity should be first
converted to a character string and then encoded to octets using UTF-
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
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.