Original text:
information about the external PSK or its identifier by virtue of it appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same <del> external PSK on the wire.  Applications should take precautions when using external PSKs to mitigate these risks. </del>  In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

Reviewer comments:
Related issue and discussion: URL
NAME please let me know what you think of the suggestion above!
NAME I disagree that those analyses are out of scope since they concern the use of external PSKs, but if "out of scope" is understood to be synonymous with "we're not going to do it," then this change is fine. :)
Indeed -- "out of scope for this document" means "we're not doing it in this document."
Carrick Bartle in her review writes: What sort of precautions should they take? Do we want to make any recommendations. Jim Schaad provided some recommendation on the mailing list: URL [JLS] There are going to be three different cases for external PSK identities: The identity if factory provisioned and carried in a file to the server, the identity is factory provisioned and read by the user from the device, and it is hand chosen. The first two cases can definitely be randomized. I don’t know that having a minimum length makes any difference. This is not exactly a cryptographic property. Another thing that might be done would be analogous to the PSK importer document and apply a one way hash from the typed in value to the value that is sent over the wire so on the wire it is just a random set of bytes.
nit: s/his/her :-)
Isn't there a fourth case JLS didn't mention, namely some other out-of-band provisioning over a secure connection? In that case, a new PSK could be provisioned after each use. (This might seem silly, but I've seen two separate use-cases for this.) Alternatively, in any of those cases, is it feasible to do some sort of ratcheting? (This is sort of expanding on the last sentence in JLS's paragraph.)
Hmm, NAME there is. I'm wary about writing down any sort of recommendation here, though, as they would probably require analysis. (In contrast to the recommendations about PSK length, for which we understand the requirements quite well, I don't think we have a good way to reason about techniques to deal with external PSK privacy... yet.)
In that case, I'm in favor of deleting this line: "Applications should take precautions when using external PSKs to mitigate these risks." Mentioning precautions we don't describe is less helpful than not mentioning them at all (since it's confusing). Even better though would be to state that such precautions are an open problem that require analysis.
Yep, that seems reasonable to me!
NAME - At this point I would implement the - lets roll over the PSK on each use into the case of issuing tokens and just void the PSK (and token) on the first usage.
NAME What type of analysis are you looking for on this? It hardly needs to have a cryptographic analysis since this is not a cryptographic property. Are you looking for some analysis that the input and output cannot be correlated?
Minimally, yes.
While it may be odd - you could ask the PSK importer document to do this and just note the privacy problem here.
NAME would you mind proposing text (preferably for this document)?
NAME What sort of tokens are you referring to?
NAME In this case the token should be ticket. I have token on the brain because that is what we use for a similar idea in ACE.
NAME NAME do you think this issue is resolved?
Yep!
Excellent -- closing as is! Sent: Wednesday, July 8, 2020 1:03 AM To: Jim Schaad ; Mohit Sethi M ; EMAIL Cc: EMAIL Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 Hi Jim, On 7/6/20 7:06 PM, Jim Schaad wrote: -----Original Message----- From: Mohit Sethi M Sent: Monday, July 6, 2020 3:10 AM To: Jim Schaad ; draft-ietf-tls-external-psk- EMAIL Cc: EMAIL Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00 Hi Jim, Thanks for the review. A clarifying question in-line. In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations that can be made? In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance. Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. I think you are referring to the PSK identity and not to the PSK. As you know, the Network Access Identifiers (NAIs) used in EAP typically need the domain name suffix for roaming, federation, etc. This is true, it is also true that EAP is very strong on saying that if you have a choice, always send an anonymous version of the NAI if you have to do it in the clear. This means that the domain can be used for correlation, but you do not have the full identity for that purpose. I think that the EMU group is going to need to look at what level of privacy protection it is going to desire when using a PSK, but in that case there is no need for having a domain suffix as that information is provided elsewhere. This might require keeping the TLS tunneling as an option to deal with passive attacks. You are absolutely right about the preference for using anonymous identities. draft-ietf-emu-eap-tls13 currently says the following about resumption: It is RECOMMENDED to use a NAIs with the same realm in the resumption and the original full authentication. This requirement allows EAP packets to be routable to the same destination as the original full authentication. If this recommendation is not followed, resumption is likely to be impossible. When NAI reuse can be done without privacy implications, it is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication. E.g. the NAI NAME can safely be reused, while the NAI ZmxleG8=NAME cannot. This document and the ensuing discussion pertains only to external PSKs and external PSK identities. I think I incorrectly used the word "issue" in my previous email as a more correct choice would have been "agree/establish" (i.e. the server and client agree on an external PSK and an external PSK identity). RFC 8446 doesn't place any restrictions on external PSK identities (other than the fact that they are at least 1 byte). If we are going to discourage the use of domain names in external PSK identities, would that be sufficient? What prevents me from using an external PSK identity of the type: mystrongsecretpskwithamazonserver? I am not sure if we should recommend randomized external PSK identities of a certain minimum length. Perhaps it might be better to add a disclaimer about the privacy loss from carelessly chosen external PSK identities? [JLS] There are going to be three different cases for external PSK identities: The identity if factory provisioned and carried in a file to the server, the identity is factory provisioned and read by the user from the device, and it is hand chosen. The first two cases can definitely be randomized. I don’t know that having a minimum length makes any difference. This is not exactly a cryptographic property. Another thing that might be done would be analogous to the PSK importer document and apply a one way hash from the typed in value to the value that is sent over the wire so on the wire it is just a random set of bytes. Jim --Mohit I would like to understand the nature of the resulting privacy loss. Is it that a passive attacker can now easily determine the server which issued the PSK identity (and the server where it will eventually be used)? While it I true that at least some of the privacy information has already been leaked in the PSK case, you know the address that is being talked to and the PSK identity that is passed. If you look at using thigs like ESNI, doing this would appear to potentially give away the very information that is being hidden in that case. The other problem with having domain based KIDs is that you could easily get some amount of correlation between the KIDs that are assigned in different domains. You could end up with URL and URL and it would be quite reasonable to assume that both of those identities are going to be for the same entity, just in different domains. Jim --Mohit Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe. Jim TLS mailing list EMAIL URL

Revised text:
information about the external PSK or its identifier by virtue of it appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same  <ins> external PSK on the wire.  Techniques for mitigating these risks require analysis and are out of scope for this document. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can