jaas

I didn't say that.

This is a naive and dangerous perspective. You're basically saying that memory safe languages don't solve all problems so it's fine to use unsafe languages.

Don't write code in unsafe languages unless you have to (almost never for new code). Period. You will have some problems either way, but you will have fewer problems in a memory safe language.

Pen testing is not even remotely a good mitigation to depend on against the dangers of a language like C. Its fine to do for defense in depth and to find problems not related to memory safety, but it's no substitute for making a more sensible language choice.

Licensing. Cisco has an all you can eat distribution license for the codec, so Firefox downloads from Cisco to piggyback on the Cisco license. If Firefox bundled it Mozilla would need a distribution license, and that's expensive.

You can read more here:

https://community.letsencrypt.org/t/2019-11-17-autoincrement...

Once a post-mortem is done there will be more information.

Status.io is where we post status information, not long-form explanations. The responses aren't canned the way I think you mean it, they're just meant to tell you status information quickly and clearly - is it up, is it down, what services are affected, how long until they're back up...

Once we have a fairly complete picture of what happened to communicate, we communicate that on our community site.

In case it's helpful for you to know, you can set up Bitlocker without a TPM. Google for instructions. It works well.

Yes. There are many cheap food options in NYC and if they need to charge a bit more to pay a fair wage then so be it. Providing even cheaper prepared food off the backs of staff not getting paid a living wage is not ok.

Seems like you're making quite the leap in assuming they can't buy effective replacement parts.

"probably had bad memories"

Speaking as someone who was at Mozilla at that time, you can change "probably had" to "definitely has". In hindsight I'd go ahead and call it a disaster. The X weeks release cadence solves so many problems.

I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert.

Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues.

We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like we recommend that shouldn't be burdensome, no reason to do it less often than that.

You can search the list here:

https://www.treasury.gov/resource-center/sanctions/sdn-list/...

Some entries have specific domains associated with them, but we are obligated to not serve any domain directly associated with (i.e. controlled by) an SDN entity, not just those listed.

If we become aware that we may be serving an entity on the SDN list (often via someone emailing us) we have to conduct an investigation which may result in termination of service.

Just so people don't get an oversimplified view of what it takes to start a CA from this comment, you will have much bigger challenges than access to application software. Your first issue will be securing millions of dollars per year for the staff that it takes to run the CA responsibly. Your next issue will be getting trusted by browsers.

Also, the open source Let's Encrypt CA software is tailored for how we do things. It's not an "off the shelf" component that you can easily run in another context and end up with a proper compliant CA.

Yes we do. On what basis did you make that statement?

We comply with U.S. sanctions by not issuing to entities on the SDN list, but that doesn't prevent us from serving the vast majority of people in those countries.

If you want to read more about this kind of thing, I can highly recommend this book:

The Death and Life of the Great Lakes by Dan Egan

It's incredibly well researched and written, and gave me a much better understanding of what's going with the ecosystems.

You stated that it wasn't a problem before they were free:

"I don't think money was ever the big deal in the real world that IETF people thought it was, but it sure drove a lot of dumb mailing list posts"

I am pointing out that I disagree, it was a very big deal and it's why I created Let's Encrypt.

I have a relative who has been repeatedly arrested for drunk driving. He had already severely injured someone and will kill someone sooner or later. The courts do nothing, he walks free with his driver's license every time. Even walked after assaulting an officer during one of the arrests. They will not put him in prison or take his license away.

This is in a midwestern U.S. state.

The laws may or may not be strong in theory, but even if they are strong they are not applied consistently. The courts are failing to protect the public from people who present a clear danger to the public.

This person, for example, is white. I am 100% sure that if he was not white he would be dealt with more harshly (and more appropriately, in this case).

Money is a big deal for ease-of-use and access. Tracking down a credit card and the necessary approvals to use it, even if the amount of money is no big deal, is a lot of friction for many people. Could be corporate red tape, could be that you don't have a credit card. Could be because you're in a country where financial sanctions prevent you from transacting with a foreign CA.

All of this friction would lead to many sites not using HTTPS because it's just too much of a hassle. And it's the visitors to those sites that suffer most.

"Unix was never a good design"

Nothing's perfect. Unix was a great design that served its purpose well for a long time, and evolved a bit along the way. Saying it was "never good" is trivializing and, in my opinion, arrogant.

Let's Encrypt | Site Reliability Engineer | Remote, U.S. and Canada

You will be a member of a six-person Site Reliability Engineering (SRE) team responsible for maintaining and evolving the operational infrastructure for the Let’s Encrypt certificate authority. You'll work closely with our application software developers and management to plan and implement the future of the certificate authority, its software applications, and its policies and procedures.

We're particularly interested in candidates with strong software engineering backgrounds and/or those with experience working on well-run SRE teams. We're looking to take our infrastructure automation to the next level.

https://www.abetterinternet.org/careers/le-sre-sw/

Head of Let's Encrypt here.

So far as we can tell, there is no viable plan for mass adoption of S/MIME. It will remain a niche system whether or not we participate. There is no opportunity for impact that would justify the effort and expense on our part, no vision for the future of S/MIME that we're excited about.

There was a viable plan for mass adoption of HTTPS in a reasonable time frame, that's why we chose to execute.

A fundamental difference between those two ecosystems is that the burden of HTTPS is almost entirely on server administrators, end users don't have to do anything. The HTTPS user-agent ecosystem has been solidly in place for a while. In the S/MIME case individuals need to be more participatory, and it's hard to get end-users to do anything, let alone correctly.

And ISRG is the non-profit legal entity behind Let's Encrypt:

https://www.abetterinternet.org/

Let's Encrypt | Site Reliability Engineer | Remote, U.S. and Canada

You will be a member of a six-person Site Reliability Engineering (SRE) team responsible for maintaining and evolving the operational infrastructure for the Let’s Encrypt certificate authority. You will work closely with our application software developers and management to plan and implement the future of the certificate authority, its software applications, and its policies and procedures.

We're particularly interested in candidates with strong software engineering backgrounds and/or those with experience working on well-run SRE teams. We're looking to take our infrastructure automation to the next level.

https://www.abetterinternet.org/careers/le-sre-sw/

EJBCA is popular but it's hardly a monoculture, especially among the larger CAs that can afford to do their own thing. Let's Encrypt doesn't use it, and I'm pretty sure a significant number of the other bigger CAs don't.

Forward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days.

It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do.

If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between whether that weakness is being exploited by regulated entities or baddies.

You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints. The issue isn't that they can't do that, it's that they don't want to do that, probably for cost or convenience reasons. Those aren't reasons to weaken TLS for everyone who actually wants secure comms.

Why do you want it to be a thing? Have you ever been exposed to an attack that would have been prevented by DNSSEC?

I feel like most people who want DNSSEC just have very theoretical warm feelings about the idea of it. When they actually implement it it does nothing but consume time and energy while adding liability.

DNSSEC doesn't help when the attacker controls your DNS control panel, just like DNSSEC doesn't help in almost every other practical attack scenario.

Let's kill it off and focus on efforts that solve real problems. It's worse than pointless, the added complexity is a huge liability.

Let's Encrypt is the name of a service, ISRG is the non-profit legal entity that provides the service.

ISRG was created in 2013 to be the legal entity behind the Let's Encrypt service. It's not being "spun out," we just never had a website for the legal entity itself until recently.

The third sentence means it is standard practice to validate from only a single network perspective today.

I have heard we would not be the first CA to do multi-perspective validation, but as far as I know we would be the only CA of significant size doing it. I do not know of other CAs doing it today, but we have not done an exhaustive survey.

Also, architecture and implementation details matter for this kind of feature. How many perspectives, what networks... We are lucky to be working with a great group from Princeton that has been helping us design our implementation.

What you are saying about how Minneapolis currently works is true, but the car-dominated commuter culture is an unfortunate situation that will not change unless Minneapolis changes the incentive structures that made it this way.

Minneapolis proper needs more livable core communities that aren't dominated by cars and commuters. I'm glad they are taking these steps because even though you are right that it makes the status quo more difficult in some ways, the status quo is not good and makes Minneapolis much less attractive long run.

AMD delivered completed physical GPU components to Intel, which Intel then stuck next to their CPUs. They didn't give Intel anything Intel couldn't get by walking over to MicroCenter.

(So far as I know anyway)

Lots of companies get older and lose ability to execute. AMD was very old already when Opteron happened.

The age of the company in a case like this is irrelevant. What matters is current management and staff and market context.