Fedora considers removing NIS support
Fedora considers removing NIS support
Posted Oct 30, 2021 14:02 UTC (Sat) by jezuch (subscriber, #52988)In reply to: Fedora considers removing NIS support by smoogen
Parent article: Fedora considers removing NIS support
Posted Oct 30, 2021 16:35 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (27 responses)
Yes, key management and distribution is a hard problem, possibly the hardest problem in all of applied cryptography. But it is far from intractable, and it's also far from the only thing you have to get right.
* Quick, what's the difference between "full" trust and "ultimate" trust? Do you really think the average user is equipped to answer that question?
Posted Nov 1, 2021 13:45 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (18 responses)
Posted Nov 1, 2021 16:08 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (17 responses)
Users already know each others' phone numbers. Sure, SIM hijacking is a thing... but like I said, Signal "mostly works." Regardless, your claim that PGP provides a "web of trust" is grossly exaggerated since the average user has never heard of a "key-signing party" and would not know how to get linked into said web of trust, so it might as well not exist at all, for all intents and purposes.
Posted Nov 1, 2021 16:38 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (16 responses)
Well according to this logic, also clear text http mostly works.
How often does it actually happen that someone does a man in the middle?
Security is not designed with the idea that nobody will attack you. Because as we have seen, attacks do happen. To some more than others.
If people haven't had key signing parties, then they get out of PGP the same security they get out of Signal.
Posted Nov 1, 2021 18:14 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (15 responses)
But the exact same criticism applies to PGP - Are users actually setting sane passphrases? Are they properly sequestering their keying material? Or are they chucking an unlocked private key directly into Dropbox or something?
Posted Nov 1, 2021 21:04 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (14 responses)
For example someone registers a signal/whatsapp/telegram account using my phone number, gets the confirmation SMS from one of the many well known SMS attacks. At this point people on signal who have my phone number will think that is me.
And that's why signal gives you no authentication, while PGP does.
We are not talking about hitting people with a wrench… of course if someone steals my phone and guesses the PIN, they can do whatever they want on signal. But they can impersonate me without having to ever meet me in person.
> Or are they chucking an unlocked private key directly into Dropbox or something?
Come on… if your security model is that the PGP user is an idiot while the signal user is smart, you are modelling wrong.
Posted Nov 1, 2021 22:50 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
This is easily defused by simply talking to the other person, once, and telling them whether or not you use Signal with phone number X. From there, trust is permanently bootstrapped, at least for as long as you can keep the phone number. In the US and probably other jurisdictions, the phone number belongs to the consumer, so that you can keep it indefinitely even when you change phone companies.
Is that less efficient than a web of trust? Yeah, probably. But in practice, most end users talk to each other (in person or via something like Zoom) much more frequently than they attend key-signing parties, so this efficiency difference is completely overwhelmed by the cold, hard reality of end user behavior.
> Come on… if your security model is that the PGP user is an idiot while the signal user is smart, you are modelling wrong.
The model is that both the PGP user and the Signal user can make mistakes, to the extent that the system allows them to make mistakes. The only mistakes you can make under Signal are setting a bad PIN or believing the other person's identity without independently confirming that they are in fact using Signal. Those are real problems; I never claimed that Signal is perfect. OTOH, there are numerous mistakes you can make with PGP:
* Poor key storage.
Posted Nov 2, 2021 7:43 UTC (Tue)
by LtWorf (subscriber, #124958)
[Link] (10 responses)
> This is easily defused by simply talking to the other person, once,
Not once… the attack can happen at any moment and so for people who don't use signal, their newly created signal account must be ignored until the meeting in person can happen.
> Is that less efficient than a web of trust? Yeah, probably. But in practice, most end users talk to each other (in person or via something like Zoom) much more frequently than they attend key-signing parties
Depends if they live in the same area or not, and the web of trust has the concept of transitory trust, so you don't need to meet everyone you write emails to. With your schema you need to meet and have the authenticating conversation with every single person you interact with.
You don't NEED a key signing party… you can just sign the key of 1 single person when you meet in person. So basically just your protocol but better because of transitive trust.
But people who use signal do not wait until they can meet in person to write to each other, and until they meet and explicitly ask about signal, their communication is e2e encrypted with a potential complete stranger.
> so this efficiency difference is completely overwhelmed by the cold, hard reality of end user behavior.
So, for signal, this means completely unauthenticated, like I keep telling you…
But you keep re-inventing a bad version of PGP and and think that somehow your-pgp-over-signal will work better than actual PGP… if PGP didn't work your protocol will fail too.
> The only mistakes you can make under Signal are setting a bad PIN or believing the other person's identity without independently confirming that they are in fact using Signal.
The PIN is your red herring. As I said, SMS can be hijacked without the PIN…
> * Poor key storage.
Plugging your phone to an unknown charger can expose you to an attack where your keys are stolen.
> * Sending a cleartext reply-to-all.
??? PGP supports fully well encrypting the same message for multiple recipients.
> * Signing a key without seeing adequate evidence of its owner's identity.
As opposed to no verification whatsoever on signal?
> * And so on...
Ok you decided, for no logical reason, that signal is more secure than PGP. Because users of PGP have human flaws that somehow users of signal don't share…
Signal has a number of problems:
* centralised
Those open to a number of attacks by entities in power, that simply PGP doesn't share.
Posted Nov 3, 2021 0:45 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Please do not put words in my mouth. I explicitly described all of these bullets as mistakes which PGP enables the user to make, not as vulnerabilities in PGP itself. I also acknowledged that Signal users are capable of making mistakes as well, a sentence which you even quoted, and then proceeded to accuse me of neglecting to mention the second mistake (of two) which I mentioned ("believing the other person's identity without independently confirming that they are in fact using Signal").
You have an agenda. That's fine. But I don't, so I'm going to respectfully disengage at this time.
Posted Nov 6, 2021 16:27 UTC (Sat)
by nix (subscriber, #2304)
[Link] (8 responses)
Meeting in person? You don't need to meet in person: you just need to know what your interlocutor's voice sounds like and call them on the phone number you probably already have for them, or, if you don't, their claimed phone number on Signal (not a Signal call, an ordinary phone call). You then ask them whether they're using Signal, and (unless coerced, in which case all bets are off anyway) you then know whether or not to trust the Signal number.
These are trivial properties of trustworthiness which any human being who uses phones at all easily understands. My 76-year-old mother would understand them instantly. The requirements you have to satisfy to use PGP safely? I'm not sure *I* know them properly and I've been using PGP (reluctantly) for decades: I do know you have to get them right *every time* and if you mess up one message that's it.
This is much worse and much more fragile than Signal's one-off easily-understood check.
Posted Nov 7, 2021 7:30 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (7 responses)
This is open to all sort of vulnerabilities.
* replay attack (record voice and form sentences)
As you can see, it works fine in the case where we don't need security and presume nobody is attacking. Not so fine if we presume someone is actually attacking.
Posted Nov 7, 2021 17:34 UTC (Sun)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Nov 7, 2021 17:49 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (5 responses)
People communicate with a number of other people without necessarily being really close on a personal level.
Posted Nov 8, 2021 0:18 UTC (Mon)
by nix (subscriber, #2304)
[Link] (4 responses)
I mean, yes, this is still not ideal -- it discriminates against deaf people, for starters. But it's a hell of a lot better than the thoroughly untrustworthy web of trust, which neither covers enough people to have any chance of actually reaching anyone but a tiny fraction of techies, nor fails safe, nor is easy enough to use that you're going to be able to use it without at the very least worrying about accidentally committing disastrous security fubars, nor even has a sane model of trust -- trust among human beings is *not* transitive at all, just because I trust my mother does not in any sense mean that I trust any of her friends, and just because she distrusts, say, her brother doesn't mean that I distrust him. Partly this is just bad terminology, but that just means that you're asking people to decide about "trust" when the thing you're actually asking them about isn't particularly related to anything like trust at all, but a *new concept* that every single person who sends and receives secure encrypted messages using PGP has to keep in mind more or less at all times. No *wonder* it tanked.
Posted Nov 8, 2021 0:34 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
In a work-related setting that's perfectly feasible, yes.
Posted Nov 8, 2021 9:22 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Well you can exchange numbers on dating apps, for work, you can post ads with your phone to sell your old couch, and as I said the phone audio quality is not nearly the same as real world audio.
> neither covers enough people to have any chance of actually reaching anyone but a tiny fraction of techies
Well whatever app you use will only work if the other person has the same app.
> trust among human beings is *not* transitive at all, just because I trust my mother does not in any sense mean that I trust any of her friends, and just because she distrusts, say, her brother doesn't mean that I distrust him.
Luckily PGP lets you express how much a person's trust can be trusted!
How much you trust a key and how much you trust signatures done with that key are separate concepts.
> No *wonder* it tanked.
And yet… at work I need a PGP key to sign every commit, as part of security policy.
Posted Nov 9, 2021 17:19 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Sure! But in all these cases these are people you don't actually know at all. Surely in that case the trustworthiness of the communication is kinda irrelevant? The relevant point is the one you knew before you started: this is a number that connects to someone you don't know, and you have no actual reason to trust that the phone number is the number you think it is. No PGP-style web of trust would help here either because *you don't know this person*: the PGP web of trust's trust should be zero (though thanks to the lunacy that is transitive trust, if the web was wide enough it might *not* be zero, entirely falsely) and the Signal web of trust tells you "I trust that this person owns this phone number" -- but you still don't trust the phone number! And this is mostly something that human beings in the real world are familiar with: though mistakes in this area do happen and are the foundation of a lot of social engineering attacks, many of which are as old as the telephone and at least some of which have been in existence for as long as the mail (e.g. who wrote the letter which exposed the Gunpowder Plot? Some speculate that it might have been Robert Cecil, the then Secretary of State... that's the exact same attack, in the early 17th century.)
And this idea (a phone number which claims in the place you found it to be e.g. a work number but is actually someone else's) is a social engineering problem which cannot possibly be fixed by any sort of technical solution below a hypothetical reliable global identity service (and then you have to worry about the people who run that service). No such service exists, nor likely can it in the absence of a trustworthy world government.
(I don't think the security of Signal or PGP in re determining the trustworthiness of your communicants is likely to be relevant with regard to selling your old couch. You don't need to trust those people to do anything but give you money and turn up and take your couch away, and if they don't do the one they don't get the other. You don't *need* to trust them or know who they are.)
Posted Nov 9, 2021 19:35 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
A Web of Trust (WoT) doesn't have transitive trust by default; owner trust is set by you, and not imported from the key servers (ever).
If you don't trust anyone else's assertions about a link between an identity and a key, then you do not give anyone other than yourself owner trust. You end up with key trust only existing for keys that you've verified yourself.
In practice, this isn't how identity works in human interaction - you trust not only identities that you've verified yourself, but also identities that other people give you in an introduction. A published signature from me on someone else's key is the WoT equivalent of me being willing to introduce this person under this identity to anyone I know; you can decide how much introductions from me are worth (owner trust), and that will lead into the WoT algorithms deciding whether you'd be willing to trust a key based on who's willing to introduce you to the owner of that key.
Now, the GPG implementation of the WoT has a lot of UX problems, which mean that it gets into a bad state - but that's not WoT style, that's GPG's implementation:
In terms of the jargon, if I were willing to put the work in to fix WoT issues, I'd make "owner trust" the only form of trust; "key trust" would become "verification". Then, keys that are fully verified would have their owner trust used to help verify more keys; trust remains something that you only set manually.
Posted Nov 4, 2021 7:38 UTC (Thu)
by madhatter (subscriber, #4665)
[Link]
But that is exactly how people who care about the integrity of their PGP keystore validate new entries therein.
Posted Nov 2, 2021 10:39 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
At least with WhatsApp (I've not used Signal, but it's the same underlying protocol, so the only issue is whether Signal has a UI at least as good as WhatsApp's UI for security), there are two ways for me to treat the encryption:
To support the second option, WhatsApp puts notifications in chat of the form "Your security code with ${contact} changed. Tap to learn more" when the other end changes key. If I tap that, I have a "Verify Code" button, which brings me back to cross-checking 12 blocks of 5 decimal digits with my contact.
I can then make an informed decision about how I treat my contact; if the security is not something I care about for this conversation, I can ignore it (option 1 again). If I do care, I can keep communicating, but I treat my contact as compromised until I can reverify codes.
Posted Nov 1, 2021 17:20 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (7 responses)
Disclaimer: I believe that "web of trust" could be made to work with a good UX on top, so I'm not unbiased here.
The gap between full and ultimate trust in a key is about whether the key is a root of your web of trust. A key with ultimate trust is a root key in the web of trust - you trust keys it signs, even if it isn't verified by the web of trust. A key with full trust needs to be verified by the web of trust before you trust keys it signs.
The UX issue here is that we're trying to bring trust from outside the web of trust so that we can pretend that the web of trust is all that exists. Out in the real world, we have two separate statements we want to make:
GPG instead forces you to express both of these things via a single trust value, where "ultimate" is the special case that you are personally confident that the record is correct outside the web of trust, and that you can trust assertions made by this record 100% without needing corroboration. This is in part because, once you're doing this, it's easy to publish your confidence in a record to the key servers, enabling a global web of trust to exist.
Personally, I think this conflation is a mistake; while it means that GPG gets to do everything via the web of trust algorithm, it makes it very hard to explain things to end users - as your question demonstrates (it shouldn't even be a question you can ask).
Posted Nov 1, 2021 18:19 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Posted Nov 1, 2021 19:03 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (5 responses)
Posted Nov 1, 2021 19:11 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
Posted Nov 1, 2021 19:27 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (3 responses)
Second, yes, end-users don't care about individual pieces, but for a technical discussion it usually helps to distinguish between unrelated topics.
Posted Nov 1, 2021 20:10 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Fine, break it into whichever pieces you like. It's irrelevant.
> but for a technical discussion it usually helps to distinguish between unrelated topics.
Yes and no. It helps when you're discussing changes to be made. It does not help when you're trying to understand the overall user experience of a product and how it compares to other products, such as Signal. The entire ecosystem of "encrypted email," as a whole, is grossly inferior to products like Signal, even allowing for some theoretical differences in their respective threat models. And it's never going to get better, unless people are willing to accept that reality and work to change it. Breaking the problem space apart into a bunch of different pieces and saying "not my problem, it's that other piece that's terrible!" is entirely unhelpful.
In other words: Pieces, such as GPG, Enigmail, Thunderbird, etc. do not have their own individual UX's. There is only the holistic UX of their combination. That is what users actually experience, and therefore that is what we must care about, if we're to care about UX at all.
Posted Nov 2, 2021 9:16 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Yes, exactly, and farnz' subthread was an attempt to do exactly that — which you then derailed by shifting attention to a completely irrelevant issue.
Posted Nov 2, 2021 10:37 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
My comment was a response to NYKevin's throwaway remark about one way in which encrypted e-mail implemented as an GPG overlay on unencrypted mail has bad UX. I chose to expand on his point about bad UX by explaining first what it's trying to do, and next why this is bad UX and how I'd fix it for a web of trust.
It's not unreasonable, in that context, to then move onto other bad UX patterns in encrypted e-mail as implemented.
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
* Sending a cleartext reply-to-all.
* Signing a key without seeing adequate evidence of its owner's identity.
* Assigning the wrong trust level to someone else's key.
* And so on...
Fedora considers removing NIS support
> * Assigning the wrong trust level to someone else's key.
* updates pushed by google/apple store
* needs a phone number
* no reproducible builds (so you don't know if what you get from google is the same stuff that you get compiling it).
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
* Just imitate the accent (phone calls cut A LOT of frequencies, it's easy to confuse people over the phone)
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Fedora considers removing NIS support
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names
Web of trust policy names