Matthew Toseland wrote: > 1. Electronic but out-of-band or strongly encrypted. > Encrypted email, USB key etc. One way invite, no need for a return trip > unless > we need to update IP addresses. Generate a bundle including the node.
If we offer a method designed for encrypted email, people will use it with unencrypted email. > 2. Email, IM, etc. > Reliable way to transport even large refs. 38 or 70 bytes is easier than a > full ref because it can be more easily cut and pasted, doesn't need to be a > file transfer. Can be observed: the only way to do this securely is to have > an out of band password verification over the phone. This sounds like the best solution to me: a two-way exhange of pubkey hashes followed by OOB password verification. > 3. SMS, phone, print. > Must be really short! So much so that there is no possibility of > cryptographic > protection in the sense you have been using it. In that case we shouldn't offer this option. > IP + port + one time > generated password with enough entropy that it can't be brute forced in the > time available (say 10 characters base64). The attacker doesn't need to brute force the password, it's in plaintext! > Probably need to exchange both > ways, but maybe we can detect that somebody is trying to connect with a > specific invite. How can we distinguish the attacker from the invitee if we don't even have the invitee's IP address? > We must not sabotage security for those who do the right thing in order to > make life easier for those who don't! Agreed. We also shouldn't make it easy to do the wrong thing. > If we use user-entered passwords they would be less easy to identify (given > we > only allow one or two attempts). Just a thought. Hmm, good point. >> We can make it safe if we know which side is OOB and we also assume it >> can't be eavesdropped (eg your one-time invite proposal). But IMO that >> assumption is too risky. > > It depends on what the user is doing with the invite. If the user is sending > it in an encrypted email for example, it's fine. Right, but we don't know what the user's doing with the invite, so we have to make fail-safe assumptions. > I don't understand this. He doesn't know the password. He doesn't know the > hash of the password. Maybe I've misunderstood - I thought you were talking about not exchanging any pubkeys or passwords up front, just making the connection and then generating a password from the pubkeys exchanged during handshaking to make sure the connection hadn't been hijacked. If that was what you meant, here's the attack: Normal scenario: Alice connects to Bob. They exchange public keys during the handshake. They each hash the two public keys to obtain a password. Alice calls Bob or vice versa, and they check that the passwords match. Attack scenario: Alice connects to Mallory; Mallory connects to Bob. Alice and Mallory exchange public keys; Mallory and Bob exchange public keys. Mallory can use a different key on each side of the connection. When talking to Bob, she uses a key that will hash to the same password as Alice's key. When talking to Alice, she uses a key that will hash to the same password as Bob's key. So when Alice calls Bob or vice versa, the passwords match and they don't detect Mallory in the middle. This only works if Mallory can find a key for every possible password. But since the passwords are short, that's no problem: she can generate keys in advance for every possible password and pick a suitable one during the attack. > In some cases it is easy to do a secure exchange of invites. And everything > else seems to offer less security! Yes, everything's less secure than a secure exchange. But some people (IMO most people) won't make a secure exchange. So how do we maximise security for the majority without harming the minority? Pubkey hashes are more secure than passwords - both approaches are vulnerable to MITM, but passwords are also vulnerable to eavesdropping. OOB verification adds an extra layer of security for those who can be bothered to use it, and doesn't harm those who can't. > If we do a two-way exchange of pubkeys, > and one side is OOB, then an attacker can easily get connected to Alice but > not Bob, if we don't do any kind of OOB checking. Yes, MITM is possible if the pubkeys aren't exchanged or checked OOB. I'm not disputing that. But passwords are worse! Cheers, Michael
