jb613
1) Patents are not an American invention. England had them before, and the Romans before that.
2) I'll assume you implied U.S. patents. The Founders regarded patents so highly that they wrote them into the U.S. Constitution. It was written generically and not limited or fixed to only "mechanical or chemical" but rather "to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries".
> Thing is though that 20 years is a very long time when we are talking software. By the time the RSA patent ran out, the algorithm described was largely obsolete.
RSA patent expired nearly 20 years ago yet RSA is still used today. For example, the public key used to secure https://news.ycombinator.com is RSA.
> Not that patents have not been a problem even before computers. Serious refinements of the steam engine for example didn't happen until after the initial patent ran out. > > Similarly Smith and Weston sat on their refinements for the Colt revolver until the patent ran out.
The myth is that patents block innovation. The reality is that blocking someone from doing something incentives them to find another way to do it. Afterall, if all you want to do is copy then how is that "blocking innovation"?
Sure - it won't be easy and will come with other pitfalls, but in some circumstances these may be easier hurdle than waiting months/years for some government to approve your product sale.
Ditto. I know exactly what you're saying - tree's take long time to grow, the world is complex and subtly nuanced, once we lose that it's gone, etc. FYI I get all that - or for the purpose of this conversation pretend that I get it and try to look past that and at what I'm saying.
We can either fight change or adapt. Cavemen once complained about demand of caves outstripping supply too. The cost of fighting change is likely far greater than the cost of adapting.
Secondly, if you're going to worry about the Amazon (not saying we shouldn't worry about it) then why aren't you worried about the lost biodiversity once under Silicon Valley? Or NYC? Or Paris? Or Johannesburg? Or Beijing? It just seems we're getting involved in other people's business when we have a lot to cleanup ourselves.
The world changes and humans need to along with it. I'm sure cavemen once sat around the fire worrying about how all the good caves were being used up.
I suspect, access of "14,000 highly confidential and proprietary files shortly before his resignation" will play a major role in swaying the deciders. Experience tells us that not all of those 14k were critical, what if it had be 1 or 2 critical design docs? In a different or future case, we may see that happen. Corps have incentive to reduce competitors, but now may start recognizing the potential leverage they have - "Our network logs show Joe accessed our main design doc 1 week before he left for company doing similar work!".
I am less concerned about one piece of technology and more concerned about the future of employer relations in general. Employers will become increasingly suspicious of employees leaving and will take actions to either prevent this or to stifle the actual knowledge gained to be used elsewhere.
Nonetheless, given your context of "there is no encryption going on at all" I argue does not necessarily hold for a backdoor - or at least not at the outset and if done properly. If the govt backdoor is a key for which huge amount of care is taken to protect and take the extreme example of the govt encrypting the only copy of the key and firing it off in one direction into space - there is a backdoor but this is not necessarily equivalent to "no encryption at all".
Plug one hole in the dike and others will pop up. Just let the free market work and people choose where they want to live and work.
By today's standards, many people were "poor" back then - it's all relative. Maybe in 100+ years they'll look back and marvel at how "poor" Andreesen/Gates/etc... were too.
You can be poor today and still make it big. You don't need a college degree or the massive debt that entails, you can make up for that with a good idea + hard work + persistence + live as frugal as possible + a little luck. It's not exactly the same - some things are harder and some things are easier, but overall it's still doable.
"The maximum for unregistered clients is 5'000 CHF/EUR per day"
Contrast that with bitcoin - no corporations to deal with, no government rules®ulations and paperwork - all you really need is an Internet connection and and simple digital signatures.
So no - I don't think iTunes or pre-paid phone codes are easier to sell than bitcoin.
fw-daemon/rules.go references "/var/lib/sgfw/sgfw_rules" yet nowhere to be found.
In the mid-90's, CA certs were put into Netscape Navigator (IE joined later) in order to facilitate the new wild wacky concept that someone might buy something online. They called it "e-commerce".
Trust was centralized because it was far easier to add the then ~half-dozen CA's rather then somehow vetting every joe that wanted to self-sign their certs. PGP's web-of-trust existed but it was deemed less viable.
Besides, the whole SSL certs thing was a major business premise behind creating Netscape - profits. Without that there might not have been a dot-com and the huge amount of money that followed since then.
From a practical standpoint, I find it hard to imagine that the cost of added complexity for configuring application rules per user would outweigh the benefits of simply configuring them system wide. I remember the days of terminal clients logging into mainframes but all I see are single user desktops. Things like location on the network matter more in an application firewall than which user is accessing the desktop.
Brush up on CA cert issuance. You seem to be assuming that all CA's perform similar levels of due diligence before issuing certs. They don't, they differ widely. Some go much further than simply DNS validation.
> I'm suggesting making CAA mandatory.
For practical reasons, I am skeptical this will happen. Too many paying entities. In the spec/contract, the MUSTs will be lowered to SHOULDs.
> The certificate would not have been issued in my example.
IF the CA checked the CAA...
> CAA would have probably prevented the mis-issuance.
Exactly - "probably".
> CAA is only fully effective if all CAs implement it (or in other words: if it becomes mandatory).
1) it won't happen. some CA's may/already-have implemented it but how is the browser/user to know which have and which haven't? 2) unclear that it is even fully effective
> Again, you fail to demonstrate how this complexity does more harm than good. art. Introducing a new mechanism requires demonstration that the added complexity is worth the effort. And in this case, it is clear that unless everyone implements it, there is no added benefit. Added cost without benefit is a bad start
We're talking about CA's issuing certs - DNS queries for email, http are outside of CA cert issuance.
> This has nothing to do with browsers. It's a mechanism to improve the CA domain validation process.
The browsers need to decide when to trust a cert - and if/when CAA becomes involved in cert issuance, then I suggest this DOES have something to do with browsers. Furthermore, you're suggesting co-existence between CA's that check CAA and CA's that don't - which implies that either the browser or user has to make a determination of whether to trust.
But we're talking past each other. So using your example, think of it like this, how will you as a user know when you visit github that another WoSign hasn't happened? ...or rather - how would a LAYPERSON know they are secure? Github might detect it - but how do ordinary USERS?
> If they had used CAA, and github.com had a CAA record indicating WoSign is not permitted to issue certificates for that domain, it's quite possible that the certificate would not have been issued.
that (wrongly) assumes ALL CA's trusted by EVERY browser will perform CAA check before issuing a cert for github.
> CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases, but it's not (and never has been advertised as) a solution to the problem of a fully-compromised CA.
The problem is not so much "fully-compromised CA" as it is we're trusting a whole pile of CA's and not all them behave the same.
> you need access to the DNS in order to change (and bypass) CAA records, whereas you only need control over the web server in order to obtain a certificate that can be used to ransom a domain
Any attacker that can gain access to web site admin credentials can also get the DNS credentials.
> CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases
You're using defense-in-depth again. Replace "-in-depth" with "-added-complexity". Here's a directly relevant example - HPKP arose from deficiencies in static pinning - which arose from deficiencies of CA/SSL ecosystem - which arose from deficiencies of plaintext traffic. It's not adding security "-in-depth" when all you're doing is resolving deficiencies in existing deployed solutions. The "depth" is single-level, not multiple.
Not all - only a subset of certs issued
> If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA.
because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself.
> actually reduce the risk associated with that attack
and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access
Look no further than at some of the past transgressions browsers let CA's get away with.
1) We've seen time and again that complexity is the enemy of security. Generally, the more moving parts, the more likely for another flaw. This is less defense-in-depth than it is added complexity. The attackers have time on their side to figure out where the next hole is.
2) The OP suggests that HPKP failed because of practical reasons (domain admins are scared to death of getting it wrong and bricking their site) - things like CAA only add to the complexity.
2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.
so too could an attacker. If an attacker is able to set HPKP, then they could just as easily reconfigure CAA to a CA that issues them a cert for your domain.
I'm sure the CA's absolutely LOVE this - customers are signaling that they will stay with CA 'X'.
Given 'vendor lockin' or 'guaranteed recurring revenue', cert prices would drop thru the floor for 1st year only for renewals to increase.