On Thu, Jul 9, 2020, at 3:08 AM, Mohit Sethi M wrote: > Top posting so that others on the list can chime in. > > While discussing the privacy implications of external PSK identities, > Jim Schaad in his email below recommends that we could describe > techniques for importing external PSK identities (that may be typed in > by the user). He suggests that we could consider using a construct > based on one way hash functions so that the typed-in external PSK > identity (presumably with not so good privacy properties) are never > sent on the wire.
This is being discussed here: https://github.com/tlswg/external-psk-design-team/issues/36 I think we ought to omit any particular recommendation, especially in the absence of analysis. What do others think? Thanks, Chris > > --Mohit > > On 7/8/20 5:45 PM, Jim Schaad wrote: > > > > > > > > *From:* Mohit Sethi M <mohit.m.se...@ericsson.com> > > *Sent:* Wednesday, July 8, 2020 1:03 AM > > *To:* Jim Schaad <i...@augustcellars.com>; Mohit Sethi M > > <mohit.m.se...@ericsson.com>; draft-ietf-tls-external-psk-guida...@ietf.org > > *Cc:* tls@ietf.org > > *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 > >> <mohit.m.se...@ericsson.com> Sent: Monday, July 6, 2020 3:10 AM To: Jim > >> Schaad <i...@augustcellars.com>; draft-ietf-tls-external-psk- > >> guida...@ietf.org Cc: tls@ietf.org Subject: Re: Review of > >> draft-ietf-tls-external-psk-guidance-00 Hi Jim, Thanks for the review. A > >> clarifying question in-line. On 7/2/20 12:02 AM, Jim Schaad wrote: * 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 @realm can safely be reused, while the NAI ZmxleG8=@realm 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: my_strong_secret_psk_with_amazon_server? > > > 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 mohit.ietf and mohit.amazon 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 > >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
