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

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Jul 2020 15:07:27 -0700

Yes I did mean to send this to tls not cfrg - I had just sent mail there and
did not look hard.

> -----Original Message-----
> From: Christopher Wood <[email-masked]>
> Sent: Wednesday, July 1, 2020 2:09 PM
> To: Jim Schaad <[email-masked]>
> Subject: Re: [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00
> 
> (-lists)
> 
> Hi Jim,
> 
> Before replying, did you mean to cc tls@ instead of cfrg@?
> 
> Thanks!
> Chris
> 
> On Wed, Jul 1, 2020, at 2:02 PM, 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.
> >
> > * 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
> >
> >
> > _______________________________________________
> > Cfrg mailing list
> > [email-masked]
> > https://www.irtf.org/mailman/listinfo/cfrg
> >

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 6 Jul 2020 10:10:19 +0000

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?
>
> difficult to have a MUST in there when most of the items below are SHOULDs.
> * 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.

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)?

--Mohit

> 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
>
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 6 Jul 2020 09:06:57 -0700

> From: Mohit Sethi M <[email-masked]>
> Sent: Monday, July 6, 2020 3:10 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-tls-external-psk-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00
> 
> Hi Jim,
> 
> > me and I don't know if it was supposed to be one.  Are there mitigations that
> can be made?
> >
> 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.

> 
> 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

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 8 Jul 2020 08:03:24 +0000

Hi Jim,

On 7/6/20 7:06 PM, Jim Schaad wrote:

-----Original Message-----
From: Mohit Sethi M <[email-masked]><mailto:[email-masked]>
Sent: Monday, July 6, 2020 3:10 AM
To: Jim Schaad <[email-masked]><mailto:[email-masked]>; draft-ietf-tls-external-psk-
[email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00

Hi Jim,

can be made?

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?

--Mohit

Jim

--Mohit

Jim

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Jim Schaad <[email-masked]>
Date: Wed, 8 Jul 2020 07:45:13 -0700

From: Mohit Sethi M <[email-masked]> 
Sent: Wednesday, July 8, 2020 1:03 AM
To: Jim Schaad <[email-masked]>; Mohit Sethi M <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

Hi Jim,

 

-----Original Message-----
From: Mohit Sethi M  <mailto:[email-masked]> <[email-masked]>
Sent: Monday, July 6, 2020 3:10 AM
To: Jim Schaad  <mailto:[email-masked]> <[email-masked]>; draft-ietf-tls-external-psk-
[email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00
 
Hi Jim,

can be made?

 

[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

 

 
Jim

--Mohit

 
 
Jim

_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 9 Jul 2020 10:08:36 +0000

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.

--Mohit

On 7/8/20 5:45 PM, Jim Schaad wrote:

To: Jim Schaad <[email-masked]><mailto:[email-masked]>; Mohit Sethi M <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Jim,

-----Original Message-----

Hi Jim,

can be made?

   ZmxleG8=@realm cannot.

Jim

--Mohit

Jim

--Mohit

Jim

TLS mailing list