[Sks-devel] Looking for peers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! keyservers.org is now online, running SKS 1.1.1. It's running on a small server in Silver Spring, Maryland, on an IPv4 network. The key dump is current as of last week, and has already reconciled with a peer and is current. keyservers.org 11370 # Rob Hansen 0xD6B98E10 Thanks! -BEGIN PGP SIGNATURE- iFYEAREIAAYFAkxZslwACgkQI4Br5da5jhCDowDgt0bT2gvl8VLeho/vzwkSdl40 xQtDLf2+rLrjpADgw5b+rUF7++676ePAZmIiyHTiFke4a815AA49tQ== =YAI6 -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
On 8/22/2010 8:04 AM, Arnold wrote: > This is a national law / ruling applicable to just one country. Even less than that. It's a state law applicable to just one state -- neither one of our largest nor most populous. (It is beautiful and I've found the people there to generally be quite pleasant, but that's beside the point.) I do not understand what Adams-Collier is on about, either. When I posted a couple of weeks ago to ask for peers, I received an email from him simply reading "ping?" I asked if there was something he needed, and got no response back. I don't know what to make of either my interaction with him, or of his interaction with Christoph. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
While I concur with you, Christoph, there's one minor error that should probably be corrected: > No keyserver is a CA... Most keyservers are CAs, in that the people who run the keyservers have signed other people's keys. The Web of Trust is really a buffet table of CAs, where you get to choose which CAs you trust and which you don't, and your network of keys emerges from your CA trust decisions. If what you meant to say was that keyserving is a totally separate function from being a CA, though, then I agree with you. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
On 8/22/2010 10:47 AM, David Shaw wrote: > Robert, are you really saying what you seem to be saying? The action > of the owners doesn't make a keyserver a CA. That makes the person > running the keyserver a CA. Yes. I was using "keyserver" as synonymous for "keyserver operator." Imprecise language, I grant, but that's English for you. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] new keyserver online
On 8/22/2010 10:54 AM, C.J. Adams-Collier KF7BMP wrote: > Because none of the information provided indicates in any way that the > private key corresponding with the public key provided is under Chris' > control. If Christoph were himself making assurances about certificates, this would be relevant. As he is not, I don't see how it is. The assurances are made by the individual signers on the certificates he distributes. I don't imagine you're going to demand each and every certificate holder contact you to verify their private keys -- so why do you expect Christoph to do so? Perhaps there's a good reason for it, but so far I'm not seeing it. > (1) The secretary must recognize one or more repositories, after finding > that a repository to be recognized: > ... (d) Contains no significant amount of information that is known or > likely to be untrue, inaccurate, or not reasonably reliable; I am not a lawyer, obviously. However, it seems to me that if you consider Christoph's private certificate to be a significant amount of information, even though it has absolutely no influence on the public certificates he distributes, you must also consider the individual signatures on those certificates to be significant amounts of information, since those do influence the public certificates. (This doesn't even get into the 45 keys on the keyservers marked as "whitehouse.gov", or the ones in the names of various celebrities, and so forth. There is a significant amount of information in the certificate pool which is likely to be untrue, inaccurate, or not reasonably reliable.) > All of this is correct. However, the advice is generally applicable to > signing- and trust-related activities. It is generally applicable within your security model. I am skeptical that your advice is applicable within mine. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyserver.pramberger.at terminating
On 9/7/2010 2:45 PM, Peter Pramberger wrote: > Several weeks ago I got a complaint from a user getting his old PGP > key removed from my keyserver. He got the usual answer in such cases, > but unfortunately wasn't accepting it. Instead he insisted on his > right to get the key removed, in accordence to the Austrian Data > Protection Act (DSG 2000). Everything works great up until some idiot decides to get the law involved. I'm sorry it's ended this way, Peter. Thank you for all your work with the keyserver community. It's very much appreciated. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyserver.pramberger.at terminating
On 9/7/2010 6:55 PM, Anakin-Marc Zaeger wrote: > Just out of curiosity, what effect, if any, would said Austrian > legislation have on those of us with keyservers in countries other than > Austria? While the law itself is domestic in nature (I doubt that > Austria or any other country would be able to enforce their laws in a > foreign sovereign nation), are there any international treaties which > this issue may fall under? IANAL. I am especially not an expert on international privacy law, which seems to be (to my layman's eyes) a giant no-man's-land where no one can really predict what various courts will do. That said: commonly, businesses that have offices in the European Union are required to obey EU directives on data privacy, regardless of whether those businesses are headquartered in an EU country. As an example, American airlines must abide by EU privacy directives since they fly into and out of EU airports. There are a *ton* of exceptions to this general principle. After going blind on this subject for a few weeks, what I came away with was "you are lost in a maze of twisty little regulations, all different." I can't give any guidance as to whether you are going to be affected by data privacy laws in the EU. I can only tell you that it is not outside the realm of possibility, especially if your keyserver is run by a business that operates in the EU. If you are concerned about this, you need to consult legal counsel that's versed in both US and EU privacy law. Good luck. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Delete key from keyserver
On 9/7/2010 9:50 PM, Yaron Minsky wrote: > I think that a basic form of deletion is pretty easy, and requires no > real research The algorithm is simple. You simply add a new kind of > pseudo-key to be gossiped around: a deletion token. In the simplest > version, the deletion token never expires; it's a permanent addition > to the database. But the effect of adding the deletion token is that > the thing it wants to delete is effectively removed. With a small > amount of extra cleverness, one can allow the deletion token to be > removed eventually as well. But given the small number of deletions > that appear to be necessary, it hardly seems urgent. I see no reason to think the number of deletions will be small. My nightmare scenario involves people with an interest in illegal information discovering the keyserver network makes a good vehicle for dissemination of relatively small pieces of illegal information. All it takes is one person discovering this and others thinking it's a good idea and the next thing you know we've got keyservers drowned in spam. It's just that this spam could get keyserver operators arrested for distribution of illegal information. (Note: although I see no reason to think the number of deletions will be small, there is also no reason to think my nightmare scenario will come to pass. We simply /do not know/ how many deletions will be necessary. I think we ought keep this lack of knowledge in mind when we discuss solutions.) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Re: Delete key from keyserver
On 9/7/2010 10:57 PM, Jeff Johnson wrote: > Well yes but ... this is NOT an illegal piece of information until > litigated afaik. Imagine some well-meaning but deranged Wikileaks activist decides to take GIFs of the most salacious Wikileaks documents, creates a phony public certificate, and a ton of photographic user IDs where each one is a classified document. Whether this is an "illegal piece of information" is really not the question: whether it will put the keyserver network in a world of hurt is the real question. (Note: I am not claiming anyone associated with Wikileaks would do such a thing. I just like to find other things beyond child porn to use as examples.) > And the pubkey was a previously legal piece of information or it never > would > have ended up on a SKS keyserver in the first place. Someone changed > their mind and has a right to their privacy. You're assuming the certificate originator originally intended to use the keyserver networks as we intend it to be used. I think we shouldn't make that assumption. The keyserver network is a reliable, scalable, highly deletion-resistant way to distribute small quantities of information. There are a ton of use cases for it which are at odds with the desires of (one would hope) the great majority of keyserver operators. > Or am I missing something essential here? Possibly. It's just as likely that I am. :) 73, de kc0sje. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Dump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/13/2010 9:36 PM, R P Herrold wrote: > just becaiuse something CAN be done does not mean it should be done, > and here particularly with a fine cache of email addresses intact > for spammers to target (rather than having to pull them one-off) Two things: 1. Shielding email addresses is just bad strategy. If your anti-spam measure is built on keeping your email address secret, then once your email address gets out (and they all do, eventually!) your plan falls apart. It is wiser to assume the spammers already have your email address and rely on anti-spam measures that are robust even then. Kerckhoff's Principle, paraphrased: "the adversary knows the system." In crypto we build systems and assume the bad guys have perfect knowledge about how the system works, about everything involved in the system except the secret key. Kerckhoff's works well for crypto. It also works well for anti-spam measures: assume the spammer already knows about you. 2. People who upload their certificates to the server have already made a conscious decision to publish their certificates far and wide. They've voluntarily entered their email addresses into a worldwide searchable database where anyone, /anyone/, can get a copy of it. Keeping the keydump away from Google is not going to make life any harder for the spammers. There's already strong evidence suggesting spammers are already harvesting the keydump anyway. > I think you are running around solving a problem that does not > exist, No comment on this. > and [impairing] the privacy of a whole community's members This is nonsense. -BEGIN PGP SIGNATURE- iFYEAREIAAYFAky2bIEACgkQI4Br5da5jhA1ogDcDBvf18YA8MI7s6FP177iAdrZ k9cwBWaOfnrwJADeNtlEe7ixQYM/KcoRPh9VhfD3md5JtO1Zdvma/A== =JOLy -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Dump
> The issue is one off vs. wholesale, and the initial inquiry from the .edu > poster demonstrates that it is not generally known how to get all 2.9 million > without effort beyond that of a casual attacker The initial inquiry from the .edu poster demonstrates only that the original poster didn't know. Generalizing from a single data point is not wise. > Facilitating anonymous wholesale transfers increases the size of the > population able to readily have a corpus to spam at, with a set of assumedly > valid email addresses and matching ID information (a) they already have it, and (b) people who upload their certificates to servers willingly accept the risk of their email address being public in exchange for the benefit of having their certificates being easily findable -- and who are you to say their wishes should be ignored? ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Dump
On 10/14/10 10:13 AM, R P Herrold wrote: > Indeed, and there is clearly a Cost / Benefit analysis to perform here; > it makes sense to me that a blackhat with infinite resources would > engineer a entire solution set. It makes sense to me that a spammer would find a broke undergrad in CompSci and say, "hey, I'll pay you $100 to grab me a copy of every email address that's on the global keyserver network." "Infinite" resources is putting things a little strongly. "Routine and unexceptional business expense" is more accurate. > The world is not a perfect place, but filled with shades of gray. But > my question is: > Why facilitate casual exploitation? This presupposes the system *is not already* being harvested. As several people have told you, there is reason to suspect that it is. Given this, I can't engage your question since it seems built on assumptions that are not true. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Re: Dump
On 10/14/10 10:07 AM, R P Herrold wrote: > Trimming away and ignoring clearly stated questions to reframe away hard > parts is a common 'debate society tactic' -- engage or be ignored This has become tedious. Rather than answer my questions, you accuse me of engaging in cheap theatrics and attempt to claim some kind of moral high ground. >> (b) people who upload their certificates to servers willingly accept >> the risk of their email address being public in exchange for the >> benefit of having their certificates being easily findable -- and who >> are you to say their wishes should be ignored? > > 'There you go again' Clearly a false generalization. For it to be a false generalization (much less a 'clearly false' generalization) you must present evidence that most users do /not/ understand the keyserver network is a public resource. So far I've yet to see it. Neither is the message you quoted relevant to the discussion. The person asking this question was running a standalone, *non-synching* server. This person is totally irrelevant to the question of what the *synching* keyserver community should do. Even then, there are always people who don't read the manuals. Exceptions to the rule do not disprove the rule: they only prove the rule has exceptions. By your reasoning it is "clearly a false generalization" to say that, e.g., citizens must pay taxes, on the grounds that some people manage to successfully commit tax fraud. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Re: Dump
On 10/14/10 12:42 PM, R P Herrold wrote: > Review the bidding. I rather believe you initiated the uncivil tone, > and I have been mild in reply: > > Hansen: >> herrold: >>> and [impairing] the privacy of a whole community's members >> This is nonsense. > > and an EOM. I think that qualifies as rude. That qualifies as direct. If I had called you names, questioned your commitment, heaped aspersions on your personal character, etcetera, that would be ad-hominem and beyond the pale. Your *ideas*, though, are fair game. As they should be, as they must be. You are not your ideas. In my daily work, probably ninety percent of my promising ideas ultimately turn out to be crap. When one of my co-workers listens to me pitch an idea, gives it fair consideration, and then says, "Rob, it's crap," I thank him for his time. He's given me everything I could ask for: not only his consideration, but also his *judgment*. He has given me his professional opinion in a clear and unambiguous manner. I can choose to abandon my research project or I can choose to continue it. Maybe it will pan out and maybe it won't. But I will never be able to claim my colleagues did not give me the benefit of their clearest, most direct judgment. I have had co-workers who think that "you're stupid" is a good criticism. I'm glad to no longer work with them. But I am genuinely grateful for my co-workers who have listened fairly and then told me, "Rob, this is nonsense." If you really think that criticism of your ideas and proposals -- even harsh and blunt criticism -- rises to the level of a personal attack against you, well... I don't know what to say about that, besides that I have no desire to speak with you further. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 2 out of 10 pool.sks-keyservers.net not responding to pings
On 11/29/10 3:55 PM, Daniel Kahn Gillmor wrote: > I'd like to suggest that they should, but i'd be interested in hearing > arguments to the contrary as well. Many keyserver operators run under the aegis of larger networks, and are beholden to the decisions made by network administrators above them. Some networks block ping (usually because of claims that ping is a security concern). I don't like the idea of the community adopting a SHOULD -- even informally -- when a large fraction of the community will lack all ability to conform with the SHOULD. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 2 out of 10 pool.sks-keyservers.net not responding to pings
On 11/29/10 5:00 PM, Daniel Kahn Gillmor wrote: > i've heard these claims about ping, and i confess i've never properly > understood them, particularly for hosts with services operating on > well-known ports. Doesn't matter. Whether the policies are wise or foolish doesn't change the fact these policies exist. > i don't understand this sentiment; if we think this is reasonable, it's > entirely acceptable to say so, even when not everyone can follow > through. You're not proposing the community deem it reasonable, though -- the community already seems to agree that it is reasonable. You're proposing the community deem it ought be conformed with if at all possible -- and there we part ways. SHOULD is a loaded word. It means, "if you fail to conform with this part of the spec you should have a darned compelling reason." I don't think we're at that point with respect to the ICMP issue. It seems to be pretty clearly a MAY. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] keyserver.gingerbear.net offline
John Clizbe has sent me a text message telling me that due to acts of God, keyserver.gingerbear.net is offline. It will be coming back up, but it's not known exactly when. John and his family are fine. ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] pool.sks-keyservers.net in seahorse
> I don't use seahorse regularly, but i recently convinced them to replace > (old, broken, non-syncing) pgp.mit.edu with a pointer to > pool.sks-keyservers.net: Didn't pgp.mit.edu convert to SKS recently? ___ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Optimum number of peers
> In theory an optimal value could be computed but there are > too many parameters (e.g. network delay and bandwidth... Additionally, these parameters are in effect constants. The SKS algorithm will have roughly logarithmic speed in propagating keys through the network: everything else (including how many peers you're connected with) affects it only by a constant factor. O(lg N) speed is *fast*. Like, really, really fast. So my suggestion: make sure you have at least two peers and you should be golden. Trying to make it even faster is kind of like trying to put racing stripes and aftermarket body kits on a Saturn V rocket: you can do it if you really want to, but there's not much point. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-network
> Why? There are some SKS servers who are sitting on the DSL lines > and have semi-static IPs. So, AFAIK, that's not a strict requirement. The strict requirement is, "your machine's IP address must be reliably accessible via DNS." So long as that's met, it's all good. And even then, "strict requirements" are more "the community of SKS keyserver operators expects this, unless you've got some really compelling reason otherwise." If you were running an SKS keyserver on the moon and were only accessible via an IP address which changed daily and no DNS, I have no doubt keyserver operators would be lining up to peer with you anyway just for the geek cred of being able to say "I'm peering with Free Luna!" :) PGP.sig Description: This is a digitally signed message part ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-network
> And there is no such thing as semi-static IP's it's static or > dynamic, if we are going to explain dns let's be correct about it :) Well, if we're being correct about it... all IPs are dynamic. "Static" just means "for a given time frame, it doesn't change." I have one friend who's had the same IP address on a DHCP lease from his cable provider for over four years now: is that a static IP, or is the fact that it could change tomorrow enough to make it dynamic? You are free to make whatever policy you want for your own servers. For me, I find that it's more useful to worry about "can I resolve this hostname?" than it is to worry about whether an IP changes. > A decent pipe -- we all know that anything less then a 1mb pipe is just > going to cause issues. I don't know this. Given the typical bandwidth used by SKS, a 128k ISDN line would seem perfectly adequate. The test should be, "do you have enough spare capacity to effectively participate," not "do you meet this arbitrary requirement." If I'm using a 1.544 MB/s T1 line to BitTorrent ISOs, well, I wouldn't consider that to be a great setup for a keyserver: although I meet the arbitrary 1Mb cutoff, I likely don't have enough spare capacity to effectively participate. (In fairness, you make this point yourself later on, which confuses me: why do you maintain both that it's spare capacity which is needed, as well as an arbitrary cutoff of 1Mb/sec? The two claims seem contradictory.) > If there aren't standards set now what will happen in a couple years? I imagine that in a couple of years we will continue to run according to "loose consensus and available servers." > I have no intentions of stirring up a bees nest but maybe SKS should > have some standards to enforce. I personally want to be sure I am > peering with stable servers and not some desktop a person uses to play > games on. I often shell into my server and use it to log into MUDs. Why should that disqualify me? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
> It will eventually become larger than a standard DVD, making it more > difficult to transport via 'sneakernet' (physical media.) Not appreciably difficult: pretty much every halfway respectable archiver on the planet lets you break up archives across multiple media. Heck, even Microsoft .CAB files support this. Also, don't discount thumb drives: I've seen 64Gb ones at reasonable price points and I'm sure larger ones are on the way. > SKS is currently the only viable keyserver in my opinion, I find it a > bit strange that every peer must have a redundant copy of every key. There are really only two options here: redundancy or uniqueness. If there's only one canonical record of each key then it becomes trivial to remove keys from the network: just take down the keyserver (either through legal threats or extralegal actions like DDoS, etc.). If each keyserver has its own record, these hijinks quickly become impractical: if your given keyserver goes down then you just move on to another keyserver. Given that neither hard drive space, bandwidth, nor physical media is a limiting factor... why should we strike redundancy? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
> But then how would you contact pool.sks-keyservers.net and reliably get a > key? All clients would need to support referrals (good luck getting *that* > rolled out universally any time soon), or just try random keyservers until > the key pops up, which would again require a change in client behaviour (and > when do you stop looking, on the assumption that the key doesn't exist?) I feel like I'm living in sin for saying this, but Bloom filters would arguably make this problem a lot easier. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
> So just wait and see until the last minute to clean it up when DB does become > a issue ? No. Wait for it to become any kind of a problem, and then solve it -- not before. Fixing things that are not problems and are not projected to become problems is an inefficient use of a highly limited resource. > Why wait ? Why can't we run a script that will at least delete keys that have > expired and revoked ? And then prevent such keys from being re-imported back > into the db ? That would be the sensible thing to do now when we don't have > any emergencies. At risk of pointing out the obvious, you've just added to the keyserver network a way to delete keys and keep them from getting re-entered into the DB. This is exactly what the keyserver network is meant to avoid. If that's possible, the keyserver system will have failed. For your idea to be adopted, the network must fail. This may explain some of the pushback you're receiving... ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
On Wed, 1 Jun 2011 15:10:01 -0400, Phil Pennock wrote: > Note that we've already lost one valued keyserver operator in Germany Austria, I think -- not that it matters to your example, but I don't want to make Austrians feel we're treating them as southern Bavaria. :) >> This is exactly what the keyserver network is meant to avoid. If >> that's possible, the keyserver system will have failed. > > Hrm, I thought the primary goal was to be a convenient way to get keys. Depends on your point of view, I imagine. > I'm happy running a free service to others, providing a reasonably > complete set of keys; but if you start making assertions about what the > keyserver network stands for, please point me to the manifesto which I'm > supposed to have signed up for as a keyserver operator, else kindly > refrain from speaking for others. I'll look around for it -- I know that when I first started becoming active with PGP, back in the early '90s, PGP had a statement of what the keyservers were intended to do -- "not allowing keys to be deleted, in order to prevent repressive governments from defeating crypto by inhibiting key exchange" was one of them. That's what I'm referring to. Admittedly, though, you're correct in that it's hardly a holy creed that we've all sworn to uphold. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
On Wed, 01 Jun 2011 15:06:08 -0700, Scott Grayban wrote: > You can search the keyserver using just the email address and they would > still get the new pub key Why would they use it? "Oh, hey, I see a new public key has been uploaded. But the one I currently have has worked for the past few years and I don't see any revocations attached to it: why should I change?" Revocations are important because they tell us to stop using a certificate. Prune away revoked certificates and suddenly nobody gets told the certificate should no longer be used. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
On Wed, 01 Jun 2011 14:33:14 -0700, Scott Grayban wrote: > The current key saving method is bulky and just so you guys can get a > idea on growth last year the dump was 3GB - as of today the dump is over > 4GB so that is at least a 1GB increase -- so if that is a sign of usage > in 5 to 10 years of growth the DB will become unmanageable -- in fact 1 > step to get into the pool is not going to work that well --> import a > current dump of the DB. Our differences of opinion seem to be here: 1. You presume bandwidth and storage media will not keep pace over five to ten years. I disagree. 2. You believe that if storage media do not keep pace, it will be impractical to break backups across multiple media. I disagree. 3. You believe that it is somehow wasteful to keep old keys around, and/or there is no good cause to keep them around. I disagree. 4. You believe these preceding points constitute an urgent problem needing immediate attention. I disagree. I don't see there to be anything further to talk about. You are certainly entitled to your views: you're just not entitled to have me take them seriously. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
On Wed, 01 Jun 2011 11:09:27 -0700, Scott Grayban wrote: > Maybe I'm the rookie here but not a linux "rookie", I have been using > linux for the past 15 years, just google my name, and I always run into > the group that would rather take the "easiest way" and ignore a issue > that is bound to come up. Appealing to credentials is unlikely to convince people. There's always someone around with more credentials and always someone around with less, and none of that makes much a difference when it comes to deciding what to do and why. I have always found a good rule of thumb for systems to be not to worry too much. If you can see a potential problem when it's on the horizon, then you can watch it for a while and decide what countermeasures need to be taken once you have a better handle on the scope and impact of both the problem and the potential solutions. Problems that are spotted on the horizon almost never come back to bite you. It's problems that you didn't see coming until they're right on top of you that can really wreck your weekend plans. Consider IPv4/IPv6 as an example -- even though we're (effectively) out of IPv4 addresses, this isn't a problem. The internet still works fine. People who needed allocations made sure to get them before we ran out. We're currently in a state of some stress to the system, but it's not any sort of calamity or disaster. Now, if IPv4 exhaustion came out of the blue and nobody saw it coming... then we'd have a big problem. Don't worry so much. :) Is the DB growing? Sure. What's the rate of DB growth? Far less than the growth rate of cheap physical storage media. Are we keeping our eyes on it? Yes. Should we do anything about it right now? Nope. If you want to talk about "okay, so what do we do if/when...", go right ahead: I think that's very constructive. Appeals to Chicken Littleism and the sky is about to fall, though -- well, I tune out. > I hear that some > people are already running into corrupt PTree db's and have to rebuild > them every few weeks... just this alone should be a warning. Cite, please. "Hearing that" is an appeal to apocryphal anecdote. Who's having these problems, and what's been done to determine the cause of the problems? > PGP (keyserver.pgp.com) has been allowing keys to be deleted for years > and they even scrub their DB of revoked and expired keys and that hasn't > degraded the trust yet. Apples and oranges. The PGP Keyserver is trying to meet a different niche than the keyserver network. Speaking just for myself, I wish them luck in achieving their goals, and I suspect they wish us luck in achieving ours. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Separate P2P Protocol Should Be Developed
> I'm starting to think that a non-reconciliation keyserver protocol should be > developed separately from SKS. This will allow the robustness of SKS to > coexist with the convenience of traditional peer-to-peer networks where nodes > with lower redundancy are constantly being added and removed. > This is one of those things that is far, far easier said than done. Yaron Minsky wrote the SKS algorithms as part of his doctoral thesis in computer science: that should give you an idea of the amount of work involved. If you wish to pursue this I wish you well and I'd be happy to point you to some good academic references, but in my experience when people talk about how something "should be done," that usually means "I want someone else to do it for me." This is Free Software. If you think it should be done -- do it, and I wish you well! ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
> reviewing, testing, and deploying a significant change to the architecture > of the SKS keyserver network... It should be noted, incidentally, that these changes would mean it would no longer be the SKS network. The SKS network is, literally, the *synchronizing* keyserver network. If the system gets changed so it's no longer synchronizing but redundancy-reducing, we really need to call it something else. So long as we say it's "just a modification to SKS," that lets people think the change is small. Once we say "invent an entirely new keyserver protocol because SKS is clearly not what these people want", that gives an idea of the scope involved. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
> categorized the U.S. as an endemic surveillance state. And since > that time it has continued to pursue private information and to do > so often without a warrant--though the FISA court has yet to decline > a single warrant request. Although I don't mean to open a political can of worms here, why do people believe the low rejection rate by FISC (they've rejected five warrants, incidentally, not zero) is evidence of malfeasance? For quite some time the gatekeeper to FISC was an FBI agent named Allan Kornblum, who knew that his career depended on FISC a lot more than it depended on the Executive Branch. He was sort of infamous for telling NSA "go away and come back with a better warrant, I'm not going to jeopardize my career bringing this to FISC, FISC will laugh at me if I bring them this and then I will never get the federal judgeship I'm looking for". Stewart Baker, former General Counsel for NSA, former Undersecretary of Homeland Security, and one of the guys who tried to foist Clipper off on us in the early Nineties, has written a book called _Skating on Stilts_ in which he talks a good bit about the bureaucratic wrangling within the intelligence community post-9/11. Kornblum is portrayed in a few different places as an obstructionist who was getting in the NSA's way. Getting warrants past FISC was not the problem, according to Baker: getting warrants past Kornblum was the torment of the damned. Baker tries to portray this as an example of how bureaucratic infighting post-9/11 got in the way of effective intelligence activities, but me, I thought it kind of said the system was working pretty well. FISC, and everything that surrounds it, is not a single monolithic entity with one single hivemind. It's a political bureaucracy, which means that it's full of strong egos in violent conflict with each other. It's tempting to see government action as the result of a single set of policies carried out by people who are in agreement about how to do things, but really, this seems to be wildly the exception rather than the rule. Usually these people can't even agree on whether they're wearing socks... ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] keyservers.org downtime
Sometime this weekend keyservers.org will have an extended downtime (multiple hours) due to maintenance work in the server room. While it's down I plan on migrating the system to Fedora 15 as well. Don't panic. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 7/29/11 11:47 PM, Scott Grayban wrote: > Why Fedora? Why use beta software for a production server? This is a whole set of rude assertions and implications masquerading as a question, and for that reason I'm going to ignore it. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 7/30/11 2:42 AM, Scott Grayban wrote: > How is that rude ? All I asked was why are you using beta software on a > production server ? Yes. And notice all the hidden assumptions and implications: 1. I am, or should be, running a production server. 2. Fedora is beta software. 3. Beta software is inappropriate for a production server. 4. Unless I have a very good reason, I'm doing it wrong. 5. I have some vague obligation to do it right. Let's address each point in turn: 1. This is not a "production server" (whatever that is: that phrase is about as meaningless as "beta"). This is the server that lives in my closet, hosts my private Subversion repos, and serves up keys. The total number of users impacted by this machine going down for even a period of weeks is precisely 1, no more, no less. My announcement to the list was so that people I peer with could have advance notice and not be surprised by the downtime. (The downtime is for a most quotidian reason: I'm rewiring part of my kitchen, and I have to throw the breaker that also controls the outlet the server lives on.) 2. Fedora is in no way beta software. It's a mature product and perfectly capable of supporting large projects, the same as any other reasonable Linux distro. I wouldn't mind in the least if someone were to run a production server on Linux Mint, for crying out loud, so long as that person was attentive and knowledgeable. 3. "Beta" is a meaningless term anyway. I've seen showstopper bugs released in "stable" releases (such as Java 7's misoptimization of loops) and I've seen beta software that's impressively reliable and feature-complete (GMail). Discounting something just because it's beta software is a cop-out: it means, "I am going to latch onto this label and think it means something because doing my own evaluation of the software is too difficult." 4. I reject this one out of hand. 5. Sure, I do. But I don't think you've got much of a place to stand on declaring what is or isn't right. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] HTML5 in index page
On 8/29/11 2:17 AM, Phil Pennock wrote: > After seeing Samir's suggested index.html page, I decided to make a few > updates to my own. It's a nasty competitive streak that sometimes comes > to the fore. Although I don't mean to dissuade anyone from following their muse, why HTML5? Wouldn't 401+CSS be better supported by existing browsers? Or does 5 add some vital capability that I'm just completely missing? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] HTML5 in index page
(I hate to sound unhelpful: it's only because I'm presently @work and can't spare the time to give this the full attention it deserves. Expect more later.) John, although I heartily approve of what you're trying to do, your page does not pass the W3C's validation tests: http://validator.w3.org As of right now, your page has almost 80 errors -- most of which seem attributable to just a very small handful of errors on the page. Kind of like template errors in C++, one error can result in many more spurious error messages. I'm sure it can be fixed without too much headache, though, and I'd be happy to work with you on it. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Invalid Signature
On 9/23/2011 5:48 PM, Timothy Holtzen wrote: > Thanks for the suggestions. Assuming signing worked on this > message, turning on PGP/MIME seems to have resolved the issue. Looks good. As a word of warning, though, PGP/MIME is known to *not* work with older versions of Mailman. Older versions of Mailman will break PGP/MIME signatures. I'm making no policy recommendations here: just want to make sure people are aware of the Mailman issue with respect to PGP/MIME. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Request for SKS key server peer connection
On 9/26/2011 10:51 AM, Timothy Holtzen wrote: > Is it just me or is that not a valid key ID. It's just you: it's a valid key ID. A complete key ID is the same as the fingerprint of the key. A "short ID" is the final eight hexadecimal digits of the key; a "long ID" is the final sixteen; a "full ID" is the complete forty. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyserver.cns.vt.edu updates
On 10/14/2011 1:39 AM, oakwhiz wrote: > In my opinion, you're better off with a self-signed certificate, > because you cannot trust the certificate authorities not to sign a > fake certificate for use in a man-in-the-middle attack. Although there are certainly some unreliable CAs (Diginotar as an obvious example), I think it's a leap to go from that to saying there exist *no* reliable CAs. > Isn't this the point of using the OpenPGP trust model instead of the > flawed X.509 trust model? OpenPGP and X.509's trust models are essentially interchangeable. They work in fundamentally the same way, to the point where the commercial version of PGP lets you use OpenPGP certs as X.509 certs and vice-versa. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 3 million keys & and community help requested
On 10/15/2011 7:51 AM, John Clizbe wrote: > I still think we have a ways to go to make SKS portable to more operating > systems -- I think MacPorts provides the better framework than Fink to do this > on OS X. I belong to the "a pox on both their houses!" school myself, when choosing between Fink and MacPorts. I have generally had better experiences with Fink, but both projects seem to be alarmingly incomplete in fundamental ways. > Cygwin port anyone? Ocaml and bdb are already there :-) What might be interesting is to port it to F#. F# is a heavily Ocaml-influenced functional language from Microsoft that runs atop the .NET runtime. A port would be nontrivial, but would allow us to run the same codebase on Win32, OS X, and most of the free Unices. > As well as ideas as to what type of sample web pages to to include. I also > think > if we are going to go that far, we shuld also provide sample membership, > mailsync, sksconf, DB-CONFIG for both KDB and PTree. As an FYI, I'm currently looking around to find *good, competent* Web designers. (I've found several designers I don't want to work with. Alas, competency and graphic design skill are hard to find in the same person.) My goal is to hire them to design good-looking web pages for SKS, with all styling done by CSS to make future editing easier. (And yes, I'm aware of the SKS webserver's limitations: those, too, are part of the spec.) If anyone knows of *good, competent* Web designers who would like a small paying gig that's only a few pages long, send them my way, please. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 3 million keys & and community help requested
On 11/2/11 5:49 AM, Andrey Korobkov wrote: > Is there any chances that SKS would be ported to some other, more > common databases like MySQL? Berkeley DB isn't quite ubiquitous, but it's close. > What is the reason behind choosing BDB as a storage? It is exactly as much hammer as we need for the nail. MySQL and its ilk are tremendously capable databases that can do everything up to and including preparing your morning latte. We don't need those capabilities. Berkeley DB is much more limited, basically working on key/value pairs... which happens to map quite neatly to our problem domain. > I think, having SKS work with client-server databases rather than > file-based could give it more scalability... I hate to sound harsh, but in my experience the overwhelming majority of the time complex systems do not act in ways that conform to our thoughts and expectations. If you believe this is a good idea and worth pursuing, I'm sure many people on this list would welcome performance metrics between Berkeley and MySQL/MariaDB/Postgres. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 3 million keys & and community help requested
On 11/2/11 3:08 PM, John Clizbe wrote: > One would need to ask Yaron to verify why BDB. A former co-worker of mine used to play college football. One of his engineering maxims came from his time on the gridiron: "if the instant replay doesn't make the right call clearly obvious after three watchings, there is no wrong call." There's a lot of wisdom there. The question may not be why Berkeley was chosen, nor even why the others were not chosen. The question may be instead, is there anything clearly and obviously better than Berkeley DB? My position is 'no,' and for that reason I think asking for justification for Berkeley DB is kind of pointless. If there's nothing obviously better, then why are we interested in his decisionmaking process? > Indeed, IME the single worst bottleneck in SKS is the initial loading > of the database from a keydump. One of my development boxes actively > syncs with several SKS peers. It runs quite well on a 500MHz Sun > Blade 100 with ATA/33 disks and 2GB of RAM. [Takes a while to load > though :-( ] > > Next up is WAN bandwidth, but that's usually only an issue when a > server initially peers or comes back online after a long absence, and > only the first recon peer will see the slow down. Ack. The bootstrapping process is the most difficult part. After that, running a keyserver is a remarkably low-load process. When I run top I invariably discover that it requires more CPU and memory than sks! [rjh@keyservers ~]$ uptime 15:17:40 up 52 days, 22:10, 3 users, load average: 0.14, 0.05, 0.06 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 3 million keys & and community help requested
> Reliable is *entirely* in the eye of the beholder. Agreed. > The core problem is extrinsic (as in dependent on the amount of > data) interdependent tunables... While I agree with your discussion of the external factors, I'd like to point out that any modern database -- regardless of whether it's MySQL, MariaDB, Postgres, BDB, or what-have-you -- will have approximately the same amount of external factors. As far as I can see no vendor has yet managed to field a database that yields good results on real-world datasets without some sort of tuning. This is of course not in any way a disagreement with your statement: just further emphasis. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Requesting your thoughts on a web of trust scheme
On 12/9/2011 12:36 AM, Daniel Kahn Gillmor wrote: > I'm not sure this is OT on sks-devel, unfortunately, so it'll be my last > post on-list on this thread. Likewise, although I suspect here is as on-topic a place as we'll find. >> http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal > > I see two main ways the proposal could use improvement as presented: I'll reduce my criticisms down to a very simple one: Trust is a human concept, not a mathematical one. We all know someone who trusts someone they shouldn't, even though they know better. Odds are good that we're examples of this ourselves (I know I am). OpenPGP gets around this by using the word "trust" in an extremely narrow sense, one that makes it useful for a particular task and not much more. This proposal never defines trust with sufficient precision for me to feel comfortable with the document: it attempts to create an infrastructure to support ... what, exactly? Until the problem can be precisely and accurately described, no solution is possible. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Requesting your thoughts on a web of trust scheme
On 12/11/2011 8:55 PM, Daniel F wrote: > Please see my response above. I am sorry if the proposal as is > didn't make it patently clear, but it was originally written for > people with the right context, and I failed to realize that there is > that significant omission from the POV of a third-party reader. As > per above, this is about trade trust, and nothing else. In that case, I think this proposal fails to take into account the major problems with economic trust over the internet. The principal one is the internet offers both ephemeral identities and pseudonymous identities. If I'm J. Random Person, I have an incentive to become trusted to the point where someone trusts me with a big trade, and then I have an incentive to betray that trust, walk away from my ephemeral pseudonym, reap my windfall and start over again somewhere else. There are a lot of ways people have tried to solve this. You can try to structure trades such that the benefit of future trades is always greater than the benefit to be had from selling out on any one particular trade: but that involves unrealistic models of economic growth. You can try to abolish ephemerality or pseudonymity, in which case, the trust metric becomes quite straightforward and you really don't need this system. (I gave a large sum of money to a complete stranger a few months ago in order to purchase a Mustang GT sports car. Didn't bother me in the slightest -- I knew who he was, I knew where he worked, I knew how long his business had been in operation, and he knew that if he screwed me over I'd sue him. I could've paid for it in BitCoins via an electronic transaction and told him to leave the car in my apartment building's garage and the keys at my desk, and still been perfectly confident the car would've arrived as ordered. The existence of enforceable contracts radically simplifies trust calculations.) Anyway. I hate to sound dismissive, but -- I think you're solving the wrong problem and not paying enough attention to the eight hundred pound gorilla in the room. And with that, I think I'm done here. It's not that the question isn't interesting, but we're now entering the realm of game-theoretical questions and that's unquestionably off-topic for this list. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] How many is too many?
On 1/24/12 2:13 PM, Javier Henderson wrote: > At what point (if any) is adding more peers to a given keyserver detrimental? Impossible to say. There's a theorem in mathematics that makes it clear two peers are sufficient for performance, and the more the merrier -- up until the point your line gets saturated. So this is really a question of your bandwidth, and not a question that has a clear answer. (The Grocery Line Theorem: if everyone approaching the checkout lines at a grocery store looks at two lines and moves to join the shorter of the two, all lines will, to a very high probability, maintain an equal length. With a little work it can be made to apply to keyservers. If everyone were to pick just two peers to sync up with, and synced with the server holding the fewer keys, all servers would sync quickly and remain in sync.) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] RFC: Index file search order
On 04/12/2012 09:33 PM, Phil Pennock wrote: > "index.shtml" should probably go: that's for server-side includes, as > processed by Apache and some other servers. The > stuff, a bit like PHP or other inline scripting markup systems. Speaking purely for myself, I've never seen .xhtm used as an extension for .xhtml. Doesn't hurt us to include it, of course. Agreed re: omitting .shtml and ensuring correct Content-Type: headers. With that said, I think the order in which they're served up is mostly irrelevant, so long as that order is well documented. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
On 04/20/2012 04:32 AM, Sebastian Urbach wrote: > Just for everyone who depends on a debian sks package. I complained to > the the debian project about Christoph Martin (Main Debian SKS > developer) and im also trying to get him removed from that position as > well. This is unlikely to get the results you want. The best way to remove someone from a maintainer position is without fuss and without making a scene: all other options produce ill-will and forks. I would suggest instead putting together your own SKS package for Debian, and seeing if you can get keyserver operators to use it. Once you have a 1.1.3 .deb packaged, debugged and with good support from the community, you'll have much more leverage to push for a change in maintainership, and there will likely be a lot less drama. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
If we're in need of 1.1.3 packages for Debian and Debian-derived distros, I might be able to help. My OCaml is no better than functional (pardon the pun) and my knowledge of .debs is far from comprehensive, but I have free time to devote to this. At present I have zero interest in "taking over" from anyone. I think any discussion of that is incredibly premature. But if we need 1.1.3 .debs, I'll do my best to get some stitched together in the next few days. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
On 4/20/12 2:22 PM, Daniel Kahn Gillmor wrote: > I suspect the trickiest parts might be thinking about how to get a > smooth upgrade from 1.1.1 and possibly how to deal with a transition > to a newer version of bdb or ocaml. But i haven't looked into it > beyond that. Oh, ouch. Yes, I hadn't thought of this. But the least I can do is look into it, and see if a solution is within my skillset. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
On 04/21/2012 01:28 AM, Daniel Kahn Gillmor wrote: > If the packaging meets debian quality standards, i think we can pretty > easily get it into debian proper -- no need to host it on the google > code download page. I've never packaged for the Debian trees: I've only ever made .debs for my own local installation. Should I set up a VM with Debian Unstable and build against that? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
The other major problem with static linking is it forces the maintainers to sync their releases with BDB security releases. If a defect is found in BDB and sks is statically linked, a new sks has to be released. If a defect is found in BDB and sks is dynamically linked, no new release of sks needs to be made. Static linking has a place, but the place does not appear to be here. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
On 04/29/2012 05:42 PM, Jeffrey Johnson wrote: > If there were any BDB "security releases", you might have a point. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1436 Yes, that's actually a bug in the libc db interface, not BDB itself, but the point still stands: this is something that would be embedded into sks with static linkage, and something that could be trivially fixed out-of-band with dynamic linkage. No nontrivial piece of software -- I repeat, *no* nontrivial piece of software -- has *ever* been released without security bugs, and it is both unprofessional and reckless to state otherwise. If you don't understand this, then I think we're done here because we're not going to agree on anything. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS debian package
> You are very very confused: db-1.85 went end-of-life > in like 1994 Not at all. That advisory, if you missed it, is from 2009. I really don't care if db-1.85 was EOLed in 1994, 1984, or 1974. What I care about is that it *is still used today* and there are, within recent memories, reports of serious problems with Berkeley DB. This counters what you say in "if there were any BDB 'security releases', you might have a point." There have been security problems with BDB, either directly in BDB or in the software ecosystem surrounding BDB, and I believe sks is well-served to avoid the embedding problem by using dynamic linking. And that's all I have to say on the subject. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Debian binary replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/10/2012 06:34 PM, Arnold wrote: > The readme says: "This ... version ... is intended to humiliate > and expose the following persons" Likewise. More to the point, when using a precompiled binary one must trust the good intentions of the packager. When I see something like this, it leads me to distrust the packager's intentions altogether. This package is in very poor form, and I am happy to have nothing to do with it. -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iFYEAREIAAYFAk+sS60ACgkQI4Br5da5jhCfiQDfUqXYvsOk3bJvCECaY8BF+XZK BNgbSu8TX9pr/ADfYgFe21QDzpyY7ypmut7VCXpB1wuyqth5Nd+Egg== =OwBG -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] De-peer sks-peer.spodhuis.org please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/11/2012 05:02 AM, Phil Pennock wrote: > The SKS peering mesh is built upon trust; in no small part, because > the peering algorithm can cause load upon your peers. Recent > events have forced me to re-evaluate two of my peerings. I have nothing to add here except that I have followed suit. -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iFYEAREIAAYFAk+tEx0ACgkQI4Br5da5jhCzgADgilQCsdTn6EbB72Y9wQjxQmv3 2H3jrc7C6dqgtwDgo35a2Ck4I9h3nmPsJ9Yp/HEXUkzDIZWw4IBe/A== =rGXd -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] De-peer sks-peer.spodhuis.org please
On 05/11/2012 10:34 AM, Sebastian Urbach wrote: > server name(s) to delete ? keyservers.org, please. Thank you. signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] New Debian Binary Replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 5/14/2012 9:41 PM, John Clizbe wrote: > I hereby inquire as to the availability of source code for your > release. Although I'm neither an SKS maintainer nor a Debian SKS administrator, I have to say the lack of source code confuses me. There are certain minimum standards associated with the GPL, and source availability is one of them. There are also minimum standards associated with software essential to security infrastructure, and likewise source availability is one of them. So, yes. Although I've not received a copy of the forked binary, I would strongly encourage Jens and Sebastian to make a tarball available post-haste. I would also encourage them to change the name of their release: "sks" refers to the package officially maintained by Yaron Minsky, and referring to their repackaging (and yet-to-be-approved patches) as "sks" will create needless confusion among the community. I'm not one of these people who believes forks are evil and must be avoided. Forks can foster wild creativity: look at, e.g., gcc => egcs. But just as egcs had the courtesy to stop calling themselves gcc (until such time as egcs became officially blessed by the gcc devs as the next release of gcc), this package needs to have the same courtesy. I believe that if source is published and the name of the package is changed, this will address pretty much all the concerns voiced by people on this list. So, my requests: 1. Source code 2. Change of name 3. An end to all this useless squabbling -BEGIN PGP SIGNATURE- iFYEAREIAAYFAk+xt6IACgkQI4Br5da5jhCzswDfSBzkbfZDifQkEZoyzAUTbbIE WRQVgtVa7eavFgDfcL2kco6lGopZRHlNCDKjFy0Xe4LZTLKZvdgwXA== =0QgB -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Request for reporting of upstream bandwidth capacity
On 05/16/2012 01:12 PM, Kristian Fiskerstrand wrote: > As upstream bandwidth capacity is one of the considerations that is > taken into account in [0] I would appreciate if the server operators > that have not already done so would kindly email me this information > off list (My UIDs in 0x6b0b9508 can be used for this). This is sort of a black art. Depending on which online service is providing the test, I've seen my upload and download speeds vary by more than two orders of magnitude. Further, since pretty much all cable ISPs were at one point in league with the Devil before finally usurping Lucifer's throne, I can't even rely on the vague promises made by their tech support imps and balseraphs. This isn't to say there's no point in what you're doing -- I think there's a lot of merit to it! -- but if we all use a different service we're going to introduce an awful lot of statistical noise. Is there any particular bandwidth capacity test that you would prefer we use? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 5/27/12 5:50 AM, Giovanni Mascellani wrote: > I'm just a newbie here, but actually I'd like to see the same concept > applied in a more general way: I think there is much garbage in the > keyservers, even behind the PGP robo-signer. The problem here is this violates one of the principle design features of the keyserver network: "We never, never, never lose certificates." It is preferable for a keyserver to outright go down than it is for even one certificate to be lost. If a certificate is lost then a malicious actor could re-upload another key with the same short ID (a very easy thing to do), and that could facilitate all different kinds of attacks on people who don't properly validity-check certificates before using them. If the keyserver goes down then everyone knows in short order there's a problem. If a certificate is lost and silently replaced it might be a long time before being discovered. (Discovery is more likely if the keyserver is synchronizing with others, but there are a lot of standalone servers.) Further, expired certificates are still useful. I have some emails more than five years old that are still relevant and useful. If a certificate gets removed just because it expires, how am I to check the signature on those messages in order to ensure they haven't been tampered with? If the expired certificate remains on the servers, though, I can download it, validity-check it, and be confident in the integrity of my message. The same logic applies to revoked certificates: they're still useful for the same reasons. The keyservers never, never, never lose certificates. That's a design goal and one that the SKS maintainers believe is a good one. I agree with them, and want to see this design goal maintained in all future development. That said, welcome to the community, and please understand that although I think your idea is awful I'm honestly happy to see you here. :) The mailing list is a place where ideas come into violent collision, but we try to be reasonable human beings to each other. Welcome! ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 5/27/12 6:53 AM, Gabor Kiss wrote: > My idea: there shoud be five wise and trusted peoples -- i.e. > a committee. Theoretically possible, although it'd be very difficult to find five people the entire PGP community could/would trust. As soon as you introduce a committee of people with some kind of special power, you open the door to conspiracy theories and every whackjob out there screaming that the Keyserver Committee is the Second Coming of the Trilateral Commission. The completely decentralized nature of the keyserver network is a strength, not a weakness: it means there's no central authority which can be corrupted or subverted. As soon as there's a committee, the door is open for malicious actors to start applying leverage for their own ends. So, yes, this proposal is technically possible but I can't imagine it's politically possible. Too much disagreement over who ought be on the committee, and too much opportunity for malicious actors to exercise leverage. Plus, the instant there's a committee the committee members will likely become legally responsible for the content of the network. If someone were to upload child porn to the keyserver network in the form of an image masquerading as a photo ID, the committee members could arguably be on the hook for criminal prosecution and/or civil liability. Frankly, I don't want that. I already have enough nightmares about running just one keyserver and the possible liabilities that could result without becoming responsible for *all* keyservers in *all* countries and *all* jurisdictions. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] RFE: max-*-size and strip-photo-uids
At present, there are no credible reports of the keyserver network being used to distribute illegal data. I'd like to repeat that: at present there are *NO* credible reports of the keyserver network being used to distribute illegal data. Please don't think I'm crying that the sky is falling, because it clearly hasn't fallen and we might go decades more without the sky falling. That said, the best time to prepare for a crisis is before the crisis hits. I would like to propose two feature requests for SKS. One (which I'll just call the "max-*-size" feature request) will limit the maximum size of a user ID, user attribute, subkey, signature, etc.: anything larger than this will not be accepted into the database nor shared with clients or other servers. This will help prevent the network from being used to distribute arbitrary binary data, although it could still be evaded by, e.g., breaking a large binary into a bunch of signatures and placing them on the certificate in order, so that they can be reassembled on the other side. The second (which I'll call the "strip-photo-uids" feature request) will strip all photo UIDs regardless of size. Again, this is not an ironclad solution: dedicated malcontents will just encode their images some other way. *These feature requests have clear, obvious downsides.* (Not the least of which is they won't work particularly well.) I don't believe either of these features is ready for implementation, but I hope that if we talk about it for a while we might be able to reach a better idea that will more appropriately address our needs. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] RFE: max-*-size and strip-photo-uids
On 5/27/12 7:10 AM, Robert J. Hansen wrote: > *These feature requests have clear, obvious downsides.* (Not the least > of which is they won't work particularly well.) So, the first question is -- what would be necessary for a solution to work well? The brute force and overkill approach: sanity-check each imported certificate to ensure that the subkeys on the certificate are legitimate cryptographic keys. Note: this is barking madness. If I give you a block of bits and say this represents two numbers, the first being the product of two large primes and the second number coprime to the first -- e.g., the (n, e) tuple of an RSA public key -- the only way to prove it's a legitimate public key would be to factor the first number and ensure that pq=n with p and q prime, and that e is coprime to n. If the only way to prove that a block of data is a correct RSA key is to break RSA, then we're absolutely screwed. So much for the brute force and overkill approach. We simply cannot check to ensure that an RSA public key is good. This may leave the door open to checking whether an RSA public key is obviously *bad*. To check for obviously bad keys, we could do trial divisions on all the primes up to, say, 10,000. A naive encoding of binary data onto a purported RSA key would likely have a factor somewhere within that range. Presto, we have a way to detect bad RSA keys. Unfortunately, it's completely bogus. Someone could simply do a naive encoding, then keep on adding 1 (well, 2, since they're smart enough to avoid even numbers) until they found a value that had no small factors. To recover the original number they just start subtracting 2 and repeat until such time as the CRC code in their data checks out. There may be other such ways to check for bad keys, but I suspect they're all going to face the same problem. I don't think there's a cryptologic solution to this. It may be more worthwhile for us to look at the data forensics community, to see if they have any tools that can quickly and efficiently find media files that may be embedded inside other files. (This was part of the DFRWS 2006 challenge, incidentally, so I know the forensics community has looked into the problem.) Anyway. Thoughts? Ideas? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 05/31/2012 12:57 AM, Gabor Kiss wrote: > There is no guarantee that one can trust all of current key servers. This is why users are encouraged to use a keyserver they *do* trust. This is why keyserver operators are encouraged *not* to peer with others they don't trust. Some operators on this list managed to get themselves de-peered not long ago as the result of actions that made other people lose trust in them. Really, that's a nonissue. > If I was related to certain Asian governments I'd set up a fake key > server that is the only reachable from the country then I'd > serve manipulated keys to certain clients. How do you propose to manipulate those keys? Do you have some way of breaking RSA that we don't know about? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 05/31/2012 01:41 AM, Gabor Kiss wrote: > You have trust a long and thin chain of signatures between you > and your abroad comrade. What if a government agent edged in the chain? 1. Then you're goatscrewed, because you're trusting the wrong people, and there is *no* technology that can help you 2. There is no #2. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] SKS segfaulting on Fedora 17
keyservers.org is a Fedora 15/x64 system running on hardware that's
coming to the end of its expected useful life. isaiah.keyservers.org is
a Fedora 17/x64 system running on much newer and beefier hardware. The
old system runs SKS 1.1.1; the new runs SKS 1.1.3. Both come from the
Fedora repos.
I made a dump of the current KDB from keyservers.org and migrated it
over to isaiah, where it was placed in a subdirectory 'dump' off of my
sks dir (/var/sks).
Once there, from /var/sks I did an sks build run as follows:
sks build -n 10 -cache 100 /var/sks/dump/*.pgp
And bam, instant segfault. build.log is not useful:
2012-05-31 01:51:59 Opening log
2012-05-31 01:51:59 Opening KeyDB database
That's it. Running gdb on the sks binary reveals:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Loading keys...done
Program received signal SIGSEGV, Segmentation fault.
SHA1_copy_and_swap (numwords=, dst=0x7f7feff0,
src=0x77cbe948) at sha1.c:38
38 d[0] = s[3];
(gdb) l
33unsigned char * s, * d;
34unsigned char a, b;
35for (s = src, d = dst; numwords > 0; s += 4, d += 4, numwords--) {
36 a = s[0];
37 b = s[1];
38 d[0] = s[3];
39 d[1] = s[2];
40 d[2] = b;
41 d[3] = a;
42}
Now for where things get wacky: running the exact same command, but with
-n 20 instead of -n 10, causes a segfault in a different part of the code:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Loading keys...done
Program received signal SIGSEGV, Segmentation fault.
0x00509713 in caml_darken ()
(gdb) l
1 /* interp - add information about dynamic loader to shared library
objects.
2 Copyright (C) 1996 Free Software Foundation, Inc.
3 This file is part of the GNU C Library.
4
5 The GNU C Library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 The GNU C Library is distributed in the hope that it will be useful,
... If any of the SKS maintainers want to take a look at this _in situ_,
I'd be happy to provide access to isaiah for debugging purposes.
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 05/31/2012 09:30 AM, Kiss Gabor (Bitman) wrote: > What if you have no choice? Let me repeat: if you're trusting the wrong people then you're goatscrewed and there is no technology that can help you. There is no Option B. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS segfaulting on Fedora 17
On 05/31/2012 09:33 AM, Robert J. Hansen wrote: > Now for where things get wacky: running the exact same command, but with > -n 20 instead of -n 10, causes a segfault in a different part of the code: -n 5 crashes in yet a different place, although it manages to actually get through a couple of the .pgp files first. The dump files are large (50,000), but the server is fairly beefy: 32Gb RAM and an i7. It shouldn't be hitting any hardware limitations: it's far more capable than the current keyservers.org is, and it handled this without a hiccup. I have no idea what the root cause of this segfault is, but it certainly seems interesting. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Bitbucket?
On 5/31/12 11:58 AM, John Clizbe wrote: > Other than the name being somewhat offensive in some English speaking > countries? I'm going to chime in here on the side of the "git isn't necessary" crowd. Git is a fine RCS for large distributed projects. For the Linux kernel it's almost ideal. But SKS is not a large distributed project: it's a fairly small one, is unlikely to grow into a huge one, and I'm not sure it's worth the additional complexity over other simpler RCSes. Feel free to emphatically disagree, of course. :) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Downtime
John's weather troubles are apparently contagious. keyservers.org was down for a few hours due to thunderstorm and tornado activity in the Maryland area. Service is now restored. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 06/04/2012 03:28 AM, Gabor Kiss wrote: > Actually it is not true that SKS does not modify certs. AFAIK, no one in this discussion ever claimed it does. It was claimed that SKS never deletes information, which rather moots the rest of your email. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 6/4/12 5:55 AM, Gabor Kiss wrote: >>> Actually it is not true that SKS does not modify certs. >> >> AFAIK, no one in this discussion ever claimed it does. > > I did not say that someone stated this. :-) Then why did you say "It is not true that SKS does not modify certs"? You're arguing against something that no one claimed and which no one believes. I don't understand the point of that. > However I say: if one kind of modification is allowed > then the other is also possible. No. Because if you drop signatures, you are losing information, and several people have come out quite adamantly against SKS losing information. > If somebody uploaded a key 10 years ago that had or has expired > signatures but he don't touch it key server does not execute any arbitrary > changes. It may drop invalid signatures under control of the end user. (I'm assuming by "invalid signature" you mean "bad signature.") No, it can't. The only way to determine if a signature is bad is to do a cryptographic operation, and SKS has no cryptographic code. Expired signatures can still be meaningful, so they must not be dropped. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 6/4/12 4:15 PM, Jeffrey Johnson wrote: > Insisting that SKS key servers *never* undertake some reasonable > policies for sound engineering purposes isn't subject to the number > of adamant objectors, but rather to sensible discussion. There's a difference between saying "these signatures should never be dropped from the servers" (which is my position) and "these signatures should always be presented to clients" (which is not my position). If a client explicitly requests for a sanitized certificate, I see no reason that SKS should not respect that request: but SKS itself needs to keep track of this data. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 6/4/12 4:27 PM, Jeffrey Johnson wrote: > But there are also reasons to add better policies like "Do Not > Modify" or "I live in the EU and privacy laws permit me to insist > that my pubkey be removed." to manage server-to-server distribution. The problem here is that the keyserver network would quickly become the lowest common denominator among all these. The U.S.-based keyservers would need ways to remove infringing copyrighted material (DMCA takedown notices), the EU-based keyservers would need ways to remove to conform to privacy laws, and so on. Taken to the logical conclusion we'd be left with a keyserver network that was the set union of all the legal restrictions of all the countries in which participating keyservers operated -- and I think that would be a not-very-useful-at-all network. Better by far, I think, for the keyserver network to undergo a planned fracture: EU and US keyservers running in separate pools and periodically syncing up. > But arguing that the problem should not be considered because "… > several people have come out quite adamantly …" isn't exactly a > healthy discussion. When have I ever said the discussion shouldn't be had? I've only ever said that the keyservers have always been guided by a "no loss of information, ever" policy. And I've also outright said that we need a way to change this policy, because otherwise we're one [insert legal challenge] away from all of us having to shut down permanently or else fear criminal charges for [criminal offense or EU data privacy directive]. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?
On 06/04/2012 09:56 PM, David Benfell wrote: > This isn't seeming consistent to me. How do you reconcile... Quite easily, actually: >> I've only ever said that the keyservers have always been guided by >> a "no loss of information, ever" policy. My position is: "Keyservers have always been guided by a 'no loss of information, ever' policy." >> And I've also outright said that we need a way to change this >> policy, because otherwise we're one [insert legal challenge] away >> from all of us having to shut down permanently or else fear >> criminal charges for [criminal offense or EU data privacy >> directive]. My position is: "We need a way to change this." Really, what's so inconsistent about saying "this is the way things are, and I believe it is in need of change?" It's true, there's quite a bit of nuance in my position: it's served up with a soupçon of "we should make sure we understand exactly why the original design was this way," a garnish of "I'd rather have the less-than-optimal current behavior than a poorly-thought-out 'solution'," and a dollop of "it's quite likely that a solution for the particular imperatives faced by U.S. keyservers will not be the same as a solution for the particular imperatives faced by E.U. keyservers," but as I said, that's just nuance. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Social media and keyserver operators?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/14/2012 07:09 PM, Phil Pennock wrote: > As you move away from lists dedicated to highly technical > concepts, those assumptions break down and it becomes more > challenging to encourage folks to do some homework first before > posting so that everyone else will see what they ask. Not only that, but part of the 'homework' at this level is collaborative. Many times before posting to this list about a subject I've run my idea past John Clizbe as a sanity check -- I think a good ninety percent of the reason why people take me seriously is John has the good grace to shoot down my more outrageous notions. Encouraging social contact between keyserver operators, so that we can come to our own estimation of each others' skills, capabilities and integrity, seems to be significantly in the best interests of the community. > The closest to something useful for us would be the Hangouts > feature of Google+, for incident response for a major issue, or > simply to debate. Let's not overlook the more everyday reason: to know each other better. There's a major problem, though: how do we convince the community of OpenPGP users that we're not conspiring behind-the-scenes? If we point users to the archive of videoconferencing, how can we persuade possibly-skeptical users there do not exist any unrecorded conferences? And for that matter, is it even possible to do so? (My thinking on that one is 'no', by the way, and my belief is Phil is likewise of this opinion.) So, yeah. Consider this a very longwinded "me, too!" post which emphasizes the social part of keyserver operators talking to each other. :) -BEGIN PGP SIGNATURE- iFYEAREIAAYFAk/ane8ACgkQI4Br5da5jhBf+wDeOLNMxNHcGuNFfH3wtYkgtvrA ewxMxrfd6CeWtwDghl7JnAq+W8Sn5CDLDWsq4tlYU1FS+ZIMyKYLJQ== =LCs9 -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] keyservers.org downtime
Due to a catastrophic set of thunderstorms that have hammered public utilities in the DC area, keyservers.org is experiencing prolonged downtime. I don't expect it to be operational for the next couple of days, and the downtime may extend more than a week. My apologies to those who are inconvenienced -- but I think you'll be more inconvenienced by Netflix and Instagram outages related to the same storm series. :) http://www.nbcwashington.com/weather/stories/Storm-Damage-Images-160950865.html The entire DC area looks like that right now -- it's really eye-popping. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 6/30/2012 4:31 PM, Javier Henderson wrote: > Weird. Not particularly: Ashburn is about 30mi/55km due west of my location. The storm hit the greater DC Metro Area badly, but 55km due west is well out of the Beltway. > keyserver.kjsl.org is at Equinix in Ashburn and remained online. This > datacenter is near Dulles airport, for those who care to look at a > map and compare locations with the storm path. "Near" means it's about as far beyond Dulles as from Dulles to my location. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 6/30/2012 9:31 PM, Brian D Heaton wrote: > Glad you and yours are all in one piece. With no power to over a > million folks, the next few days may get a bit "interesting." Thanks, Brian. Yeah, as of right now 1.3 million people are without power during one of the worst heat streaks DC has ever recorded for the month of June. Pepco, the local power utility, says it may take between a week and fifteen days to get everyone back operational. Power around here has been solid as a rock, but TV and internet are both out and connectivity is provided by a 4G wireless card for my laptop. Traffic and street lights are out all over the place. So, yeah, if you're peered with any keyserver in the greater DC Metro Area, be warned they may be down and may be unable to check in here to say so. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 7/1/2012 2:49 AM, Gabor Kiss wrote: > Why don't put a CNAME record of keyservers.org pointing to a working > server? Most of your users won't notice the difference. :) Because that's fundamentally dishonest. Some people use keyservers.org indirectly through pool.sks-keyservers.net. These people genuinely don't care where their certificates get served up from: they just care their certificates get served. Some people use keyservers.org directly by specifying it at the command line. Not necessarily because they trust me, mind you -- it's just as likely that they use keyservers.org directly because they want to know who it is that's running their keyserver, and they don't want to accept a certificate served up by someone completely anonymous. Many of these people have their tinfoil hats wound too tight, but it's possible that some of these people may have good and legitimate reasons for wanting *one particular* keyserver rather than some random keyserver. I would rather keyservers.org had a week of downtime than I would silently redirect its traffic somewhere else. I won't do it. If someone requests a certificate from keyservers.org, I should either service that request myself or it shouldn't get done at all. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 7/1/2012 3:26 AM, Kiss Gabor (Bitman) wrote: > I respect your opinion but I don't agree. Sorry. What precisely do you disagree with? > _All_ key servers of the pool are absolutely untrustable by definition. Not true. For instance, I trust John Clizbe. If I receive a certificate from him, I'm pretty confident that he's not, e.g., logging my certificate requests and turning it over to the cops. You, on the other hand, I don't know you, and for all I know you're doing those sorts of things. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] keyservers.org downtime
On 7/1/2012 5:26 AM, Kiss Gabor (Bitman) wrote: > No matter which key server a key I get from. > No matter who operates a key server. > The only important thing if a key is signed by trustworthy peoples or not. In your security model, sure. But please don't go about telling the world what their model should be. In your world, "by definition" all keyservers are equally untrustworthy. But other people have different worlds, and they get to come up with their own definitions, and many of them are based on reason and due caution. > Why do you trust John? Why would I tell someone I don't trust -- you -- the reasons for the trust I've invested in John? > Why do you think peoples trust _you_? Why would I tell someone I don't trust -- you -- the reasons for the trust other people have invested in me? For whatever reason there are a fair number of people who trust me to give good counsel and to be fair in my dealings with the community. I value the trust these people have invested in me, and for that reason I will not redirect keyservers.org somewhere else. > If a user was cautious, (s)he would download thousands more keys (s)he > need or operates an own key server. Again, you keep on defining threat models for other people. You have the authority to declare what your model is. You really don't have any footing to declare what someone else's model should be. Nobody does. > a trusty key server. (I hope you know at least one beside yours. :-) > If some users trust you as a key server operator, they must > trust your choice of fallback server too. This is flat factually wrong. Trust is not necessarily a transitive property. See, e.g., "Why Isn't Trust Transitive?", _Proceedings of the International Workshop on Security Protocols_, 1997. http://dl.acm.org/citation.cfm?id=720377 In *some* models, trust *is allowed to be* a transitive property. However, transitive trust is not a general property of all models, and definitely not a general property of keyservers. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Another outage
keyservers.org had another brief (couple of hours) outage today due to another thunderstorm in the DC area. Power and internet has since been restored, but thousands of people in the DC area aren't yet as lucky. Other keyservers in the DC Metro Area may be down as well. Apparently, the local power utility is unable to keep service going whenever there's a single lightning bolt within twenty miles of the Washington Monument. I apologize to those inconvenienced. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] sks recon crashes with ptree corruption
John Clizbe and I have both had a problem recently with sks recon
crashing in a way that completely borks the PTree/ subdirectory. If
your sks recon process dies and, upon restarting it, you see this in the
log:
2012-08-10 00:38:56 Raising Sys.Break -- PTree may be corrupted:
Failure("remove_from_node: attempt to delete non-existant element from
prefix tree")
2012-08-10 00:38:57 DB closed
... then you may join the ranks of those affected by this bug.
There is no fix yet, nor do we know exactly what's causing this bug to
manifest. For now, if your PTree/ subdir gets borked the best way to
proceed is to rebuild the entire PTree/ subdir:
$ rm -rf PTree
$ sks pbuild -cache 20 -ptree_cache 70
I hope that nobody else has hit this bug; but, if so, I hope these
instructions help.
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks recon crashes with ptree corruption
On 8/10/2012 12:45 AM, Robert J. Hansen wrote: > There is no fix yet, nor do we know exactly what's causing this bug to > manifest. For now, if your PTree/ subdir gets borked the best way to > proceed is to rebuild the entire PTree/ subdir: For what it's worth, I am unable to keep sks recon going for more than an hour before getting hit by this. It's incredibly infuriating. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks recon crashes with ptree corruption
On 8/10/2012 11:31 AM, Kristian Fiskerstrand wrote: > Would it be possible for you to share some information* about the system > so that I can try to replicate it? (OS, SKS version, etc...). This is an Ubuntu 12.04 AMD64 system running the latest SKS available from the normal Ubuntu repository. The problem I was encountering seems to have resolved itself: it's been running for a few hours now without trouble. If the problem reoccurs I'll start anew with the debug level cranked as far as it will go, and will be in touch with a more detailed failure report. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] keyservers.org downtime
Hurricane Sandy is currently projected to make landfall almost on my front doorstep. For this reason, keyservers.org may go offline anytime in the near future. If it goes offline, expect it to be gone for a few days or more. Hopefully, though, all will be well and this will turn out to be a tempest in a teapot (if you'll pardon the pun). I'll be fine, I'm sure of that: the worst that will happen is I'll lose connectivity for a few days. This isn't the first natural disaster I've weathered out. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Keyservers.org downtime
keyservers.org will be down for approximately 8 hours on Tuesday for a server relocation. As with all server relocations it's possible that things will spring up that keep it offline for a longer period, but at present I think 8 hours is about right. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
On 9/13/2013 5:48 PM, Daniel Kahn Gillmor wrote: > RFC 4880 is explicit: > > Some implementations do not represent the interest of a single user > (for example, a key server). Such implementations always trim local > certifications from any key they handle. I don't see a MUST in there. The language is not explicit without it. Is it a case of they SHOULD always, they MAY always, or they MUST always? Without specification it's unclear. Although I am inclined to think the current behavior is a bug, I'm also inclined to think this is making a mountain out of a molehill. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
On 9/13/2013 6:09 PM, Daniel Kahn Gillmor wrote: > The intent is pretty clear, despite it not rising to the level of an RFC > 2119 MUST. Did anyone on this list expect the keyserver network to > propagate non-exportable certifications? I did, and I think I'm speaking as a reasonable, rational human being with a good deal of software engineering experience. Point blank: people read specifications differently. What you (and I, really) consider to be a defect, other people will read as being completely in accordance with the RFC. If you see a phrase that can be interpreted in multiple ways, it's a guarantee that somewhere someone is interpreting it in a way that you don't like. A wise engineer is someone who expects these alternate interpretations and is skeptical about his/her own certitude of interpretation. By all means, report the defect and make a case for your point of view. (Which you've done, and thank you.) And if/when the maintainers mark it as NOTABUG, then have the courtesy to thank them for their time and move on. Or else fork SKS and start your own codebase which fixes this bug which you apparently find intolerable. > I'm hoping for responses in similar good faith. You have received responses in good faith. They disagree with you. That doesn't mean they're wrong or not made in good faith. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
On 9/13/2013 7:51 PM, John Clizbe wrote: > I agree with Werner and Dave Shaw that you are wrong. If you are so > convinced you are correct, post, with _ALL_ the particulars not just > those that support your stance, to the IETF-OpenPGP list and get > their opinion. Although I agree with DKG that this is a bug, this is one of those cases where the fixes are all far worse than the bug itself. We need some turn of phrase to describe "although arguably not conforming to specification, this 'bug' is the least harmful option and involves the least breakage." WONTFIX doesn't seem to cover it, because that implies even if an option came along that involved even less harm and breakage the change wouldn't be made. NOTABUG doesn't seem quite right, because it's arguably not conforming to spec. And, of course, ENGINEERING_IS_ALL_ABOUT_COMPROMISES_IN_DESIGN is too long to fit into a drop-down combobox. Sigh. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
On 9/13/2013 8:22 PM, Christoph Anton Mitterer wrote: > And I guess the intention of the RFC is rather clear (with or without > MUSTs)... implementations should not export such signatures... and SKS > counts IMO as an "implementation". In what bizarro universe is SKS an implementation of RFC4880? It's an implementation of Minsky's efficient synchronization protocol, sure. But not of RFC4880. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS should not accept or replay non-exportable certifications
On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote: > Let me also be clearer about why i find this bug serious... I am still not seeing why this bug is serious. It still seems to be a case of mountains and molehills. > I have told numerous people that the keyserver network will not > propagate local signatures. This is true. However, as Ray Lee once said, "every truth has a context." Here the context is, "but if you try to prove how clever you are by creating corner-case certificates, you may wind up hoist in your own petard." > If the keyserver network actively forwards these certifications, > then users of the keyserver network and local certifications stand a > greater risk of global data leakage that they do not want. Please show me real users who are having troubles dealing with this bug. Not just you, because we've already established you're in love with weird corner cases. If this is affecting real users then I would be all in favor of further discussion on this subject. Without them, though, I'm inclined to say "enough already!" At some point you have to apply the instant-reply rule: if after watching the instant reply three times you have no idea what the correct decision is, then there is no wrong decision. Move forward and respect the decision of the person making the call. In this case, whatever decision the SKS maintainers make, I will cheerfully accept. > But i still believe this to be a reasonable expectation IMO, the fact RFC4880 implicitly allows a non-exportable self-signature should be considered a bug. IYO, this isn't a bug but a feature, and SKS's willingness to propagate these self-sigs is the bug. Both sides have arguments in their favor. Ultimately, it's up to the maintainers and the keyserver community to decide which will be the canonical behavior. Although I believe SKS's behavior as it currently stands is technically in error, I do not believe the alternatives you are presenting amount to a good fix. I encourage the maintainers and the community to not worry about this until/unless we see real users being impacted by it. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
> Agree. Ppl get personal swearing against me but dont had the kindness > to read the post and try to understand it. I have read all the posts in this thread and done my best to understand them. Some things I can't decipher, like > Hust bame it. ... which is, IMO, a case study in why standard English (of either the US or UK varieties) should be used on this list when possible. This is not a personal attack, Simon: it's simply telling you that your preferred method of writing is unclear and difficult to understand. Further: I would remind to all parties that courtesy and respect are important to the functioning of the keyserver community. Comments such as > If you give a fuck for poolmember's feedback then say it. Would save > time to write ignored arguments again and again. or > And tobias if u put ur emotions above your prpfessionality its ok > for me. Hust bame it. Wonder y emotional insulters may have admin > privs at a public paid university. are ultimately damaging to the community, and will likely result in the breaking of peering agreements. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
> Du hast scheinbar überlesen dass die Nachricht via Handy getippert wurde I would suggest doing what I do when I send messages in languages other than English; turn off autocorrect. As it happens, I have a copy of Brecht's _Leben des Galilei_ on my endtable right now. Not all Americans are dependent on Google Translate: some of us were exchange students and have not forgotten the language. :) A translation for the list -- human-generated, which means it's not literal but will hopefully maintain the spirit of his post: "You've overlooked that the message was typed on a cell and the autocorrect isn't designed for English. 'This message was sent from my Android phone via K-9 Mail.' And because you're just like the first poster and aren't engaging with the real issues, you're dead to me." Okay. Glad we got that straight, Simon. That said, this list has always used English as a common language of communication. Please use it in the future. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
> "You've seemingly overlooked that the message was typed on a cell and > the autocorrect isn't designed for English. 'This message was sent from > my Android phone via K-9 Mail.' And because you instantly become > personal in your first post and aren't engaging with the real issues, > you're dead as a conversational partner to me." Ah, thank you for the correction! :) With respect to the German language -- I spent a good bit of my 18th and 19th years in Saxony, and it literally changed my life. I found Germany to be a warm and welcoming place, and the vast majority of your countrymen were kind to me. I haven't been back since, although I'd like to. And what the hell. This list has had enough drama and bad feelings as of late, so I'll share a funny story from Hildesheim. --- I was on a bus with my host sister, who had a major English test the next day. She asked if we could speak English so that she could get some practice in before the Prüfung, so there we were chatting away. Sitting across from us was a mother with her young daughter, and the girl's eyes were wide as saucers as she watched me. She tugged on her mother's sleeve and whispered to her, "Mutti, Mutti! Ein Ausländer! Hier! Er ist Ausländer!" For non-German speakers, that's a pretty rude thing to say. "Mom, Mom! A foreigner! Here! He's a foreigner!" My host sister and I gave her a quizzical "we're right here and we can hear you" look, her mother made fulsome apologies, and tried to hush her daughter. The daughter just repeated it, louder, so everyone on the bus could hear. The mother looked as if she was about to die of embarrassment. Finally I spoke to the little girl directly. "Ich bin nicht 'ein Ausländer,'" I said, scare-quoting the phrase with my fingers. "Ich bin Amerikaner, ein Exchangestudent, und ein Freund zu meiner Freundin." My host sister elbowed me suddenly and I knew I'd committed some gaffe, but I went on anyway. "Ich bin Robert. Was ist deine Name? Wer ist deine Mutti?" The little girl looked as if I'd just slapped her. She turned away, stuck her nose high in the air, and said in an imperious voice -- "/That's/ all right. /I/ speak /English/." She looked like a little queen, really, and her accent was straight-up Alistair Cooke. The entire bus broke out laughing. After the laughter subsided I asked my host sister what was wrong. "Nothing," she said irritatedly. "You just kind of implied we're dating. I'm your Freundin?" I blinked. "What? It's the feminine of Freund..." "Yes, and it's used for girlfriends." "So what's used for friends who happen to be women?" "Freundin, of course." I shook my head. "But it's the /same word!/" She shrugged. "It's more about how you say it, I guess." I stared at her a moment. "Your language makes absolutely no sense, you know that?" She gave me a glower and a smile. "This, from the English-speaker." The bus had a second round of laughter over that. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Seeking peers for pgp.archreactor.org
On 6/12/2014 2:41 PM, Travis Megee wrote: ... forgive a silly question, but I have to ask: is that your real name, or an homage to Gregory MacDonald? :) ( http://en.wikipedia.org/wiki/Travis_McGee for those who have never read a MacDonald novel. Brilliant writing, just brilliant.) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Rationalization (Was: Questions regarding blocking ...)
On 8/3/2014 3:06 AM, Kiss Gabor (Bitman) wrote: > I'm thinking on structure of graph of key servers for a long time. > IMHO it is too scale free and not designed knowingly enough. If you haven't read this paper, start with it. * Watts, Duncan J.; Strogatz, Steven H. (June 1998). "Collective dynamics of 'small-world' networks". Nature 393 (6684). Available online at: http://labs.yahoo.com/files/w_s_NATURE_0.pdf It's three pages and is plenty worth reading. If you haven't already learned about small-world networks, it'll completely change the way you view things like the keyserver network. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
> This is a DOS because Mallory could effectively increase Alice's > public key to a size that it would be untenable for Bob to > download it from the pool. There are so many other, better ways to DoS the entire keyserver network that I have real trouble taking this one seriously. I think Kristian has the right of it here. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Proposal: Start verifying self-signatures
> Uploading user attribute packets with bogus self-signatures is > probably the easiest way to DoS the entire keyserver network. No. No, it's not. The easiest way is to add a single child porn image to a UID and upload it to the keyserver, and watch as worldwide every keyserver operator either takes down their server, keeps it up but cooperates strongly with authorities, or gets arrested. The *next*-easiest way is to start filing EU data privacy directives. For the price of a postage stamp you can take EU keyservers offline. This has already been done successfully (see Peter Palfreder as an example). If I were in the EU, I would be far more concerned with this than with maliciously large user attributes. Why would I use your mechanism when I can just write a letter and take down any keyserver in the EU? And if I'm enough of a sociopath as to want to take down the entire keyserver network, why would I be dissuaded by the prospect of needing to acquire just one child porn image to make my attack successful? Call this the Ivory Fallacy. When academics and theoreticians think like rogues, we tend to imagine academic and theoretical rogues. But rogues are generally quite pragmatic people, and in many ways more clever than we are. "Upload a 1TiB image? Come on, man. You can do better than that." > Are we just going to wait around until someone starts doing this? We > can solve these vulnerabilities now. When people start talking about the urgency of immediate action, my skepticism alarm triggers. In my experience, frying pans without fires are few and far between. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
