On Sun, Apr 18, 2004 at 11:13:27AM +1000, Duane spake thusly: > But have you ever met face to face with an employee from a CA and > verified they were an employee or just grabbed the info from their > website and assumed there was no man in the middle attack sending you an > alternate key/fingerprint (yes I know this is highly unlikely however > high profile targets would be possible at some point, how lucky do you > feel? :)
No, I haven't. And you are right it is highly unlikely. Knowing that someone was going to want to get a key signed, putting the bogus info where they would find it, tricking someone into calling you and giving them a bogus key, etc. is all very difficult. I think we are going to have to give up the notion of 100% security and accept the very small chance (orders of magnitude smaller than now) of someone being fooled if we ever want to get this stuff deployed. > If we make up some number, I have seen figures for websites can't seem > to find them at present, anyways say a TLS/SSL operation uses 8x more > CPU power then a non-TLS connection, this means if you are running a > voip to pstn service or in an office environment with a large amount of > handsets/calls you need 8x more servers or 8x less clients so there is > definitely a cost involved there even if CPUs etc are cheaper... Since most cpu's out there in the world spend 80% of their time idle doing nothing anyway I don't think it would be quite this bad. :) > As for hostname matching, you run an enum check on a phone number, it > returns a URL... say iaxtel.com... you connect to it and it then says Ah. I haven't given too much thought about how it interacts with phone systems yet. I'll ponder this one. > Umm just a side note, we have a working enum.164 website/dns ( > http://e164.org ) service that now does pstn verification (due > diligence) by calling you and reading out a pin number, currently a > little rough and we need a few IVR records (which will within the next > few days), and need to update the documentation on the website, however > it does seem to work reasonably well... Very cool. I am reading up on this stuff. > Most HTML emails have a non-html component as well, and the amount of > people that dislike html emails I don't see this as a good comparison ;) Indeed. It was just an example of the mail vendors successfully forcing something on everyong. > You can't enforce crypto from a MTA/MUA point of view, there is a whole > bunch of complications if you force certificates on people like you'd > have to get them a public/private key pair and then well it wouldn't be > so private... That is fine. The mail administrator can read everything they type into the server anyhow. He can bug their keyboard if he wants. > The reason they would is to beat the virus/spam filters currently in > operation at a MTA level, they would be rendered useless, at present all > you need is a valid email address to get a certificate issued from a CA > with their root certificate in most/all current email clients... I doubt they would because it would make spamming much more expensive. Some might but it makes it much less likely and kills their profits which removes the incentive. -- Tracy Reed The attachment is a digital signature. http://copilotconsulting.com More info: http://copilotconsulting.com/sig
pgp00000.pgp
Description: PGP signature
