Inching closer to the complete digital lockdown, I see.
I read the federal government’s Zero-Trust Memo so you don’t have to
141–150 of 369 posts
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#142> Today’s email protocols use the STARTTLS protocol for encryption; it is laughably easy to do a protocol downgrade attack that turns off the encryption. This can be solved with DANE, which is based on DNSSEC. When properly configured, the sending mailserver will force the use of STARTTLS with a trusted certificate. The STARTTLS+DANE combination has been a mandatory standard for governmental organizations in the Neth…
Is DANE @tptacek approved of? You say DNSSEC and it triggers my internal alarm bells.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#143Earlier quoted context omitted.
Way earlier than that, even. > Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too. https://web.archive.org/web/20160624033024/https://pages.nis...
SHOULD NOT and MUST NOT are very different from a compliance perspective. The former usually means something between nothing at all and “you can do it but you have to write paperwork that no one will actually read in detail, but someone will maybe check the existence of, if you do”. The latter means “do it and you are noncompliant”.
https://datatracker.ietf.org/doc/html/rfc2119 is a good reference, although those precise definitions may or many not be in effect in any particular situation (including this one).
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#144Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.
Here in Czechia we have BankID and it is problematic: 1) No verification that the user trusts that particular bank to perform this service. Most banks just deployed BankID for all their customers. 2) No verification between bank and government ensuring that particular person can be represented by particular bank. In principle a bank could inpersonate a person even if that person have no legal relation with that bank.…
#2 and partially #1 are solved by regulation and reputation: banks are highly regulated business, and BankID support requires specific security audit.
Ad #3: FIDO is basically unusable for banking. It's designed for user authentication, not transaction signatures which banks need (and must do because of the PSD2 regulation).
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#145This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edg…
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…
"Software freedom" doesn't really make sense when the software's function is "using someone else's software". You're stil at the mercy of the server (which is why remote attestation is even interesting in the first place).
If you want to use free software, only commect to Affero GPL servces and don't use nonfree services, and don't consume nonfree content.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#146Earlier quoted context omitted.
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…
Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some po…
Free software doesn't really work in a networked untrusted world.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#147Really pleasantly surprised at how progressive this memo is. It will be interesting to see the timelines put in place to make the transition. Btw - I'd love to see the people who put this memo together re-evaluate the ID.me system they're implementing for citizens given how poor the identity verification is.
I have an issue with using ID.me for government websites, because it is a privately owned company. Online authentication at this point seems as important as USPS service and warrants being owned and developed by the government itself.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#148Earlier quoted context omitted.
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…
Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some po…
> Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with.
No, it isn't. It's a way for corporations and governments to restrict what people can do with their devices. That makes sense if you're an employee of the corporation or the government, since organizations can reasonably expect to restrict what their employees can do with devices they use for work, and I would be fine with using a separate device for my work than for my personal computing (in fact that's what I do now). But many scenarios are not like that: for example, me connecting with my bank's website. It's not reasonable or realistic to expect that to be limited to a limited set of pre-approved software.
The correct way to deal with untrusted software on the client is to just...not trust the software on the client. Which means you need to verify the user by some means that does not require trusting the software on the client. That is perfectly in line with the "zero trust" model advocated by this memo.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#149Earlier quoted context omitted.
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…
"Software freedom" doesn't really make sense when the software's function is "using someone else's software". You're stil at the mercy of the server (which is why remote attestation is even interesting in the first place). If you want to use free software, only commect to Affero GPL servces and don't use nonfree services, and don't consume nonfree content.
You're usually only at the mercy of the server because you don't control the client; a free YouTube client like VLC remains useful. A free Microsoft Teams client would be useful. I allege that free VNC clients are also useful, even if there's non-free software on the other end.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#150Earlier quoted context omitted.
I think browser-based streaming is the only scenario impacted. Apps can already interrogate their platform and make play/no play decisions. They are also already limiting (weakly) the max number of devices that can playback which requires some level of device identification, just not at the confidence required for authentication.
Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by n…
This should be obvious from your comment but I think it's worth calling something out explicitly here: a bank that does that is mandating that you accept either Apple's or Google's terms of service. That's a lot of power to give to two huge companies.
I think we'd do well to provide the option to use open protocols when possible, to avoid further entrenching the Apple/Google duopoly.