Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bastionzero.com

Post reply on HN
Print view View original

31–40 of 369 posts

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

#31

Post by c0l0 »

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.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

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

#32

Post by jaycroft »

pitaj wrote: post #27
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…

What's wrong with TOTP?

I was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test.

https://blog.trezor.io/why-you-should-never-use-google-authe...

Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untrustworthy, whatever your feelings on "the other crypto".

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

#33

Post by toomuchtodo »

thomascgalvin wrote: post #23
adreamingsoul wrote: post #16

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

I'm America, about 30% of the population would start screaming about the Mark of the Beast if we tried to roll out something like this.

Which is why you ignore them. No reason for a nation to be held back by this type of person. Same reason you don’t take cancer treatment advice from someone who suggests juicing.

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

#34

Post by seibelj »

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

Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero

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

#35

Post by [deleted] »

jaycroft wrote: post #32
pitaj wrote: post #27

Earlier quoted context omitted.

What's wrong with TOTP?

I was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test. https://blog.trezor.io/why-you-should-never-use-google-authe... Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untru…

[deleted]

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

#36

Post by Signez »

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

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 or whatever."

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

#37

Post by kstrauser »

KarlKemp wrote: post #22

I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The sam…

The "trust" here largely refers to identity. Do you trust that everyone in your house is your relative, by virtue of the fact that they're in your house? That falls down when you have a burglar. Similarly, is it good to trust that everyone on your corporate network is an employee, and therefore should have employee-level access to all the resources on that network? I wouldn't recommend it.

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

#38

Post by ctime »

The real crux of the issue is the long-tail of applications which were never conceived with anything but network-based trust. I'm certain the DoD is absolutely packed with these, probably for nearly every workflow.

The reason this was so "easy" for Google (and some other companies, like GitLab[1]) to realize most of these goals is that they are a web-based technology company - fundamentally the tooling and scalable systems needed to get started were web so the transition were "free". Meaning, most of the internal apps were HTTP apps, built on internal systems, and the initial investment was just to make an existing proxied internal service, external and behind a context aware proxy [1].

The hard part for most other companies (and the DoD) is figuring out what to do with protocols and workflows that aren't http or otherwise proxyable.

[1] https://cloud.google.com/iap/docs/cloud-iap-context-aware-ac...

[2] https://about.gitlab.com/blog/2019/10/02/zero-trust-at-gitla...

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

#39

Post by reginaldo »

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

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

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

#40

Post by CGamesPlay »

meepmorp wrote: post #17
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…

Also, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.

I am a bit concerned that this will be read as "Password policies must require the use of no special characters", possibly as a misguided attempt to push people away from adding using "Password123!" as the password. I wish the memo had spelled out a little more clearly that there's nothing wrong with special characters, but they shouldn't be required. Also, is a whitespace a special character?
Post reply on HN