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.
> *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. > 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. > 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. > 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. > 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. Cheers, Michael
