4 ms·

I like how periodically we briefly get reminded that PGP's web of trust really is the superior system but we forget about it in a few minutes and move on.

tgsovlerkhgsel 4y ago
It really isn't, though. It's great in theory but breaks down in practice because the average user has neither the patience nor knowledge to manually deal with that stuff, nor should we expect them to.
- mastax 4y ago
  Instead we give the keys to the kingdom to everyone who shows up with a letter of recommendation.
moring 4y ago
It isn't superior because it isn't easy to use. It's only superior on the "secure" side. It would be nice if that concept was re-implemented in an actually superior product, starting with "will the average user be able to use it in their daily communication?"
brnt 4y ago
PGP's ceremony is no solution for anything. A Signal-like experience (TOFU, key verification if you wish, alerts when keys change) would be superior, if people were trained more (and recall how hard is was to tell people to look for the green padlock). Autocrypt is an attempt (with little uptake). Certificates not only about encryption, but also about authority: am I really connected to my bank? PGP only solves that if I already have verified keys, which is the hardest part left unsolved. Unfortunately, proprietary two factor apps seems to be the way this is increasingly solved. Even further removed from a superior system (but, apparently, practical).
- 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.
- bombolo 4y ago
  > PGP only solves that if I already have verified keys, which is the hardest part left unsolved. But you've opened your bank account in person. When you got the token to login to the bank website they might as well ask you to sign their certificate since you are there.
  - joshuaissac 4y ago
    > But you've opened your bank account in person. Many banks do not require this. Many do not even have physical branches to visit.
  - mort96 4y ago
    Last time I opened a bank account, I did it by creating an account on their website.
    - bombolo 4y ago
      USA I suppose? I guess that's why you have a huge problem of people opening debt under other people's name there, which is a thing that doesn't really happen here.
      - mort96 4y ago
        Norway. I don't believe we have that problem.
      - brnt 4y ago
        Most European countries run proper citizen registries that allow for secure verification of IDs and online opening of bank accounts. Many banks don't require visits anymore. All the same, two factor devices (you can mail them too) are phased out across the blad in favor of mobile apps. Which is nog great.
        bombolo 4y ago
        mobile authentication is actually in violation of a EU directive. My bank linked that very directive when they retired the physical token in favour of using the phone, saying the bad EU was forcing them to do this money saving step. I couldn't believe it was true, I read the actual text of the directive and it was in fact not true.
- upofadown 4y ago
  I would not want to trust my bank account to all of the following: * the people that run the Signal Servers (or whoever). * The people that send the verification SMS. * The phone company. ... even for a little while. Two factor only verifies you, not the bank.
  - lotsofpulp 4y ago
    Does TOTP 2FA solve not having to trust those other entities?
    - bombolo 4y ago
      Many force you to install their own app instead of using a generic one. Which is a problem. Also google's app doesn't easily let you export and backup the seeds. So you either remember to do that initially or breaking your phone == losing access to everything.
      - account42 4y ago
        > Many force you to install their own app instead of using a generic one. Which is a problem. I agree that having to use a proprietary app is not great, but TOTP is vulnerable to MITM attacks because the tokens are not restricted to a specific action but only to a time slice. For many use cases that is not a big problem, but for a bank account I'd want more security. Of course being able to do your banking in the same app or a slightly different one on the same device kind of defeats the purpose.
CJefferson 4y ago
How is it more secure? With certificate transparency, there has been almost no invalid certificates found, and anyone who produces one is immediately struck off. I can't really imagine how web of trust would let me (for example) securely connect to hellbunny.com, a website I have no direct connection to,.and isn't that famous.
- bombolo 4y ago
  Why are root CA authorities holding on to private keys and sending them around? https://www.techtarget.com/searchsecurity/news/252436120/23000-Symantec-certificates-revoked-following-leak-of-private-keys https://www.techtarget.com/searchsecurity/news/252436120/230... The "trusted" party sometimes fails spectacularly it seems. > hellbunny.com, a website I have no direct connection to,.and isn't that famous. And what do you know about that certificate? That some root CA signed it. Do they follow a proper process? I don't care about random websites. For those letsencrypt is fine. But for banking or paying taxes I want some more checks done. And they aren't provided.
  - tialaramex 4y ago
    > Why are root CA authorities holding on to private keys and sending them around? They aren't. In the story you link Trustico are a reseller. Once Trustico revealed that they had these keys which they shouldn't have, all the certificates were invalidated because they're worthless, the issuing CA - DigiCert - did exactly what we want them to do. If the corner store near me sells cans of Coke which they have poisoned, that's not a problem with Coca-Cola, it's problem with that local store. The local cops should get involved, and yes as happened here, the company whose product reputation they harmed should be angry about that and cut ties to them, no more Coke branded fridge if the store owners somehow stay in business (and indeed in my hypothetical if they avoid jail).
  - tialaramex 4y ago
    > And what do you know about that certificate? That some root CA signed it. Do they follow a proper process? The purpose of m.d.s.policy, the discussion group where the decision to distrust Trustcor was made, is to oversee these root CAs. As part of that, we require them to use at least one of the Ten Blessed Methods (there aren't actually currently ten of them) to decide whether a subscriber is entitled to certificates for particular DNS names. You can read in the CAB BRs https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ what the currently allowed Blessed Methods are in section 3.2.2.4 Validation of Domain Authorization or Control -- each method is numbered e.g. 3.2.2.4.19 is the most often used Let's Encrypt (ACME standard) web site authentication. You can also read in the CA's own documentation how they claim to implement one or more of the Blessed Methods, for example Let's Encrypt offer 3.2.2.4.19 and explain that, but they don't offer say 3.2.2.14 which is sending out emails with a magic random number in them to a domain contact's email address.
otikik 4y ago
Not really superior if no one uses because they can't figure it out.
- bombolo 4y ago
  Well the current system we basically sign everything as long as the domain on the certificate matches what's registered on the DNS. If the certificate says "Company AB", nobody checks if that's true.
  - tialaramex 4y ago
    If the certificate says "Company AB" the CA is required to check that's true, there's a set procedure to do so. If you ask Let's Encrypt for a certificate saying "Company AB" they won't give it to you, because they don't follow such procedures and so they know they can't issue such certificates. But, this is not very useful because: * Consumers generally have no idea who "Company AB" are. You wanted funny-cat-gifs.example not "VXK Enterprise LLC of New Jersey" who might happen to run funny-cat-gifs.example. Lots of famous brands are actually offered by companies with unrelated names, so then you're asking the CA to vouch for the brand name, which is an extra layer of indirection... * Jurisdiction is a thing. Maybe I trust Greasy Geoff's Cider And Pork, but alas I was thinking of the Kansas Greasy Geoff's, not the one from Missouri. * Machines can't do anything with this so it's only useful in the rare case a human spent time thinking about it, whereas the DNS name check is something the machine cares about for every single HTTP transaction, of which often several per second happen.
upofadown 4y ago
The OpenPGP standard trust stuff is certainly represents a more flexible system (wildcards match on a regular expression) and at this point is a simpler and more straightforward system. It ultimately solves more or less the same problem. TLS links a key fingerprint (ultimately the identity in any cryptographic trust system) to a host name. PGP links the key fingerprint to a name and email address (although the standard does not prevent you from linking, say, your phone number as well). So in either case we link the fingerprint to a more convenient alphanumeric string. That's it, that's all we are doing here. The whole trick is in what you think that alphanumeric string represents. I sometimes fantasize about a world where the head office of a bank has a giant QR code literally chiselled into the stone of the building representing the key fingerprint of their root identity. That way anyone that walks by can verify all the bank's identities down to the individual employee simply by snapping a pic with their phone. Part of the responsibility of someone working there would be to check the QR code every morning to ensure that no one had come in the night with a jack hammer and concrete...

tgsovlerkhgsel 4y ago

It really isn't, though. It's great in theory but breaks down in practice because the average user has neither the patience nor knowledge to manually deal with that stuff, nor should we expect them to.

mastax 4y ago
Instead we give the keys to the kingdom to everyone who shows up with a letter of recommendation.

moring 4y ago

It isn't superior because it isn't easy to use. It's only superior on the "secure" side. It would be nice if that concept was re-implemented in an actually superior product, starting with "will the average user be able to use it in their daily communication?"

brnt 4y ago

PGP's ceremony is no solution for anything. A Signal-like experience (TOFU, key verification if you wish, alerts when keys change) would be superior, if people were trained more (and recall how hard is was to tell people to look for the green padlock). Autocrypt is an attempt (with little uptake). Certificates not only about encryption, but also about authority: am I really connected to my bank? PGP only solves that if I already have verified keys, which is the hardest part left unsolved. Unfortunately, proprietary two factor apps seems to be the way this is increasingly solved. Even further removed from a superior system (but, apparently, practical).

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.
bombolo 4y ago
> PGP only solves that if I already have verified keys, which is the hardest part left unsolved. But you've opened your bank account in person. When you got the token to login to the bank website they might as well ask you to sign their certificate since you are there.
- joshuaissac 4y ago
  > But you've opened your bank account in person. Many banks do not require this. Many do not even have physical branches to visit.
- mort96 4y ago
  Last time I opened a bank account, I did it by creating an account on their website.
  - bombolo 4y ago
    USA I suppose? I guess that's why you have a huge problem of people opening debt under other people's name there, which is a thing that doesn't really happen here.
    - mort96 4y ago
      Norway. I don't believe we have that problem.
    - brnt 4y ago
      Most European countries run proper citizen registries that allow for secure verification of IDs and online opening of bank accounts. Many banks don't require visits anymore. All the same, two factor devices (you can mail them too) are phased out across the blad in favor of mobile apps. Which is nog great.
      - bombolo 4y ago
        mobile authentication is actually in violation of a EU directive. My bank linked that very directive when they retired the physical token in favour of using the phone, saying the bad EU was forcing them to do this money saving step. I couldn't believe it was true, I read the actual text of the directive and it was in fact not true.
upofadown 4y ago
I would not want to trust my bank account to all of the following: * the people that run the Signal Servers (or whoever). * The people that send the verification SMS. * The phone company. ... even for a little while. Two factor only verifies you, not the bank.
- lotsofpulp 4y ago
  Does TOTP 2FA solve not having to trust those other entities?
  - bombolo 4y ago
    Many force you to install their own app instead of using a generic one. Which is a problem. Also google's app doesn't easily let you export and backup the seeds. So you either remember to do that initially or breaking your phone == losing access to everything.
    - account42 4y ago
      > Many force you to install their own app instead of using a generic one. Which is a problem. I agree that having to use a proprietary app is not great, but TOTP is vulnerable to MITM attacks because the tokens are not restricted to a specific action but only to a time slice. For many use cases that is not a big problem, but for a bank account I'd want more security. Of course being able to do your banking in the same app or a slightly different one on the same device kind of defeats the purpose.

CJefferson 4y ago

How is it more secure? With certificate transparency, there has been almost no invalid certificates found, and anyone who produces one is immediately struck off. I can't really imagine how web of trust would let me (for example) securely connect to hellbunny.com, a website I have no direct connection to,.and isn't that famous.

bombolo 4y ago
Why are root CA authorities holding on to private keys and sending them around? https://www.techtarget.com/searchsecurity/news/252436120/23000-Symantec-certificates-revoked-following-leak-of-private-keys https://www.techtarget.com/searchsecurity/news/252436120/230... The "trusted" party sometimes fails spectacularly it seems. > hellbunny.com, a website I have no direct connection to,.and isn't that famous. And what do you know about that certificate? That some root CA signed it. Do they follow a proper process? I don't care about random websites. For those letsencrypt is fine. But for banking or paying taxes I want some more checks done. And they aren't provided.
- tialaramex 4y ago
  > Why are root CA authorities holding on to private keys and sending them around? They aren't. In the story you link Trustico are a reseller. Once Trustico revealed that they had these keys which they shouldn't have, all the certificates were invalidated because they're worthless, the issuing CA - DigiCert - did exactly what we want them to do. If the corner store near me sells cans of Coke which they have poisoned, that's not a problem with Coca-Cola, it's problem with that local store. The local cops should get involved, and yes as happened here, the company whose product reputation they harmed should be angry about that and cut ties to them, no more Coke branded fridge if the store owners somehow stay in business (and indeed in my hypothetical if they avoid jail).
- tialaramex 4y ago
  > And what do you know about that certificate? That some root CA signed it. Do they follow a proper process? The purpose of m.d.s.policy, the discussion group where the decision to distrust Trustcor was made, is to oversee these root CAs. As part of that, we require them to use at least one of the Ten Blessed Methods (there aren't actually currently ten of them) to decide whether a subscriber is entitled to certificates for particular DNS names. You can read in the CAB BRs https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ what the currently allowed Blessed Methods are in section 3.2.2.4 Validation of Domain Authorization or Control -- each method is numbered e.g. 3.2.2.4.19 is the most often used Let's Encrypt (ACME standard) web site authentication. You can also read in the CA's own documentation how they claim to implement one or more of the Blessed Methods, for example Let's Encrypt offer 3.2.2.4.19 and explain that, but they don't offer say 3.2.2.14 which is sending out emails with a magic random number in them to a domain contact's email address.

otikik 4y ago

Not really superior if no one uses because they can't figure it out.

bombolo 4y ago
Well the current system we basically sign everything as long as the domain on the certificate matches what's registered on the DNS. If the certificate says "Company AB", nobody checks if that's true.
- tialaramex 4y ago
  If the certificate says "Company AB" the CA is required to check that's true, there's a set procedure to do so. If you ask Let's Encrypt for a certificate saying "Company AB" they won't give it to you, because they don't follow such procedures and so they know they can't issue such certificates. But, this is not very useful because: * Consumers generally have no idea who "Company AB" are. You wanted funny-cat-gifs.example not "VXK Enterprise LLC of New Jersey" who might happen to run funny-cat-gifs.example. Lots of famous brands are actually offered by companies with unrelated names, so then you're asking the CA to vouch for the brand name, which is an extra layer of indirection... * Jurisdiction is a thing. Maybe I trust Greasy Geoff's Cider And Pork, but alas I was thinking of the Kansas Greasy Geoff's, not the one from Missouri. * Machines can't do anything with this so it's only useful in the rare case a human spent time thinking about it, whereas the DNS name check is something the machine cares about for every single HTTP transaction, of which often several per second happen.

upofadown 4y ago

The OpenPGP standard trust stuff is certainly represents a more flexible system (wildcards match on a regular expression) and at this point is a simpler and more straightforward system. It ultimately solves more or less the same problem. TLS links a key fingerprint (ultimately the identity in any cryptographic trust system) to a host name. PGP links the key fingerprint to a name and email address (although the standard does not prevent you from linking, say, your phone number as well). So in either case we link the fingerprint to a more convenient alphanumeric string. That's it, that's all we are doing here. The whole trick is in what you think that alphanumeric string represents. I sometimes fantasize about a world where the head office of a bank has a giant QR code literally chiselled into the stone of the building representing the key fingerprint of their root identity. That way anyone that walks by can verify all the bank's identities down to the individual employee simply by snapping a pic with their phone. Part of the responsibility of someone working there would be to check the QR code every morning to ensure that no one had come in the night with a jack hammer and concrete...