Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

[Christopher Wood <[e-mail]>]

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 <[e-mail]> 
> > *Sent:* Wednesday, July 8, 2020 1:03 AM
> > *To:* Jim Schaad <[e-mail]>; Mohit Sethi M <[e-mail]>; [e-mail]
> > *Cc:* [e-mail]
> > *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 <[e-mail]> Sent: Monday, July 6, 2020 3:10 AM To: Jim Schaad <[e-mail]>; draft-ietf-tls-external-psk- [e-mail] Cc: [e-mail] 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 [e-mail] https://www.ietf.org/mailman/listinfo/tls 
> > 
> > _______________________________________________
> TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>