Hi, I positive security property the document should definitely be mention is that PSKs are quantum-safe.
It can be argued how large the PSKs need to be, but even 128-bit PSKs are practically safe againts any foreseable quantum computer. Assuming someone builds a quantum computer that breaks RSA-2042 in hours. Even a cluster with millions of such computers would take hundred of years to brute-force a 128-bit symmetric key due to the fact that Grover's cannot be efficiently parallelizable. The complexity of Grover’s algorithms has also been proved to be optimal. I think the document should reference RFC 8773 in Section 6. Cheers, John -----Original Message----- From: John Mattsson <[email protected]> Date: Tuesday, 29 September 2020 at 09:58 To: "[email protected]" <[email protected]> Subject: Review of draft-ietf-tls-external-psk-guidance-00 Hi, I think is a very well written and very useful document. Comments and suggestions: - Abstract and Section 1 ”It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.” I think a very important objective of the document is to list the security properties not provided by PSKs. Suggestion: ”It lists TLS security properties provided by PSKs as well as security properties not provided by PSKs” - Section 4 “There are a number of obvious weaknesses here:” The are several more weaknesses/attacks possible when using a group PSK: - If PSK with DH is used, a group member that actively MITM the handshakes and all following traffic can eavesdrop or modify all traffic. - If PSK without DH is used, a group member that passively eavesdropped on the handshake can eavesdrop on or modify selected traffic. The list is now a mixture of a misbehaving group member and an attacker that compromised a group member. I would suggest that the list only talks about what a group member can to and then after the list states that “If a group member is compromised, then the attacker can perform all of the above attacks.” - Section 4 The are several more weaknesses/limitation (not attacks) when using a group PSK: - Revocation of individual group members is not possible without changing the authentication key for all members. - Network activity logging becomes less useful as messages can only be tied to the group and not individual members (or pair of members). There also several weaknesses/limitation that are hinted at in RFC 8446 which apply for two-party PSK authenticated connections. As this is a guidance document for all uses of external PSK, I think this document should bring up and expand upon: - Key Compromise Impersonation (KCI) resistance - Protection of endpoint identities - Forward secret with respect to long-term keys (psk_ke only) An additional security property given by signature authentication but not psk authentication is non-repudiation. As stated by Wikipedia “By this property, an entity that has signed some information cannot at a later time deny having signed it.” - Section 4 ”In addition to these, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as detailed below. The attack only works under certain assumption on the PSK identity and PSK. It does not work if the members use their identities “A”, “B”, “C” to create PSK identities or derive pairwise PSKs from a master group key. This should be clarified. - Section 5 ”As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire. Sending identifiers in cleartext lead to more weaknesses than linkability. Suggestion: ”As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire. Depending on the PSK identity, a passive attacker may also be able to identify the device, person, or enterprise running the TLS client or TLS server. An active attacker can also use the PSK identity to oppress handshakes or application data from a specific device/user by blocking, delaying, or rate-limit traffic. Section 6 ”Internet of Things (IoT) and devices with limited computational capabilities.” Limited memory and storage might be more important. Most devices today have computational capabilities to do asymmetric crypto, it is computational capabilities combined with latency requirement that is limiting. Section 6 ”[RFC7925] defines TLS and DTLS profiles for resource-constrained devices and suggests the use of PSK” This kind of makes is sounds like PSK is recommended over ECDSA. Both RFC 7252 and RFC 7925 treats ECDSA and PSK authentication equally. Section 6 ”There are also use cases where PSKs are shared between more than two entities. Some examples below (as noted by Akhmetzyanova et al.[Akhmetzyanova]):” These are not real use cases. Akhmetzyanova et. Al. clearly states that they are “providing two dummy systems”, I.e. these are not real systems. If there are no actual concrete use cases, the use of group PSK should maybe stay forbidden. Section 7.1 “OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.” I assume this is not the case for TLS 1.3 as the cipher suites in TLS 1.3 are independent of the authentication. Section 8 “It is NOT RECOMMENDED to share the same PSK between more than one client and server.” As described earlier in the document, group PSK violates both “peer authentication” and “downgrade protection property”. It also violates “secrecy of the session keys”. Two-party PSK already does not provide “Key Compromise Impersonation (KCI) resistance” and “Protection of endpoint identities” and psk_key does not provide “Forward secret with respect to long-term keys”. So when psk_ke is used in a group, the only property left is “Uniqueness of the session keys”... I am skeptical to introduce this new group PSK mode in an informal guidance document. If group PSK should be allowed, it should be more clearly declared as a new mode of TLS 1.3 and the security properties given and not given should be more clearly stated. Cheers, John _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
