Re: Keysigning @ CFP2003
On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: It's rather efficient if you want to sign a large number of keys of people you mostly do not know personally. Right, but remember that knowing people personally was supposed to be part of the point of vouching for their identity to others. I know this guy. We spent a couple years working on X together. is different in kind from I met this guy once in my life, and he had a driver license that said his name was mike. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 10:02 PM 3/24/2003 +, David Wagner wrote: You could take your argument even further and ask whether any crypto was needed at all. After all, most attacks have worked by compromising the endpoint, not by sniffing network traffic. I'll let you decide whether to count this as a success story for SSL, or as indication that the crypto wasn't needed in the first place. (I'm a little skeptical of this argument, by the way, but hey, if we're playing devil's advocate, why not aim high?) I assert that there may be more sites that transmit credit card numbers w/o crypto, as sites that use SSL (although transaction rates are highly skewed so they even if it were ten times the number of sites, it might represent fewer actual transmissions). I don't have actual numbers, but I am aware of significant number of sites. However, I would contend that harvesting numbers from end-point merchant files has significantly higher return (ROI, expected results for the effort) than any sort of network evesdropping ... and that it is practically impossible to provide the necessary armoring as countermeasure for this vulnerability; end point attacks by either insider and outsider (historically, insider attacks on financial infrastructure have represented vast majority of incidents. While it may be possible to do a single armored site it isn't practical to do a million such sites (for one thing, people make too many mistakes) ... as per previous ref to security proportional to risk (and the merchant file risk is proportional to the credit limits of the accounts, not the specific merchant transaction). I would expect that network evesdropping would be employed where vulnerability was something other than kind of fraud do'able by attacking the end-point merchant file. Note however, skimming (various kinds of electronic non-electronic recording) does go on in the physical world. Part of the issue may be that the target object (account number) has much lower occurance in general internet traffic (physical world skimming involves traffic that is almost solely account numbers). If you just have to skim, there are some number of points that are much more target rich environments (better fraud ROI) than internet traffic. There is some phrase that if the only thing you know how to use is a hammer, then every solution may involve a nail. The fundamental problem with account numbers is that they are effectively a kind of shared-secret acquiring/harvesting the numbers enables fraud. There are significant number of business processes that require the availability of the account numbers. This is one of the reasons for the end-point merchant files and also why SET (with significantly more complex crypto infrastructure and essentially only, also addressing data in-flight) offered very little additional over what my wife and I were involved with setting up the original SSL for e-commerce. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 The point of x9.59 wasn't to add even more layers of crypto and information hiding to protect these shared-secrets but to change the business model so that the account numbers were no longer shared-secrets. X9.59 uses simple digital signature for authenticated payment transactions and a business rule that account numbers used in x9.59 transactions can't be used in non-authenticated payment transactions. http://www.garlic.com/~lynn/index.html#x959 aka just by evesdropping an x9.59 transactions or harvesting account numbers used in x9.59 transactions doesn't enable a crook to initiate a fraudulent payment transaction. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL
- Original Message - From: Nomen Nescio [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 24, 2003 1:20 PM Subject: Re: Brumley Boneh timing attack on OpenSSL Regarding using blinding to defend against timing attacks, and supposing that a crypto library is going to have support for blinding: - Should it do blinding for RSA signatures as well as RSA decryption? If you are a client, and you manually control the signature generation (like you use PGP to sign email messages), I wouldn't implement blinding. But if you are a server (or a client that automatically responds to requests) that signs message for some reason, and you receive many requests, I would. RSA decryption, yes for servers. - How about for ElGamal decryption? - Non-ephemeral (static) DH key exchange? Again, if you are automatically answer to requests, yes I would. In the Freedom network, servers had non-ephemeral keys and did a DH key exchange with clients (client side used ephemeral keys and was anonymous), we implemented blinding on the server side to counter timing attacks because we had a hunch that they could work over network connections. - Ephemeral DH key exchange? No, I wouldn't. I would be very surprised if you could do timing attacks on one execution of a modulo exponentiation, unless there is some way to trick a server in using the same secret on different inputs, even though it's suppose to do ephemeral DH. - How about for DSS signatures? Yes if you automatically answer to requests. Paul Kocher's initial paper on the subject explicitly mentions DH, RSA and DSS. If there is a possibility that you can be used as an oracle, and you have a static key, you should be careful. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Monday 24 March 2003 19:26, bear wrote: On Mon, 24 Mar 2003, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) There have, however, been numerous MITM attacks for stealing or eavesdropping on email. A semi-famous case I'm thinking of involves a rabid baptist minister named fred phelps and a topeka city councilwoman who had the audacity to vote against him running roughshod over the law. He set up routing tables to fool DNS into thinking his machine was the shortest distance from the courthouse where she worked to her home ISP and eavesdropped on her mail. Sent a message to every fax machine in town calling her a Jezebellian whore after getting the skinny on the aftermath of an affair that she was discussing with her husband. I love it! Then, I'm wrong on that point, we do in fact have some aggressive MITMs occuring in some mediums over the net. Steve Bellovin pointed one out, this is another. Which gets us to the next stage of the analysis (what did they cost!). And as for theft of credit card numbers, the lack of MITM attacks directly on them is just a sign that other areas of security around them are so loose no crooks have yet had to go to that much trouble. Weakest link, remember? No need to mount a MITM attack if you're able to just bribe the data entry clerk. I'd say, SSL with the cert protection is the strongest link in the chain. In fact, it's ludicrously strong. It's like a Chubb vault lock on a screen door. If we were getting physical here, the door wouldn't be strong enough to hold up the lock. So, cut to the chase: if we mandate that from now on, all commerce servers use ADH, just hypothetically, for the sake of argument, do you think that the connection would then become anything other than the strongest link in the chain? (I think it would remain the strongest link, by far. In fact, even if it was unencrypted, I think it would be one of the stronger links, c.f., David Wagner's devilish advocacy. But, nobody would suggest we throw away the current cert infrastructure, just that we back off a little and accept the intermediate path of ADH / self-signed certs.) Just because most companies' security is so poor that it's not worth the crook's time and effort doesn't mean we should throw anyone who takes security seriously enough that a MITM vulnerability might be the weakest link to the wolves. Nobody's saying that we should. I'm saying that the server and browser should offer the choice to deploy and use more convenient levels of security. The message should congratulate the user for moving up to a more secure channel than HTTP, not annoy them with imponderables about how self-signed certs might be insecure under a certain hard-to-measure threat model... as is the case now. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
On Monday, Mar 24, 2003, at 22:32 US/Eastern, bear wrote: On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: It's rather efficient if you want to sign a large number of keys of people you mostly do not know personally. Right, but remember that knowing people personally was supposed to be part of the point of vouching for their identity to others. Not that I heard of. I always understood that I should be 'convinced' of the identity and willing to state that to others. Knowing someone personally is very nice and gives you rather a lot of assurance that their identity is being used consistently and that others know the person by the same identity. (It is for precisely that reason that I have signed a few keys for people who use an alias.) Sometimes however you have the choice between a 'weaker' form of certification and no certification at all. I prefer the former because it increases the chances of the WoT being useful. Key signing parties' reliance on passports are a case in point. In general passports are a reasonable indication of identity. I know this guy. We spent a couple years working on X together. is different in kind from I met this guy once in my life, and he had a driver license that said his name was mike. Yes. But PGP doesn't mandate either interpretation. That is what you use your trust knobs for: you decide on a per-user basis how trustworthy an identity certification from that user is. The redundancy of a well-connected WoT then helps you a bit in eliminating simple errors. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a séance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
On Tuesday 25 March 2003 00:22, Jeroen van Gelderen wrote: On Monday, Mar 24, 2003, at 22:32 US/Eastern, bear wrote: On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: It's rather efficient if you want to sign a large number of keys of people you mostly do not know personally. Right, but remember that knowing people personally was supposed to be part of the point of vouching for their identity to others. Not that I heard of. I always understood that I should be 'convinced' of the identity and willing to state that to others. Well, that's a surprise to me! My understanding of the PGPid signature was that the semantics were loose, deliberately undefined. And, within that limitation, it came down to I met this guy, he called himself Micky Mouse. I've only been to one key signing event, and no identity was flashed around that I recall. So, do we have two completely disjoint communities here? One group that avoids photo id and another that requires it? Or is one group or the other so small that nobody really noticed? I'm curious, is all! Yes. But PGP doesn't mandate either interpretation. That is what you use your trust knobs for: you decide on a per-user basis how trustworthy an identity certification from that user is. The redundancy of a well-connected WoT then helps you a bit in eliminating simple errors. Um. So, there are people out there that I am convinced are who they say they are. They happen to be nyms, but I know that, and they are consistent nyms. Can I sign their key with the highest level? -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Monday, Mar 24, 2003, at 18:57 US/Eastern, Ed Gerck wrote: I'm sorry to say it but MITM is neither a fable nor restricted to laboratory demos. It's an attack available today even to script kiddies. For example, there is a possibility that some evil attacker redirects the traffic from the user's computer to his own computer by ARP spoofing. With the programs arpspoof, dnsspoof and webmitm in the dsniff package it is possible for a script kiddie to read the SSL traffic in cleartext (list of commands available if there is list interest). For this attack to work the user and the attacker must be on the same LAN or ... the attacker could be somewhere else using a hacked computer on the LAN -- which is not so hard to do ;-) This is good info! ... Clearly, the browsers should not discriminate against cert-less browsing opportunities The only sign of the spoofing attack is that the user gets a warning about the certificate that the attacker is presenting. It's vital that the user does not proceed if this happens -- contrary to what you propose. True. Based on his first post however I think that IanG is saying something like: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a séance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
On Tuesday, Mar 25, 2003, at 00:36 US/Eastern, Ian Grigg wrote: On Tuesday 25 March 2003 00:22, Jeroen van Gelderen wrote: On Monday, Mar 24, 2003, at 22:32 US/Eastern, bear wrote: On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: It's rather efficient if you want to sign a large number of keys of people you mostly do not know personally. Right, but remember that knowing people personally was supposed to be part of the point of vouching for their identity to others. Not that I heard of. I always understood that I should be 'convinced' of the identity and willing to state that to others. Well, that's a surprise to me! My understanding of the PGPid signature was that the semantics were loose, deliberately undefined. And, within that limitation, it came down to I met this guy, he called himself Micky Mouse. I don't think that is a contradiction. This is just your personal requirements for being 'convinced'. I've only been to one key signing event, and no identity was flashed around that I recall. So, do we have two completely disjoint communities here? One group that avoids photo id and another that requires it? Or is one group or the other so small that nobody really noticed? Nah. I think the photo-id case just makes large key-signing parties easier (or possible). I suspect that for a large group of people (excluding you(?)) the following statement holds: When I see a new person for 30 seconds she cannot 'convince' me of her identity. If a passport is flashed in my face in those 30 seconds I actually am quite certain of it. So there you have it: the difference between being able to sign in 30 seconds, or not. A practical -if not optimal- way to grow the WoT. This does *not* mean photo-id is a pre-condition for signing someone's key. It does *not* mean you should sign a key if you are shown a photo-id. It just *might* make it possible to sign a key where otherwise no certification would be possible. Yes. But PGP doesn't mandate either interpretation. That is what you use your trust knobs for: you decide on a per-user basis how trustworthy an identity certification from that user is. The redundancy of a well-connected WoT then helps you a bit in eliminating simple errors. Um. So, there are people out there that I am convinced are who they say they are. They happen to be nyms, but I know that, and they are consistent nyms. Can I sign their key with the highest level? Why not? It is *your* definition of 'convinced'. Other people will use their trust knobs to translate your judgement to their reliance on said judgement. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Western Corporations That Supplied Iraq's Weapons Program: http://www.thememoryhole.org/corp/iraq-suppliers.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) I'm sorry but the a priori truth above is false . Ignorance about the flaw, that is now fixed, and the need to do a LAN attack (if you want not to mess with the DNS) have helped avert a major public exploit. The hole is now fixed and the logic fails for this reason as well. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. There is a good reason -- MITM. AnonDH and self-signed certs cannot prevent MITM. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). But it is, please see the spoof/MITM method in my previous post. Which, BTW, is rather old info in some circles (3 years?) and is easy to do by script kiddies with no knowledge about anything we are talking here -- they can simply do it. Anyone can do it. (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) I think Ian's post, with all due respect to Ian, reflects a misconception about cert validation. The misconception is that cert validation can be provided as an absolute reference -- it cannot. The *mathematical* reasons are explained in the paper I cited. This misconception was discussed some 6 years in the ssl-talk list and other lists, and clarified at the time -- please see the archives. It was good, however, to post this again and, again, to allow this to be clarified. 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. You are asking for the same thing that was asked, and answered, 6 years ago in the ssl-talk and other lists. There is a way to do it and the way is not self-signed certs or SSL AnonDH. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Problem -- SSL AnonDH cannot prevent MITM. The solution is not to deny the problem and ask who cares about MITM? Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. OTOH, some practical code is being developed, and has been sucessfully tested in the past 3 years with up to 300,000 simultaneous users, which may provide the example you ask for. Please write to me privately if you'd like to use it. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 02:20 US/Eastern, Ed Gerck wrote: Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Be precise in the use of words and expect precision from others -- Pierre Abelard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 11:10 PM 03/23/2003 -0500, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) One of the major reasons for this, of course, is the requirement for certificates, which give at least some vague level of authentication that you're talking to the site you wanted, as well as some much vaguer level of authentication that the web site might correspond to some actual business that at least had enough capital to buy a cert. Sure, there are a variety of subtle and entertaining ways to pull of MITM attacks, but one crude and obvious one is to forge either an entire site or at least the parts of it that ask for your credit card number, and use something like DNS hacking or minor name misspellings to get people to visit your site instead of the real one. If you need to forward some of the requests on to the real site, that's a bit more work, and makes you easier to trace, so if you can be a MITM without bothering with the back half, great. And of course the cruder and more obvious attack was to create a site for a company that wasn't actually on the web yet, so nobody's watching the site, and then fly-by-night out of there. Is it perfect? No, but it does tend to raise the bar on attacks to the point that keeps out lots of the anklebiters and makes it more effective to attack a badly-administered server instead of forging a better-administered server. Oh, and it also let merchants who desperately wanted the public to trust them enough to give them credit card numbers tell their potential customers See, we've got *cryptography*! instead of See, we've got servers sitting exposed to the net, which is a social engineering problem, and also let them say See, the certificates let you know you're talking to the REAL Example Inc. instead a some faker putting up example.com. Because the real economics is whether you can get customers to show up. (Well, ok, and whether you can make money if they do show up :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
[ Charset UTF-8 unsupported, converting... ] On Saturday 22 March 2003 17:12, Douglas F. Calvert wrote: I will be organizing a keysigning session for CFP2003. Please submit your keys to [EMAIL PROTECTED] and I will print out sheets with key information in order to speed up the process. Bring a photo ID and a copy of your key information so that you can verify what is on the printout. A list of submitted keys and a keyring will be available on: I must be out of touch - since when did PGP key signing require a photo id? It is an usual requirement for a keysigning party to bring a photo ID to validate if theirs key ids are the same as their names (and to get class 3 key signatures) http://www.cryptnet.net/fdp/crypto/gpg-party.html#ss1.1 Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
CTKS?
Change the Key Stupid ? Just a nice simple question. I have previously implemented a process to generate new dsa/rsa keys for ssh and transfer them over the existing encrypted session with time interval t, the following connection will use the new keys so forth.. The reason behind this was, if anyone robbed the private key and knew the passphrase ( in fact I had no passphrase above, and allowed any of the last 3 keys pairs to be used ), it would only be valid for a short time interval... The benefit is simple for ssh, blank passphrase private keys are useful for time interval t and no longer, gaining access to these via backups, temporary root, temporary contract etc, are of little use if time internal is sufficiently short. I have not seen this technique documented/ mentioned for ssh or any other protocols ? links references ? or is this a case of CTKSS! ( Change the key Stupid, Stupid ) ? ..surely where there is risk of keys being copied and allowing either access, future decryption or MITM attacks with private key, it makes sense to automate the key exchange when possible ? and also to continue to have the 1-3 month manual key exchange over alternate channel. Thoughts / criticisms welcome - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
I must be out of touch - since when did PGP key signing require a photo id? It's rather efficient if you want to sign a large number of keys of people you mostly do not know personally. Assuming, of course, that the ID is of a sort for which you have an is-a-forgery oracle. Has anyone ever weighted a PGP key's certification value as a function of how many keys it's know to have certified? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 12:17 AM 3/25/2003 -0500, Ian Grigg wrote: I'd say, SSL with the cert protection is the strongest link in the chain. In fact, it's ludicrously strong. It's like a Chubb vault lock on a screen door. If we were getting physical here, the door wouldn't be strong enough to hold up the lock. except the certification authorities ... when doing the certification of who owns a domain name still asks the domain name infrastructure as to who really owns the domain name when they get a request for a SSL domain name certificate. SSL domain name certificate request after a domain name hijack still is possible (aka a chubb vault lock with a possible backdoor). the other scenario that has been raised before is that the browsers treat all certification authorities the same aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tue, 25 Mar 2003, Ian Grigg wrote: On Monday 24 March 2003 19:26, bear wrote: him running roughshod over the law. He set up routing tables to fool DNS into thinking his machine was the shortest distance from the courthouse where she worked to her home ISP and eavesdropped on her mail. Sent a message to every fax machine in town calling her a Jezebellian whore after getting the skinny on the aftermath of an affair that she was discussing with her husband. I love it! Then, I'm wrong on that point, we do in fact have some aggressive MITMs occuring in some mediums over the net. Steve Bellovin pointed one out, this is another. Which gets us to the next stage of the analysis (what did they cost!). Wait. Time out. Setting aside the increased monetary cost of her reelection campaign in a fairly conservative state capitol, and setting aside the increased difficulty of raising money for that campaign, the main costs here are intangible. On a professional level, she had reduced power in office because of the scandal this clown created publishing her personal email, but the intangible costs go both directions from there. Toward the personal end of the spectrum, discussing the aftermath of an affair with one's husband is sensitive and personal, and making that whole thing public can't have done either of them, or their marriage for that matter, any good. In the public sphere, this is a case in which information gained from an attack on email was being employed directly for undeserved influence on government officials. Being timed to interfere with her reelection makes it a direct means of removing political opponents from office, and it has probably had a chilling effect on other council members in that benighted city who might otherwise have voted in ways Phred didn't like. What he did was nothing less than a direct assault on the democratic process of government. I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
On Tue, 25 Mar 2003, Matt Crawford wrote: Has anyone ever weighted a PGP key's certification value as a function of how many keys it's know to have certified? An interesting idea: At one extreme you could view the whole universe as having a finite amount of trust and every certification is a transfer of some trust from one person to another. But then companies like verisign, after the first thousand or so certs, would have nothing left to sell. At the other, you could view verisign as providing a fairly reliable indication, not necessarily of who X is, but certainly of the fact that somebody was willing to spend thousands of dollars to claim to be X and the financial records are on file if you absolutely need to figure out who that was, so they create trust in a way that most keysigners don't. Neither model is perfect, but the latter one seems to have more appeal to people in protecting financial transactions and the former to people who are more concerned about personal privacy. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tue, 25 Mar 2003, Anne Lynn Wheeler wrote: the other scenario that has been raised before is that the browsers treat all certification authorities the same aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. Of course the consumer gets to make that choice. I can go into my browser's keyring and delete root certs that have been sold, ever. And I routinely do. A fair number of sites don't work for me anymore, but I'm okay with that. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday 25 March 2003 12:07, bear wrote: On Tue, 25 Mar 2003, Ian Grigg wrote: Which gets us to the next stage of the analysis (what did they cost!). Wait. Time out. good stuff snipped I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. I'm sorry to disagree, but I'm sticking to my cost-benefit analysis: monetary costs are totally germane. You see, we need some way in which to measure the harm. It's either subjective as you describe above, which can't support an infrastructure decision, or its objective, which means, money. But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. Presumably, (you mentioned America, right?) this injured party filed a civil suit against the person and sought damages. Now, even if the case did not get filed, I imagine that you would be able to find a few legal types to provide an upper and lower bound on the sort of damages that case would go for. And there's your number! From my ignorant position, I'd scratch in a figure of about a million dollars there, and wait for someone to refine it. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. I would agree. Which is why we are having this discussion - how can we get this poor victim's traffic onto some form of crypto so she doesn't get her life ripped apart by some dirtbag? As far as SSL goes (switching from the context of her mail to the system we are discussing here), here's the answer: Make ADH / self-signed certs a respectable half-way house to CA-signed certs. Encourage all servers to accept them, by default. Encourage all browsers to switch up to ADH / self-signed secured traffic. Don't discourage it, encourage it. The problem is, it is just too darned hard expensive for sites to get into SSL. That's what we are looking at, here, lowering the cost of entry into SSL. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL
Anton Stiglic wrote: - Should it do blinding for RSA signatures as well as RSA decryption? If you are a client, and you manually control the signature generation (like you use PGP to sign email messages), I wouldn't implement blinding. But if you are a server (or a client that automatically responds to requests) that signs message for some reason, and you receive many requests, I would. The way I understand the attack, you have to throw a million specially-chosen guesses at the server, which it will blindly attempt to decrypt and use. Basically, you're getting the server to decrypt chosen ciphertext for you. I don't see how the attack can apply to signatures, where the server itself is formatting the data to be signed. Unless the server is just directly signing (RSA-encrypting) arbitrary client-supplied data, but that's a no-no anyway. This is slightly more than theoretical, as OCSP servers do nothing but emit signed responses. An OCSP client can only indirectly influence some of the data that a server signs, and so it seems very difficult to pull off the attack. M. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 12:28 US/Eastern, bear wrote: On Tue, 25 Mar 2003, Anne Lynn Wheeler wrote: the other scenario that has been raised before is that the browsers treat all certification authorities the same aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. Of course the consumer gets to make that choice. I can go into my browser's keyring and delete root certs that have been sold, ever. And I routinely do. A fair number of sites don't work for me anymore, but I'm okay with that. Go tell that to Joe Average. Or your mom. Or my sister. Or the average MSN user. You know, the insignificant group of people that make up the majority of the Internet population these days. If the lock icon is displayed it is safe. Of course the consumer doesn't get to choose. Just like the consumer never, ever gets to use all of the features on his VCR[*]. This is an software agent deficiency. A UI issue: presently the UI doesn't facilitate the consumer in making that choice. Cheers, -J [*] I'm *not* talking about TiVo here, just about old-fashioned VCRs. -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Be precise in the use of words and expect precision from others -- Pierre Abelard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ian Grigg writes: I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. I'm sorry to disagree, but I'm sticking to my cost-benefit analysis: monetary costs are totally germane. You see, we need some way in which to measure the harm. It's either subjective as you describe above, which can't support an infrastructure decision, or its objective, which means, money. I'm skeptical. Just because the cost is subjective doesn't mean we should ignore the cost. But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. That's using a questionable measuring stick. The damages paid out in a civil suit may be very different (either higher, or lower) than the true cost of the misconduct. Remember, the courts are not intended to be a remedy for all harms, nor could they ever be. The courts shouldn't be a replacement for our independent judgement. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ben Laurie wrote: Ed Gerck wrote: ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. This would still depend on what the paper calls extrinsic references, that are outside the dialogue and create opportunity for faults (intentional or otherwise). The resulting problems for PGP are summarized in www.mcg.org.br/cert.htm#1.2. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen van Gelderen wrote: Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. Maybe we're talking about different MSIE bugs, which is not hard to do ;-) I was referring to the MSIE bug that affects the SSL handshake in HTTPS, from the context in discussion. BTW, HTTP has no provision to prevent MITM in any case -- in fact, establishing a MITM is part of the HTTP tool box and used in reverse proxies for example. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 13:55 US/Eastern, Ed Gerck wrote: Jeroen van Gelderen wrote: Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. Maybe we're talking about different MSIE bugs, which is not hard to do ;-) I am NOT talking about MSIE bugs at all. I didn't mention them and I don't know where you pull the reference from. I am talking about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet: 1. Presently 1% of Internet traffic is protected *by SSL* against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all (because it travels over plain HTTP). I was referring to the MSIE bug that affects the SSL handshake in HTTPS, from the context in discussion. BTW, HTTP has no provision to prevent MITM in any case -- in fact, establishing a MITM is part of the HTTP tool box and used in reverse proxies for example. Well, that is *exactly* the point I made: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Hence the a priori truth. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. That is, we cannot add just privacy protection to HTTP by enabling SSL. That sucks because HTTP with just privacy protection is preferable over plain HTTP. But the present SSL infrastructure insists that I pay to defend against MITM even if I have no need for that. That is the problem I (and I suspect IanG) is talking about. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack for (2), (3). (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it. -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen van Gelderen wrote: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. In addition, when you talk about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet you are not talking about user's choices -- where the user is the party at risk in terms of their credit card number. You're talking about web-admins failing to protect third-party information they request. Current DO liability laws, making the officers of a corporation personally responsible for such irresponsible behavior, will probably help correct this much more efficiently than just a few of us decrying it. My personal view is that ALL traffic SHOULD be encrypted, MITM protected, and authenticated, with the possibility of anonymous authentication if so desired. Of course, this is not practical today -- yet. But we're working to get there. BTW, a source once told me that about 5% of all email traffic is encrypted. So, your 1% figure is also just a part of the picture. Cheers --/Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tue, 25 Mar 2003, Ian Grigg wrote: On Tuesday 25 March 2003 12:07, bear wrote: But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. Presumably, (you mentioned America, right?) this injured party filed a civil suit against the person and sought damages. You honestly haven't heard of Fred Phelps? He has thirteen children and nine of them are lawyers. Estimated costs to sue the guy are in the hundreds of thousands of dollars. Estimated costs for him to defend are near zero. Plus the instant you file that civil suit you'll have his zombies loudly picketing your home (that's right, your private residence) 24/7 until you stop. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. I would agree. Which is why we are having this discussion - how can we get this poor victim's traffic onto some form of crypto so she doesn't get her life ripped apart by some dirtbag? ISP's don't want to support encrypted links because it raises their CPU costs. And mail clients generally aren't intelligently designed to handle encrypted email which the mail servers could just pass through without decrypting and encrypting. I think a new protocol is needed. The fact that SMTP is unencrypted by default makes it impossible for an encrypted email form to be built on top of it. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
I get the impression that we're talking at cross-purposes here, with at least two different discussions. Let's look at several cases: 1 - Sites that have SSL and Expensive Certs that need them and need MITM protection 1a - These sites, but with other security holes making it easy to break in. 1b - These sites, broken by SSL bugs or browser bugs 2 - Sites that have SSL and Expensive Certs that don't need them, as long as they've got some crypto like self-signed certs, which don't give MITM protection 3 - Sites that don't have SSL today because it's too annoying, for which crypto would be useful, and ADH or self-signed certs would be good enough, because MITM isn't a big threat for them. 4 - Sites that don't need crypto. Some people are arguing Many Sites with SSL Certs are Type 2, Not Type 1 (No they're not! Yes, they are!) Some people are arguing There are lots of Type 3, so we should support them better than we do today instead of requiring them to do Type 1 (I suspect that's what Ian was really trying to say, but most of the replies have been to the other question, e.g. There are lots of Type 3! No, there aren't many Type 2! Yes there *are* lots of Type 3! No there ARENT'T many Type 2! Yes, there are lots of 1a, but that doesn't imply 2! Type 1+2 is 1% and 3+4 is 99%! No, 1b was fixed One of the big reasons for DNSSEC was MITM protection, at least before virtual hosting took over, because it gave you a way to trust that the IP address you used was the correct IP address for the domain name you wanted, so you were probably talking to the right machine. Of course that doesn't get you ARP-spoofing protection, or eavesdropping protection unless you also use it as a crypto key or at least a signature key for DH parts, and doesn't protect you against other users on your machine (but a shared machine doesn't have much protection anyway, at least from root, so that was already part of your threat model, and that's another 1-vs-1a variant, like the heavy-duty lock on your apartment building front door when your own apartment door has a wimpy lock.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen van Gelderen wrote: On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote: Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. You are saying that active attacks have the same cost as passive attacks. That is ostensibly not correct. Cost is not the point even though cost is low and within the reach of script kiddies. What we would like to do however is offer a little privacy protection trough enabling AnonDH by flipping a switch. I do have CPU cycles to burn. And so do the client browsers. I am not pretending to offer the same level of security as SSL certs (see note [*]). I agree with this. This is helpful. However, supporting this by asking Who's afraid of Mallory Wolf? is IMO not helpful -- because we should all be afradi fo MITM attacks. It's not good for security to deny an attack that is rather easy to do today. I'm proposing a slight, near-zero-cost improvement[*] in the status quo. You are complaining that it doesn't achieve perfection. I do not understand that. Your proposal is, possibly, a good option to have. However, it does not: provide a credible protection against eavesdropping. It is better than ROT13, for sure. Essentially, you're asking for encryption without an authenticated end-point. This is acceptable. But I suggest that advancing your idea should not be prefaced by denying or trying to hide the real problem of MITM attacks. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote: Jeroen van Gelderen wrote: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. You are saying that active attacks have the same cost as passive attacks. That is ostensibly not correct. In addition, when you talk about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet you are not talking about user's choices -- where the user is the party at risk in terms of their credit card number. You're talking about web-admins failing to protect third-party information they request. Not at all. That assertion is nowhere to be found in my original post either. I am talking about a website like -say- Cryptix (or Dilbert, or The Onion, or whichever). Websites where we do not have any requirement of offering the user any privacy whatsoever. Where we do not collect CC numbers. Where we do in fact not collect much of anything. And where we definitely don't have money for an SSL certificate. Where in fact any effort spent on this stuff is an incredible waste of resources. What we would like to do however is offer a little privacy protection trough enabling AnonDH by flipping a switch. I do have CPU cycles to burn. And so do the client browsers. I am not pretending to offer the same level of security as SSL certs (see note [*]). Enabling AnonDH will eliminate passive attacks at near zero cost and thus *raise* *the* *cost* of eavesdropping. For one it will render mere recording of HTTP traffic useless, which, in my book is a plus. We obviously don't care to *eliminate* eavesdropping because we are happily putting up with that today. You seem to be asserting that increasing the cost of eavesdropping by a small amount is worthless. I'm sorry but I don't see how that makes sense. It is the difference between simply mirroring Google's OC48 to and NSA-owned port on the switch and redirecting the OC48 trough a real-time, low-latency NSA-owned MITM device. Without being detected. I'm proposing a slight, near-zero-cost improvement[*] in the status quo. You are complaining that it doesn't achieve perfection. I do not understand that. Cheers, Jeroen [*] Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* *displayed* when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. -- Jeroen C. van Gelderen - [EMAIL PROTECTED] They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it. -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday 25 March 2003 13:17, David Wagner wrote: I'm skeptical. Just because the cost is subjective doesn't mean we should ignore the cost. I agree with that ... I was converting the subjective harm into an objective cost. I certainly wasn't intending to ignore it :-) But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. That's using a questionable measuring stick. That being part and parcel of the problem. It's a subjective harm, there is no solid way to move subjective to objective, by definition. We can only make estimates. What is beneficial here is that - at least - we have one way to do this. And, it is a way that has lots of disinterested observers, lots of experience, and lots of interested parties. Much as I dislike courts, it is a fair and auditable way of dollarising a harm. Bear says: You honestly haven't heard of Fred Phelps? Nope. But, all we want is an estimated cost of the attack. Ask some lawyers for a quote. Ignore the guy's family, we are only after an estimate of the cost. David says: The damages paid out in a civil suit may be very different (either higher, or lower) than the true cost of the misconduct. Remember, the courts are not intended to be a remedy for all harms, nor could they ever be. The courts shouldn't be a replacement for our independent judgement. This of course is true especially with the low level of MITM activity that we've found to date. If such a case were to happen once a year, I'd not be really confident of the accuracy of the numbers, especially if we were estimating based on lawyer's opinions rather than awarded damages. (But that wouldn't so much matter if the numbers came out as also too low to consider, as I suspect they will.) If however, we had such MITMs once per month, then costs could be averaged over the size of the activity. Something like this: There are 500 million email users in the world today (guess!). Cost of failures that could be rectified with proper crypto (amounts to 12 cases per year) is 12 million dollars. Some judgements less than a million, some more. [ if you like, you could add in a fudge factor for unreported harms and other judgement calls. ] Now, the cost of prevention: assume we pass a law to make every ISP sell every user a copy of OpenPGP to protect their privacy. Bulk discount gives us $1 each copy, annually updated to cover for the inevitable new release. So, cost to protect: 500 million x $1. Saved costs in cases: $12million. That law won't get passed :-) -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ed Gerck wrote: Ben Laurie wrote: Ed Gerck wrote: ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. This would still depend on what the paper calls extrinsic references, that are outside the dialogue and create opportunity for faults (intentional or otherwise). The resulting problems for PGP are summarized in www.mcg.org.br/cert.htm#1.2. It seems to me that the difference between PGP's WoT and what you are suggesting is that the entity which is attempting to prove the linkage between their DN and a private key is that they get to choose which signatures the relying party should refer to. Am I wrong? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 12:09 PM 3/25/2003 -0800, bear wrote: ISP's don't want to support encrypted links because it raises their CPU costs. And mail clients generally aren't intelligently designed to handle encrypted email which the mail servers could just pass through without decrypting and encrypting. circa '95 there were comments that ISP's didn't want to verify from/spoofed packet addresses on DHCP modem connections because it increased their router cpu costs (actually one of the most common routers didn't have enuf processor power to implement even trivial packet filtering on modem lines). http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement now there is the observation in this thread (or the previous thread) that many websites use SSL very sparingly because it cuts their web traffic capacity by 80-90 percent (http vis-a-vis https given the same hardware). Typical sequence is that person clicks-on/types something and goes to a site with straight HTTP, they shop for a while ... until they are ready to check-out, they then click on the check-out button. That button supplies a URL that sends them off to a HTTPS site (aka the user didn't actually originated the HTTPS url) ... where all the payment information is provided. Now since the client/consumer never provided the actual HTTPS sequence but it was provided for them by a webpage at the HTTP site they were shopping at it is presumably trivial for the HTTP site that they are shopping at to make sure that the HTTPS URL domain that clients are sent to matches the certificate domain at that site (and a lot of shopping URLs have a lot of appended history so that it is relatively easily contrived that the consumer doesn't notice the domain name of the check-out/payment page). A lot of the requirement for encryption is end-to-end ... or at least VPN-like so encrypted packets should mostly be transparent to operations in their ISP roles. This isn't as true on the web-hosting side of the house ... where SSL or similar encryption activity can represent significant additional CPU processing load. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
- Original Message - From: Ed Gerck [EMAIL PROTECTED] To: Jeroen C. van Gelderen [EMAIL PROTECTED] Cc: Ian Grigg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 11:20 PM Subject: Re: Who's afraid of Mallory Wolf? Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. Their is another bug that has not been fixed by MS that allows signed but invalid certificates to be used to MITM the browser as well with no notification. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) I'm sorry but the a priori truth above is false . Ignorance about the flaw, that is now fixed, and the need to do a LAN attack (if you want not to mess with the DNS) have helped avert a major public exploit. The hole is now fixed and the logic fails for this reason as well. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. There is a good reason -- MITM. AnonDH and self-signed certs cannot prevent MITM. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). But it is, please see the spoof/MITM method in my previous post. Which, BTW, is rather old info in some circles (3 years?) and is easy to do by script kiddies with no knowledge about anything we are talking here -- they can simply do it. Anyone can do it. (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) I think Ian's post, with all due respect to Ian, reflects a misconception about cert validation. The misconception is that cert validation can be provided as an absolute reference -- it cannot. The *mathematical* reasons are explained in the paper I cited. This misconception was discussed some 6 years in the ssl-talk list and other lists, and clarified at the time -- please see the archives. It was good, however, to post this again and, again, to allow this to be clarified. 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. You are asking for the same thing that was asked, and answered, 6 years ago in the ssl-talk and other lists. There is a way to do it and the way is not self-signed certs or SSL AnonDH. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Problem -- SSL AnonDH cannot prevent MITM. The solution is not to deny the problem and ask who cares about MITM? Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. OTOH, some practical code is being developed, and has been sucessfully tested in the past 3 years with up to 300,000 simultaneous users, which may provide the example you ask for. Please write to me privately if you'd like to use it. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
I get the impression that we're talking at cross-purposes here, with at least two different discussions. I suspect that the discussion started from commercial motivations; cf www.systemics.com /r$ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ben Laurie wrote: It seems to me that the difference between PGP's WoT and what you are suggesting is that the entity which is attempting to prove the linkage between their DN and a private key is that they get to choose which signatures the relying party should refer to. PGP's WoT already does that. To be clear, in PGP the entity that is attempting to prove the linkage between a DN and a public key chooses which signatures are acceptable, their degree of trust, and how these signatures became acceptable in the first place. BTW, a similar facility also exists in X.509, where the entity that is attempting to prove the linkage may accept or reject a CA for that purpose (unfortunately, browsers make this decision automatically for the user but it does not need to be so). That said, the paper does not provide a way to implement the method I suggested. The paper only shows that such a method should exist. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
On Tue, 2003-03-25 at 07:52, Janusz A. Urbanowicz wrote: I must be out of touch - since when did PGP key signing require a photo id? It is an usual requirement for a keysigning party to bring a photo ID to validate if theirs key ids are the same as their names (and to get class 3 key signatures) I usually reserve class three signatures to people that I know very well. Casual photo ID and fingerprint verification usually produces a ersion 2 signature from me. Furthermore GPG also allows for the insertion of a signature policy URL in a signature. The policy URL is a description of what process you went through to verify an identity... -- + Douglas Calvert [EMAIL PROTECTED] http://anize.org/dfc/ + | Key Id 0xC9541FB2 http://anize.org/dfc-keys.asc | | [X] User wants to receive encrypted mail | +| 0817 30D4 82B6 BB8D 5E66 06F6 B796 073D C954 1FB2 |+ signature.asc Description: This is a digitally signed message part
