Oh and there is an eight:

The claim to be rated by the better business bureau has been shown to be false. KlearGear makes several such claims that have been shown to be false for the purpose of gaining business. That meets the legal definition of fraud. In addition to creating the possibility of criminal sanctions, fraud voids a contract.

The Bill of rights is also enforceable on state governments.

KlearGear is attempting to enforce a purported contract term, guess what regulates contracts, oh yes, its the courts. And guess what the courts are part of, oh yes they are part of the government.

One of the sources of the Bill of Rights was precisely a concern about the government 'privatizing' censorship. That is how the British libel laws came into being, the purposes were to reduce the number of duels by providing an alternative dispute resolution process and to enable the rich and powerful to suppress their critics. It is no coincidence that in the 20th century the UK libel laws were used by a long series of corrupt bastards to suppress legitimate criticism, from John Major, the adulterer suing the New Statesman over an allegation of adultery, to Robert Maxwell the guy who stole almost a billion dollars worth of pension funds, to Jeffrey Archer and John Aitken who went to jail for perjury after making fraudulent libel claims.

The breach led to the contract being voided. KlearGear never delivered and Paypal refunded the money. So there was no exchange on either side.

The buyers might have had a claim for non-performance but the idea that the seller could enforce their one sided terms is ridiculous.

A clause that prevents reporting the failure to perform is certainly not going to be valid, not even in Texas.

The contract clause is unenforceable for multiple reasons. The first amendment has a bearing on one of them.

First there is no contract, The goods were never delivered, KlearGear failed to perform its obligation, there was never an exchange of a consideration. Therefore no contract.

Second, the original agreement was with the husband, the comments were made by the wife.

Third, the contract terms were added after the original agreement as is demonstrated by the Way Back Machine archives

Fourth, even if there had been a contract it would be a contract of adhesion. The seller defines the terms and the buyer has a weak negotiating position. In such cases civilized jurisdictions (i.e. not necessarily a corrupt jurisdiction) generally strike out clauses that are surprising or contrary to normal practice absent clear proof that the buyer was aware the term existed. A line of text in a fifty page contract in 6pt type is not normally enforceable.

Fifth, the term in question was unconscionable which means that it offends the basic principles of commerce and/or society. Constitutional precedent and in particular the first amendment is frequently used to establish that a clause is 'unconscionable'. Kleargear is not 'violating' the first amendment but the courts are not going to enforce a contract term whose purpose is to take away constitutionally protected rights.

Sixth, even if all the above were not so, the claim for $3,500 is a liquidated damages clause and thus invalid. As a matter of public policy, corporations are not allowed to set fines.

Seventh, the amount was clearly in dispute. Thus the reporting to Experian was in breach of the fair credit reporting act.

I am sure that there are weaker claims out there, but I can't think of one offhand.

Not an IETF list.

It is not even meant to be a proposal.

The point of the document is that I took all the points that had been made five or more times already and put them into one document so that we can move the discussion on to the next stage. Otherwise every time we get a new person joining the group we have to go through the same thing all over. And the third or fourth time round it becomes 'we already know that', 'NOO you are trying to censor me, NSA plant!'.

It isn't meant to become an IETF draft, they would make me take out all the fun parts. Like pointing out the abject incompetence of an organization that lets a 29 year old contractor with a pole dancer for a girl friend have access to that material six months after joining. Why do Alexander and Clapper still have jobs? And spying on US citizens and then trading the raw SIGINT with foreign powers that are certain to share it with my commercial competitors? What were these idiots thinking?

There is work going on in IETF and in fact we started before his Bruce-ship made his call to arms. I doubt the PRISM-PROOF branding will stick. But it is powerful mind share as this story proves. We have botched deployment of almost all the security protocols developed in IETF except for TLS and that succeeded before it went in. This is a chance to hit the reset button and fix the mindbogglingly stupid deployment gaps. Like having no standard way to discover recipient keys and having two different message formats (OpenPGP and S/MIME) forcing people to choose between two key endorsement schemes rather than allow them to pick the one suited to their needs.

Yes, I do think there was interference in the past efforts but I suspect it was subtler than most imagine and not coming from the NIST folk. Rather, I think the interference came from folk who would encourage both sides in technical disputes to dig in and refuse to compromise, folk who participate with no visible means of financial support and seem to have limitless time to write drafts but are not very technical.

Hmmm I replace my hard drives when I start to see RAID errors. I don't plan to run SSD raid as the on board fault tolerance should be ok.

Would be nice to have hard data on expected failures so that I know whether to plan for a three or a six year lifespan. I generally replace my main machine on a six year cycle as I have a lot of expensive software. Looking to upgrade this year when the higher performance intel chips launch.

1tb is quite a lot. Probably more than I need in solid state. The price is also quite a bit more than the $0.05/gig for Hard drives. But it's getting a lot narrower. And RAID 1 doubles that cost anyway...

Was about to make a witty reply till i realized i stopped readin slashdot round about the time i got married.

Umm, i am wearing one right now. Sleeping in it just would not occur to me. Plus you have to take it off to charge it. So as a privacy thing, well the only reason it would get you in trouble would be wearing it during sex so you could get the fuel points. Not a security issue that worries me at all. Now the implants.. They might be an issue.

That is not an approved disposal scheme in the US DoD. Explosives can and do leave pieces large enough to recover information from.

Neither CRLs nor OCSP are intended to mitigate a CA private key breach.

The only control in the system is to revoke the CA root and that can be effected on Windows by issuing a new CTL (as happened to revoke the Diginotar root) that drops the compromised root. The other browsers have similar mechanisms.

The war could well be over by the time DNSSEC is deployed. The Iranian group have developed new attacks and dramatically escalated the sophistication of their attacks. The time between attacks has been weeks, not years. There is simply no prospect of large scale DNSSEC deployment in the next 6 months. the Iranian 'elections' are in March. I can't even see any possibility of deployment ahead of the next presidential election.

Working on both of those.

Not without sounding really whinny.

At this point its water under the bridge, I have changed my mind on what the approach to security should be and so has the industry.

The browser that an Iranian dissident should be using is probably not the same as the one your granny uses to shop online for sex toys. There are security concerns in both cases but the risks and issues are totally incommensurate.

Let me explain. I have been working on Web security now for 19 years. I was present at the original meetings at which the SSL system was proposed, I convened several of the relevant meetings.

At no time was government wiretap a design consideration for SSL. NEVER. In fact to claim this was totally ridiculous since at the time we were fighting a running battle with the FBI and the NSA who were trying to stop us using strong cryptography at all. The original SSL design was limited to 40 bits and was very clearly crackable.

SSL is not designed to be wiretap proof, my proposal and the EIT proposal were stronger in that regard. But at the time the criteria was whether shopping online could be made as safe as shopping in a store. That was the design criteria by which SSL was judged and the design criteria it passed (after they eventually hired some competent crypto people). I was the person who stated the design criteria at the meeting.

Most check CRLS and OCSP.

The problem is what they do when they can't reach that data. All the browsers out there now simply fail silently and go to the site anyway.

For some reason this is seen as a problem with CAs and not the broken browsers. But from the browser providers perspective 99% of their customers are really interested in getting to sites reliably and without fuss and less than 1% are dissidents whose lives might be threatened.

This is not the fault of the guy who writes the code. They only own one small piece of the browser and do not get to make the 'commercial' decisions.

Expecting this to be any different with a DNSSEC scheme is to engage in mystical thinking of a naive variety.

Unfortunately the registrar system is rather less trustworthy than you imagine. We have not to date encountered an outright criminal CA. We do however know of several ICANN registrars that are run by criminal gangs.

The back end security model of the DNS system is not at all good. While in theory a domain can be 'locked' there is no document that explains how locking is achieved at the various registry back ends. A domain that is not locked or one that is fraudulently unlocked is easily compromised.

The part of the CA system that has been the target of recent attacks is the reseller networks and smaller CAs. These are exactly the same sort of company that runs a registrar. In fact many registrars are turning to CAs to run their DNSSEC infrastructure since the smaller ones do not have the technical ability to do it in house. In fact a typical registrar is a pure marketing organization with all technical functions outsourced.

There are today about 20 active CAs and another 100 or so affiliates with separate brands. In contrast there are over a thousand ICANN registrars.

Sure there are some advantages to incorporating DNSSEC into the security model. But to improve security it should be an additional check, not a replacement. Today DNSSEC is an untried infrastructure, it is grafted on to a legacy infrastructure that is very old and complex and security is an afterthought.

The current breach is not even an SSL validation failure. The attacker obtained the certificate by bypassing the SSL validation system entirely and applying for an S/MIME certificate that did not have an EKU (which it should). That makes it a technical exploit rather than a validation issue. DNSSEC is a new code base and a very complicated one. Anyone who tells you that it is not going to have similar technical issues is a snake oilsman.

DNSSEC has its place, even for key distribution. But it does not provide a basis for trust because mere holdership of a DNS domain does not mean you are trustworthy.

The big win for DNSSEC is to distribute security policy in a scalable fashion. See my CAA and ESRV Internet drafts.

Imagine that you are visiting slashdot, wouldn't it be better to use SSL than en-clair if the site supports it? Wouldn't it be better to have encryption with a duff cert than no encryption at all? [*]

DNSSEC allows a site to put a flag in its DNS to say 'always use SSL when visiting slashdot on http'. Now the server knows that if it is going to slashdot and it is not encrypted there is a man in the middle. Same for Twitter, Google etd.

DNSSEC can also be used to ensure that the only certs trusted for a domain are ones authorized by the domain holder. This provides an independent trust path to CA issued X.509. If used in combination, security can be improved.

[*] The catch is that showing the user the padlock icon for a duff cert is going to make them less secure. That is why I would like to see the browsers remove the padlock icon completely for DV certs. the only reason the padlock is required is to allow the user to check that SSL is in use. Since the user can't and won't do that reliably it is a poor control anyway. But it is in any case a control that should be enforced by the browser not the user and DNSSEC security policy allows that to happen.

On key distribution, well sure, for typical Web services and for promiscuous security, DNSSEC validated keys are just fine. It is not going to be a money saver. It does not justify a padlock icon (neither does a DV cert). But it is perfectly adequate for most applications.

Unfortunately it is likely that making use of DNSSEC for key distribution is going to be delayed for at least a year due to IETF politics. I blame the people behind the DANE proposal. They have been less than forthcoming about their real agenda from the start and have shown absolutely no willingness to accept any input from other parts of the IETF. The IETF is a consensus based organization but the test is IETF consensus, not working group consensus. If a clique wants to change the rules for handling PKIX certs they have to get an IETF consensus that this should be done.

DANE could have easily been designed in a way that allowed security policy and key distribution to be completely separate. Unfortunately the ruling clique insists these be joined. The result is a spec that is in my opinion undeployable because the transition strategy for a scheme providing positive trust (key distribution) is by necessity very different to that required for a scheme that provides negative trust (key revocation, security policy, etc.).