I read the federal government’s Zero-Trust Memo so you don’t have to • Hacker News Board

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#131

Post by dathinab » Thu, Jan 27, 2022, 9:34 PM UTC

Signez wrote: post #36

c0l0 wrote: post #31

Earlier 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.…

Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement. Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation…

If something like that is good enough to fulfill the requirements, that would be good.

Some services already thinks like that, like I think discord.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#132

Post by mjg59 » Thu, Jan 27, 2022, 9:34 PM UTC

tptacek wrote: post #126

mjg59 wrote: post #122

Earlier quoted context omitted.

It's not clear to me that a VPN endpoint is a meaningfully smaller attack surface than an authenticating proxy? The VPN approach has a couple of downsides: * You don't have a central location to perform more granular access control. Per-service context aware access restrictions (device state, host location, that sort of thing) need to be punted down to the services rather than being centrally managed. * Device state…

Sure: an authenticating proxy serves the same purpose. I agree that unless you have a pretty clever VPN configuration, you're losing the device context stuff, which matters a lot in some places. I'd do: * SSO integration on all internal apps. * An authenticating proxy if the org that owned it was sharp and had total institutional buy-in both from developers and from ops. * A WireGuard VPN otherwise.

If you have the institutional buy-in to handle auth being done at the proxy level, that gets you away from having to implement SSO per service. I agree that doing this well isn't trivial, but in the long term there's a reasonably compelling argument that it makes life easier for both developers and ops.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#133

Post by dragonwriter » Thu, Jan 27, 2022, 9:37 PM UTC

gkop wrote: post #121

mooreds wrote: post #108

Earlier quoted context omitted.

To be fair, this was part of the NIST guidelines since Mar 2020. A whole appendix was added to justify it: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

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”.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#134

Post by count » Thu, Jan 27, 2022, 9:39 PM UTC

Godel_unicode wrote: post #92

kelnos wrote: post #91

Earlier quoted context omitted.

No, I'd expect it does include TOTP. Read it as "discontinue support for protocols that supply one-time codes". A TOTP app would fall under that description. TOTP apps are certainly better than getting codes via SMS, but they're still susceptible to phishing. The normal attack there is that the attacker (who has already figured out your password) signs into your bank account, gets the MFA prompt, and then sends an SM…

All of this is really government we-don't-pick-winners speak for yubikeys.

PIV/CAC Smartcards.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#135

Post by dathinab » Thu, Jan 27, 2022, 9:39 PM UTC

btbuilder wrote: post #125

shbooms wrote: post #101

Earlier quoted context omitted.

I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If…

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 not allowing you to control the device you own.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#136

Post by jandrewrogers » Thu, Jan 27, 2022, 9:41 PM UTC

kelnos wrote: post #98

jandrewrogers wrote: post #76

Earlier quoted context omitted.

There is a large contingent of non-religious people who are against it on civil liberties grounds. The resistance to it truly crosses both parties, and it requires the cooperation of the States, which makes it politically non-viable as a practical matter.

The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification that are a pain in the ass for a regular citizen to have to deal with. And the REAL ID stuff essentially makes state IDs conform to a national ID specification anyway. And regardless, if you do want a national US ID, you just get a p…

Many State governments do not recognize a US passport as valid ID. This was unexpected when I first encountered an example of it, but apparently that is normal and I was just the last person to find out. The REAL ID legislation only regulates processing and format, there is no enforceable requirement to share that with the Federal government and many States (both red and blue) do not in practice. States recognize the ID of other States, as is required by the Constitution.

Because there is no official national ID system, you can do virtually everything Federally with a stack of affidavits and pretty thin "evidence" that you are who you claim to be. They strongly prefer that you have something resembling ID but it isn't strictly required. This also creates a national ID bootstrapping problem insofar as millions of Americans don't have proof that they are Americans because there was never a requirement of having documentary evidence. As a consequence, government processes are forgiving of people that have no "real" identification documents because so many people have fallen through the cracks historically.

Of course, this has been widely abused historically, so the US government has relatively sophisticated methods for "duck typing" identities by inference these days.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#137

Post by hansvm » Thu, Jan 27, 2022, 9:45 PM UTC

Signez wrote: post #36

c0l0 wrote: post #31

Earlier 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.…

Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement. Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation…

Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#138

Post by imrejonk » Thu, Jan 27, 2022, 9:48 PM UTC

> 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 Netherlands since 2016.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#139

Post by bigiain » Thu, Jan 27, 2022, 9:49 PM UTC

kelnos wrote: post #88

reginaldo wrote: post #39

Earlier quoted context omitted.

It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.

It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.

I’m not even so sure I’m totally against banks doing that either.

From where I sit right now, I have within arms reach my MacBook, a Win11 Thinkpad, a half a dozen Raspberry Pis (including a 400), 2 iPhones only one of which is rooted, an iPad (unrooted) a Pinebook, a Pine Phone, and 4 Samsung phones one with its stock Android7 EOLed final update and three rooted/jailbroken with various Lineage versions. I have way way more devices running open source OSen than unmolested Apple/Microsoft/Google(+Samsung) provided Software.

My unrooted iPhone is the only one of them I trust to have my banking app/creds on.

I’d be a bit pissed if Netflix took my money but didn’t run where I wanted it, but they might be already, I only ever really use it on my AppleTV and my iPad. I expect I’d be able to use it on my MacBook and thinkpad, but could be disappointed, I’d be a bit surprised if it ran on any of my other devices listed…

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#140

Post by reilly3000 » Thu, Jan 27, 2022, 9:49 PM UTC

c0l0 wrote: post #31

staticassertion wrote: post #2

This 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.…

How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client.

If you want to get a package that is in the Arch core/ repo, doesnt that require a form of attestation?

I just don’t see a slippery slope towards dropping support for unofficial clients, we’re already at the bottom where they are generally and actively rejected for various reasons.

Still, the Android case is admittedly disturbing, it feels a lot more personal to be forced to use certain OS builds; that goes beyond the scope of how I would define a client.