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, 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?
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?
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?
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]
