Hi John, I hope you also check the text for addressing Selfie attacks in the pull request I created Chris. Some more comments below.
--Mohit On 10/11/19 10:38 AM, John Mattsson wrote: Thanks Mohit, Re-reading the Selfie paper I see that the authors define Client Alice and Server Alice as different members of the group. That makes things clearer. I think there are three cases: 1. Use cases where only Client Alice and Server Bob shares the PSK are not vulnerable to the Selfie attack. 1. Cases where Alice, Bob, and Caesar share an external PSK seem like misconfiguration, I assume TLS 1.3 just forgot to explicitly forbid them. 1. The interesting use case if where Client Alice, Server Alice, Client Bob, and Server Bob shares a PSK. That is a very valid use case and one that is currently deployed in several systems. To do as the Selfie authors suggest “A PSK MUST NOT be shared between more than one client and one server” seems way too drastic as is forbids 3 above. For 3 I think the Selfie attack can be very easily mitigated by forcing clients to check incoming ServerHello.random. I think something like the following updates for RFC 8446 would be enough: “A PSK MUST NOT be shared between more than two endpoints” What is a bug for you maybe is a feature for someone else. I wish we could put the requirement you suggest but there are several people who use PSKs that are shared by more than two nodes. “An endpoint receiving a ClientHello with PSK authentication MUST check that the ClientHello.random is not equal to a ClientHello.random that the endpoint previously sent and has not received a ServerHello.” This is one possible solution. In effect you are using the CleintHello.random and ServerHello.random as endpoint identifiers. However, it seems cleaner to not re-use random nonces from the cryptographic protocols as identifiers. Cheers, John From: TLS <tls-boun...@ietf.org><mailto:tls-boun...@ietf.org> on behalf of Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org><mailto:mohit.m.sethi=40ericsson....@dmarc.ietf.org> Date: Tuesday, 8 October 2019 at 21:08 To: Christian Huitema <huit...@huitema.net><mailto:huit...@huitema.net>, Christopher Wood <c...@heapingbits.net><mailto:c...@heapingbits.net>, Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com>, "TLS@ietf.org"<mailto:TLS@ietf.org> <tls@ietf.org><mailto:tls@ietf.org> Subject: Re: [TLS] Selfie attack Hi Christian, It was my poor attempt at explaining the attack. The attack can happen as long as a node sends outbound connections (as a TLS client) and accepts inbound connections (as a TLS server) with the same external PSK and identity. This is likely to happen in some form of group communication but not necessarily. In such a scenario, a malicious node Eve can fool Alice to open a connection to herself (hence the name Selfie). Admittedly, UKS/misbinding/selfie are somewhat hard to comprehend sometimes (at least for me). --Mohit On 10/8/19 9:51 PM, Christian Huitema wrote: On 10/8/2019 9:46 AM, Christopher Wood wrote: On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote: Hi Chris, For the benefit of the list, let me summarize that the selfie attack is only relevant where multiple parties share the same PSK and use the same PSK for outgoing and incoming connections. These situations are rather rare, but I accept that TLS is widely used (and sometimes misused) in many places. I may be getting old but the way Mohit writes it, it seems that the attack happens when the security of a group relies on a secret shared by all members of the group, and can then be compromised when one of the group members misbehaves. How is that a new threat? If groups are defined by a shared secret, then corruption of a group member reveals that shared secret to the attacker and open the path for all kinds of exploitation. In what sense is the "selfie" attack different from that generic threat? -- Christian Huitema _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
