Incorrect advice wording

[gitcnd]

This wrong word "most": ... to select the most appropriate authentication requirements for their digital service offering. Should read "minimum" ... to select the minimum appropriate authentication requirements for their digital service offering.

It's an important distinction.

[gitcnd]

FYI: "more secure" does NOT necessarily mean "harder" or "slower" or "less convenient" or "more expensive" or any other negative connotations. If you specifically want to deter characteristics, please specify the characteristics instead of the security strength when so doing.

[jricher]

The text in question doesn't say "most secure", it says "most appropriate", which is contextual. The minimum isn't always the most appropriate in a given context.

[gitcnd]

Hi Justin - thanks for the personal response! I'm not sure if I expressed what I mean very well. What I'm trying to get at, is that we should not be deterring people from using better solutions.
If you chose to disregard "characteristics" like I mentioned from the advice for a moment, then "most appropriate" will always be AAL3 in every case (because it's most secure, and we disregarded all else). If you're trying to link appropriateness to security strength in some context where reduced strength is acceptable for some reason, it's going to be because of whatever that "reason" turns out to be - which will be those characteristics I mention (or the "given context" that you talk about).

The problem I'm trying to address, is that the wording at present literally presents the misconception that "higher" levels might be less-appropriate for whatever reason (I used "security strength" in my example, but I do actually mean any characteristic(s) from the context). There are all kinds of implementations exhibiting different strengths of character, and the future and innovation are going to bring more - we should help users understand the "Scope" of what they should be choosing from, not prescribing to them something we call "most appropriate" when what we're really trying to say is that anything "this level or better" should be used.

One big problem I observe with modern security compliance, is a move towards "risk based" security, which might be OK if the subject understood who the risk should apply to, but unfortunately, they too often do not. A risk to a company that PII gets exposed might be very low (or even non-existent, like when they have insurance), but the risk to the individual of that exposure is very high. It's going to help if we can educate readers that they are allowed to choose "better" - right now - if they (for example) picked AAL3 when their assessment says they need AAL2 - they're going to be in a precarious situation because they have demonstrated non-compliance with this standard (they chose not to use the "most appropriate"), even though their choice delivered a better outcome.

Hopefully that makes sense?

[jricher]

But that's exactly it: this part of the guides is not at all saying "this level or better", nor is it saying that it should "always be AAL3 in every case". It is in fact saying that there are other considerations that you can't "disregard" in choosing what's appropriate for your situation.

Furthermore, the way the guidance is written, you'll see that the levels are designed to be subsumptive. With AAL as an example, fulfilling AAL3 :also: fulfills all of the requirements for AAL2, so someone who's compliant at AAL3 is already compliant at AAL2 and AAL1, and the scenario you describe does not exist. This is true for all xALs. You can always do more than what's required at a level and still be compliant -- that's how requirements work.

(Note that these are all my own personal comments and not an official NIST response, but I wanted to help clarify.)

[gitcnd]

Hi Justin - yes, I've been following your work on this for some time - I know where you stand. My worry is that this is going to get interpreted literally: "most appropriate" is an unambiguous phrase; it's not subsumptive.

[jricher]

A section has been added to the FAQ to help address this. Keeping the issue open as we may also review the referenced specification text.

https://pages.nist.gov/800-63-FAQ/#q4

[gitcnd]

That section begins with two opinions, neither of which is accurate, and builds on them dissuade readers from going higher, which in a security publication seems the opposite to ideal - we should be suggesting people "do the best they can", not the least they can.

"There is always a trade-off in choosing the appropriate level across all categories."

and

"Higher levels do come with greater security and assurance, but at the cost of greater complexity, overhead, and potential for failure."

We're talking about hundreds of techniques and thousands of products here - this is not some kind of theoretical linear scale, nor even a scale at all.

You may have seen a lot of rubbish high-strength products, but that doesn't make those opinions a universal truth, nor that it would always be that way if it was. There are some really garbage low-strength authenticators out there, which are demonstrably worse in overhead, complexity, and failure potential than some really good high-strength ones - so that last sentence alone is highly inappropriate.

It also reads like a higher xAL has a greater potential for failure - except I'm pretty sure "failure" isn't the right word there, not that this sentence is fixable anyhow, because it's not true in general.

And there are a HUGE number of considerations that have been completely ignored here too - like ease of enrollment, simplicity for the user, financial costs, efficacy defeating real-world attack issues like malware, social-engineering, friendly-fraud, phishing, and MitM; convenience, ubiquity, ability to work internationally or in aeroplanes at 35000ft, loss handling and re-enrollment procedures and the relative strengths of both of those, device lifespan, accessibility, user skill and ability requirements, restrictions in classified environments [e.g. no cameras, or no RF], duress handling, speed, infrastructure requirements, compatibility with systems, vendor support, security sovereignty, updates, company reputation, laws and trust and nation-state interference, supply interdiction, ... if we're going to point out drawbacks, surely we should be comprehensive - these people are using this advice to protect users - they NEED to know what to look out for, not just a tiny selection of 3 not-very-relevant issues.