4 ms·

Most of the whole PGP system is inadequate for real use, but it points towards a model and interface which is: most people for most encryption simply want to kn

by XorNot 4y ago

Most of the whole PGP system is inadequate for real use, but it points towards a model and interface which is: most people for most encryption simply want to know the answer to "is this my bank as my government/insurance company etc. believes it is?" and that sort of key would essentially be distributed by consensus. But the standard we've got is, once you're "in" to the CA root store, technically you can issue certificates for anything in any context, and the way we interact with them is to simply trust them uniformly. What we need is a system which let's us easily contextualize the actual trust problem we're solving with a connection: i.e. "I'm contacting a bank in <country>, so I want to know that the government of that country thinks its a bank, (maybe through the reserve bank of that country which expresses trust as to that identity". Chains of trust which make sense for the relationship. As it is, if I visit say - pm.gov.au and check the certificate I get that it was issued by GlobalSign. Who are they? Well, they're in the Root CA store which is why they're involved because that was the only requirement. But what I want to actually know is "Am I talking to the Australian government and at what level?"

mschuster91 4y ago
The problem isn't made easier by there being two completely distinct questions to be answered: - connection security: are the crypto credentials being used for signing e-mails or encrypting web traffic belonging to the entity in question? This should have been solved by putting the fingerprints into DNS so that clients can validate it on their own instead of having to trust a CA. DNSSEC and certificate pinning would have been the answer, but both are incredibly complex to set up and littered with failure scenarios that may be very difficult to recover from, but in the end it got "solved" by LetsEncrypt/ACME where the CA acts as a proxy. For e-mail, it got solved better by DKIM, but that's only applicable to the scenario "an email server wishes to check if an email it received from example.com actually originates from example.com", but not for "an email client wishes to send an encrypted email to foo@example.com and needs the public key for this mailbox". - connection authenticity: is the server a client is talking to (e.g. bank.com) actually belonging to the legal entity the user expects it to be? That one is what CAs were originally designed to verify and where a much larger amount of trust is placed on the CAs doing their job correctly. One idea to do that was SSL EV certificates, but for whatever reason these fell out of favor - and right now, there is no replacement at all for this use case. Additionally, the situation is made even more complex by legal or compliance requirements, e.g. banks who have to record virtually everything their employees do. For that, they have to break HTTPS by providing their own root certificate.
- account42 4y ago
  Except the questions are not distinct as long as you want to protect against MITM attacks. Having a secure connection is meaningless if you have no way of telling that its secure up until whoever you intend to talk to. And if you do trust the connection to be free from active attackers then you don't need certificates at all, e.g. diffie helman key exchange would be enough to create a shared secret that in the presence of a passive adversary that can only observe.

by XorNot 4y ago

mschuster91 4y ago

The problem isn't made easier by there being two completely distinct questions to be answered: - connection security: are the crypto credentials being used for signing e-mails or encrypting web traffic belonging to the entity in question? This should have been solved by putting the fingerprints into DNS so that clients can validate it on their own instead of having to trust a CA. DNSSEC and certificate pinning would have been the answer, but both are incredibly complex to set up and littered with failure scenarios that may be very difficult to recover from, but in the end it got "solved" by LetsEncrypt/ACME where the CA acts as a proxy. For e-mail, it got solved better by DKIM, but that's only applicable to the scenario "an email server wishes to check if an email it received from example.com actually originates from example.com", but not for "an email client wishes to send an encrypted email to foo@example.com and needs the public key for this mailbox". - connection authenticity: is the server a client is talking to (e.g. bank.com) actually belonging to the legal entity the user expects it to be? That one is what CAs were originally designed to verify and where a much larger amount of trust is placed on the CAs doing their job correctly. One idea to do that was SSL EV certificates, but for whatever reason these fell out of favor - and right now, there is no replacement at all for this use case. Additionally, the situation is made even more complex by legal or compliance requirements, e.g. banks who have to record virtually everything their employees do. For that, they have to break HTTPS by providing their own root certificate.

account42 4y ago
Except the questions are not distinct as long as you want to protect against MITM attacks. Having a secure connection is meaningless if you have no way of telling that its secure up until whoever you intend to talk to. And if you do trust the connection to be free from active attackers then you don't need certificates at all, e.g. diffie helman key exchange would be enough to create a shared secret that in the presence of a passive adversary that can only observe.