jasonh3

A mechanism to constrain root CAs to particular URLs/domains was proposed in firefox a while ago[0]. Perhaps an idea whose time has now come?

It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD).

0: https://bugzilla.mozilla.org/show_bug.cgi?id=501697

Somewhat related: if there were a shared password between the client and server, Password Authenticated Key Exchange techniques [0] could offer protection even when the server CA was compromised. PAKEs use zero-knowledge proof techniques to assert that each side already had password material (and derive a key from it) without revealing what the actual password was if the other side didn't have it to begin with.

In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing.

There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired [1].

0: https://en.wikipedia.org/wiki/Password-authenticated_key_agr... 1: https://tools.ietf.org/html/draft-barnes-tls-pake-04

This feels a lot like a more production-y version of Ryoan (OSDI '16).

https://www.usenix.org/conference/osdi16/technical-sessions/...

When I first saw this post, I got excited that someone had finally addressed the side channel from 17 years ago, which gathered inter-packet timing from ssh packets (and the fact that passwords are not echo'd) to a) detect when passwords were being typed, and b) use Hidden Markov Models to extract keystroke timing to try to extract the likely passwords.

There have been defenses proposed over the years, but none were accepted by OpenSSH AFAICT.

https://users.ece.cmu.edu/~vsekar/Teaching/Spring19/18731/re...

https://www.researchgate.net/publication/2907598_Timing_Anal...

Considering GPG is the primary protection for the Linux distros that run most of the services we're discussing* , at some point our trust falls down to it anyhow :)

* : Last I checked, the two most popular Linux distros I'm familiar with (CentOS and Ubuntu) only make their iso hashes available via http-only served files that are GPG signed

I hope you would be correct, that lots of people would notice a compromise, though I'm not convinced that this would be the case since the attacker could pretend to be the single committer.

> How many scenarios are there where a compromise wouldn’t include GPG keys or the attacker simply uploading their own key?

If the user's github credentials were compromised (lots of ways for that to happen which don't involve their system/keys being compromised, like using the same password across sites), then using GPG signatures would still allow cloners to check/detect problems since they wouldn't have the maliciously-updated github GPG key (or they might be one of the few folks still using the Web of Trust).

Furthermore, it's possible to have a local system compromise that doesn't give access to GPG keys, as keys could either be password protected or kept on a separate system that's primarily used for signatures (not extreme for a system that distributes law).

Also, signatures not only protect the latest commit, they also sign the previous commit hash(es), protecting previous commits and preventing a history rewrite. Without them, a history rewrite that left recent commits unchanged but modified some text could have the chance to go unnoticed.

EDIT: small clarity tweak

It's great that DC is making their latest laws available to everyone, however it's a little scary that the commits aren't signed, meaning that anyone who gained access to the github repo could forge them (and do more than fixing typos).

Hopefully DC (and others) will look at doing GPG signatures[0,1] so that they don't have to trust github's authentication as much. Github has a nice GUI that reflects signatures with the "Verified" tag, which you can see at[2].

0: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

1: https://help.github.com/articles/signing-commits/

2: https://github.com/QubesOS/qubes-doc/commits/master