On Monday 19 November 2007 23:10, Michael Rogers wrote: > Matthew Toseland wrote: > > We cannot assume there is no MITM either! > > We shouldn't assume it's impossible, but we have to weigh realistic > assumptions about attackers against realistic assumptions about users. I > believe that a lot of users will use email, IM, SMS and phone to > exchange refs, even if we warn them not to. So the question is, how do > we make that as secure as possible? The refs should be short, > innocuous-looking strings that don't contain any secret values, so it's > easy to exchange them over real-time channels, and hard to carry out a > MITM in real time.
SMS is not realistic for 70 or even 38 byte values. Neither is phone. Typing in even 38 bytes (from phone, SMS or print) is not likely to happen: it's significantly longer than the typical CD key. Out of band password verification is feasible for SMS and phone, and difficult to MITM in real time. Encrypted email, USB key etc are "ideal". So we are left with: 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. 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. 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. IP + port + one time generated password with enough entropy that it can't be brute forced in the time available (say 10 characters base64). Probably need to exchange both ways, but maybe we can detect that somebody is trying to connect with a specific invite. > > > *Something* must occur out > > of band, because MITM is trivial if you work at the ISP, or are otherwise > > closer to Alice than Bob is. > > I agree, we can only guarantee decent security to users who exchange > refs out of band. But if they fail to do so, we should still try to > provide semi-decent security. We must not sabotage security for those who do the right thing in order to make life easier for those who don't! > > > Our only other option is to assume that the > > attacker will not be able to identify the noderef quickly enough to > > substitute it or connect to it. > > Yup, this is the best we can do for users who won't or can't exchange > refs out of band. If we use user-entered passwords they would be less easy to identify (given we only allow one or two attempts). Just a thought. > > > Protocol questions: > > > > Can we make a two-way exchange safe when only one side is out of band? Even if > > we don't know which side it is? Do we need to specify it? Hoping that one > > side is OOB is probably a false sense of security... > > 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. > > > How easy can we make out of band post connect verification? E.g. exchange > > invites, then each node generates a short password which is exchanged out of > > band e.g. over the phone with a small maximum number of attempts? (Making > > certain assumptions about the state of voice recognition...) > > I don't believe a single password offers enough security: if there are, > say, 2^32 possible passwords then the attacker has to generate 2^32 > keypairs to find one that will result in the same password as the > genuine keypair, making a MITM undetectable. 2^32 is small enough for > the attacker to generate the keypairs in advance and pick a suitable one > in real time. I don't understand this. He doesn't know the password. He doesn't know the hash of the password. > > > Is it reasonable to offer (advanced?) users the choice of indicating that an > > invite is unobservable because they sent it by encrypted email, delivered it > > by hand etc? > > To be honest I don't understand what would be gained by doing so - > security-minded users will do a two-way exchange of pubkey hashes if > they know it's necessary. It's the other users we need to worry about. In some cases it is easy to do a secure exchange of invites. And everything else seems to offer less security! 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. Now, maybe Bob would notice - but more likely he'd write it off as some wierd firewall/freenet issue. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071120/9c320b67/attachment.pgp>
