> Can someone point me to specific exploits that this key rotation schedule would have stopped?
It's not only key mismanagement that is being mitigated. You also have to prove more frequently that you have control of the domain or IP in the certificate.
In essence it brings a working method of revocation to WebPKI.
> but not low enough to prevent significant numbers of people from being compromised if there is a compromised key.
> You also have to prove more frequently that you have control of the domain or IP in the certificate.
That doesn't particularly matter; if someone takes over the domain but doesn't have a leaked key, they can't sign requests for the domain with my cert. It takes a leaked key for this to turn into a vulnerability.
On the other hand, anyone that owns the domain can get a perfectly valid cert any time, no need to exploit anything. And given that nobody actually looks at the details of the cert owner in practice, that means that if you lose the domain, the new owner is, treated as legit. No compromises needed.
The only way to prevent that is to pin the cert, which this short rotation schedule makes harder, or pin the public key and be very careful to not regenerate your keys when you submit a new CSR.
In short: Don't lose your domain.
> Compared to a year?
Typically these kinds of things have an exponential dropoff, so most of the exploited folks would be soon after the compromise. I don't think that shortening to this long a period, rather than (say) 24h would make a material difference.
But, again, I'm also not sure how many people were compromised via anything that this kind of rotation would prevent. It seems like most exploits depend on someone either losing control over the domain (again, don't do that; the current issuance model doesn't handle that), or just being phished via a valid cert on an unrelated domain.
Do you have concrete examples of anyone being exploited via key mismanagement (or not proving often enough that they have control over a domain)?
> That doesn't particularly matter; if someone takes over the domain but doesn't have a leaked key, they can't sign requests for the domain with my cert. It takes a leaked key for this to turn into a vulnerability.
It does, if someone gets temporary access, issues a certificate and then keeps using it to impersonate something. Now the malicious actor has to do it much more often, significantly increasing chances of detection.
I just downloaded one of DigiCert's CRLs and it was half a megabyte. There are probably thousands of revoked certificates in there. If you're not checking CRLs, and a lot of non-browser clients (think programming languages, software libraries, command-line tools, etc.) aren't, then you would trust one of those certificates if it was presented to you. With certificate lifetimes of 47 days instead of a year, 87% of those revoked certificates become unusable regardless of CRL checking.
Why is leaving almost 15% of bad certificates in play ok? If it was shortened to 48 hours, then it would make 99.5% of them unusable, and I suspect the real world impact would still be approximately zero.
It does not have to be perfect to be better. It's not great that 13% of revoked certificates would still be there (and get trusted by CRL-ignoring clients) but significantly smaller CRL files may get us closer to more widespread CRL checking. The shorter lifetime also reduces the window of time that a revoked certificate can be exploited by that same 87%. While I'd wager most certificates that get revoked are revoked for minor administrative mistakes and so are unlikely to be used in attacks, some revocations are still exploitable, and it's nearly impossible to measure the actual occurrence of such things at Internet scale without concerted effort.
This reminds me a bit of trying to get TLS 1.2 support in browsers before the revelation that the older versions (especially SSL3) were in fact being exploited all the time directly and via downgrading. Since practically nobody complained (out of ignorance) and, at the time, browsers didn't collect metrics and phone home with them (it was a simpler time), there was no evidence of a problem. Until there was massive evidence of a problem because some people bothered to look into and report it. Journalism-driven development shouldn't be the primary way to handle computer security.
> So at a 47 day cadence, it's true we'll have to regularly maintain it: We'll need to hire another staff member to constantly do nothing but. (Most of the software we use does not support automated rotation yet. I assume some will due to this change, but certainly not 100%.)
This is fundamentally a skill issue. If a human can replace the certificate, so can a machine. Write a script.
It is, but since we rely on DNS anyway, no matter what, and your DNS provider can get a certificate from Let's Encrypt for your site, without asking you, there's merit to combining them. It doesn't add any security to have PKI separate from DNS.
However, we could use some form of Certificate Transparency that would somehow work with DANE.
Also it still protects you from everyone who isn't your DNS provider, so it's valuable if you only need a medium level of security.
> It is, but since we rely on DNS anyway, no matter what, and your DNS provider can get a certificate from Let's Encrypt for your site, without asking you, there's merit to combining them.
They can, but they'll also get caught thanks to CT. No such audit infrastructure exists for DANE/DNSSEC.
> It doesn't add any security to have PKI separate from DNS.
One can also get a certificate for an IP addresses.
There is no need for a certificate from let’s encrypt. DANE lets you put your own self signed certificate into DNS and it should be trusted because DNS is authoritative, although DNSSEC should be required to make it secure.
And yet no browser trusts it, and a single-digit percentage of popular zones (from the Tranco list) have signatures; this despite decades of deployment effort. Meanwhile, over 60% of all sites on the Internet have ISRG certificates.
> I would be happy for them to remove is the portability between providers requirement: it was essentially dead on arrival, is not implemented, and could be done away with.
Well, they actually shouldn't. There are non-EU email providers that show exactly what would happen - customers wouldn't be able to transfer out their email from that service provider. Unlucky if they won't notice that limitation in time.
> The other EU-level regulation that needs to be either removed or completely rethought (since it will clearly not be enforced in a way that makes sense) is the cookie regulation. It was well-intentioned, badly implemented, and the GDPR addresses more of the core problems, it is time to do away with it.
Or simply start handing out fines for malicious compliance.
That's a bit negative. There are plenty of people that want a full OSS alternative to Gmail, Outlook, Yahoo and others. That includes calendar and contacts.
I run grep on Thunderbird's storage directory and it's significantly faster than anything Thunderbird itself attempts. (It also allows finding exact matches, fuzzy search without language "awareness" is disgusting to use.)
Even worse: the Swedish translation is lacking, so I use English. But my emails are often in Swedish. Making åäö and aao equal is never what I have ever wanted.
Not as bad as gnome which - in addition - has not let me reliably set things like date formats or first day of the week since several years despite using Swedish as my language.
I ask about mbox (one file system file per Thunderbird folder - e.g., one file named Inbox containing all its messages) or maildir (one folder per TB folder, containing one file per message) because it affects search using outside tools that don't understand that folder structure.
I'm wondering how efficient they are: When you search, does grep return an Inbox mbox file at a certain line number, or a maildir file?
It seems to be mbox, one file per Thunderbird folder.
Thunderbird itself seems to build some kind of an index next to mbox files. But finding the relevant email in TB's files makes it much easier to locate and open in TB itself (if it's needed). But I'd heavily prefer it to not be this way.
Proton says they care about security and privacy but at the same time makes it impossible to use your own keys or properly export the original emails from your inbox. I really can't take this suggestion seriously.
Last I checked that tool reordered all the headers (which destroys a lot of forensic value amongst other issues) and neither should such a tool be the only way to get (supposedly) good exports.
Both the IMAP bridge and web interface should provide original unmodified emails upon request.
That's not a good argument. The easiest way to undermine security of everyone is to allow portability of keys features. Look for example at where Signal fails and for no benefit to a normal user.
Current email encryption schemes provide no forward security, it's nothing like Signal. Key management has to work totally different.
You're also wrong in the aspect that it would undermine something, you can absolutely export keys from Protonmail, you just can't use your own keys properly. You can't remove all the keys they have generated, you can't use your own client with your own keys, the bridge literally mucks it up. The defaults can be what they are, it's not mutually exclusive in any way.
In the end this restriction undermines the security and privacy for everyone that want to use secure hardware storage. Which is absolutely insane for a service that boasts about these things.
I didn't critique their security model, I said you wanting greater convenience to exfiltrate keys and documents, even if its to a system that is more secure for you, is not arguing for better security and privacy in their product.
Your comment makes no sense. You can already export all the keys Protonmail generates (which I don't want to use and neither should I be forced to use). Not allowing the user to use their own provides absolutely no resistance to any kind of exfiltration.
>> Proton says they care about security and privacy but at the same time makes it impossible to use your own keys or properly export the original emails from your inbox. I really can't take this suggestion seriously.
They shamefully don't care about security and privacy because you can't get anti privacy capabilities working to your satisfaction.
You apparently could have lead with a lot of valid complaints but your 'shame' isn't really consistent with what you actually want.
It's not only key mismanagement that is being mitigated. You also have to prove more frequently that you have control of the domain or IP in the certificate.
In essence it brings a working method of revocation to WebPKI.
> but not low enough to prevent significant numbers of people from being compromised if there is a compromised key.
Compared to a year?
reply