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

[Mohit Sethi M]

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:


From: Mohit Sethi M 

Sent: Wednesday, July 8, 2020 1:03 AM
To: Jim Schaad ; Mohit 
Sethi M ; 
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 


Sent: Monday, July 6, 2020 3:10 AM

To: Jim Schaad ; 
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 m

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

[Carrick Bartle]

Hi everyone,

A few thoughts on draft-ietf-tls-external-psk-guidance-00:

Isn’t the rerouting attack described in Section 4 not possible if "A" uses the 
SNI extension and "C" aborts the connection on mismatch? If so, it might be 
worth mentioning that as a potential mitigation (as the Selfie paper does).

> "C" has completed the handshake, ostensibly with "A".
"C" did in fact complete the handshake with "A." (Without mistaking it for some 
other endpoint or something.)

> Low entropy keys are only secure against active attack if a PAKE is used with 
> TLS.
Maybe cite a document that contains a recommended way of using PAKEs with TLS 
(e.g. draft-sullivan-tls-opaque-00)?

>  Applications should take precautions when using external PSKs to mitigate 
> these risks.
What sort of precautions should they take?

> Preventing this type of linkability is out of scope, as PSKs are explicitly 
> designed to support mutual authentication.
Isn't mutual authentication, in general, orthogonal to linkability? 
Certificates, for example, are encrypted in TLS 1.3, and so cannot be linked 
across connections.

> Below, we list some example use-cases where pair-wise external PSKs with TLS 
> have been used for authentication.
I assume "pair-wise" here means a PSK is shared between only one server and one 
client, but this the term "pair-wise" hasn't been associated with that concept 
in this document, it's not completely clear. Since "pair-wise" is used twice in 
the document, maybe define it when the concept is first introduced.

> primarily for the purposes of supporting TLS connections with fast open 
> (0-RTT data)
I've only ever heard "fast open" used in the context of TFO, which is distinct 
from (albeit similar to) 0-RTT. Using "fast open" to refer to 0-RTT sounds like 
it's conflating terms. Shouldn't "early data" be used here instead of "fast 
open"?

> In this use-case, resource-constrained IoT devices act as TLS clients and 
> share the same PSK.  The devices use this PSK for quickly establishing 
> connections with a central server.  Such a scheme ensures that the client IoT 
> devices are legitimate members of the system.
If the IoT devices only talk to a central server and not each other, why do 
they all need the same PSK?

> To perform rare system specific operations that require a higher security 
> level, the central server can request resource-intensive client 
> authentication with the usage of a certificate after successfully 
> establishing the connection with a PSK.
If you're going to authenticate with a cert, why bother preceding that with an 
authentication with a PSK?

> 6.1.  Provisioning Examples
This section contains a list of ways to provision PSKs, but mostly without any 
commentary or discussion. Are these methods good? Bad? Are there any pitfalls? 
If so, how can one guard against them?

> Moreover, PSK production lacks guidance unlike user passwords.
Isn't that precisely the point of this draft? Seems unnecessary to mention. (Or 
it might be better to move this point to the intro as a motivating factor of 
this document.)

> PSK provisioning systems are often constrained in application-specific ways.  
> For example, although one goal of provisioning is to ensure that each pair of 
> nodes has a unique key pair, some systems do not want to distribute pair-wise 
> shared keys to achieve this.
Why not? What application-specific constraint would warrant that?

> some systems require the provisioning process to embed application-specific 
> information in either PSKs or their identities.
Is it really a good idea to embed data in the PSK itself? Does that not 
diminish the entropy of the PSK? Why is it not sufficient to put that sort of 
information in the identity?

> Identities may sometimes need to be routable, as is currently under 
> discussion for EAP-TLS-PSK.
What does it mean for an identity to be "routable"? Also, EAP-TLS-PSK needs a 
citation link. I'm not sure which document it's referring to.

> Applications MUST use external PSKs that adhere to the following requirements:
I think you mean "If an application uses external PSKs, the PSKs MUST adhere to 
the following requirements." Otherwise it sounds like you're saying every 
application must use an external PSK.

> Each PSK SHOULD be derived from at least 128 bits of entropy
Recommend a particular method for doing that?

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

>3.  Nodes SHOULD use external PSK importers 
> [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of TLS 
> client and server.
Why?

> OpenSSL