Skip to content
September 22, 2021 / Jim Fenton

Comments on the Federal Zero Trust Strategy

The Office of Management and Budget (OMB) and the Cybersecurity and Infrastructure Security Agency (CISA) recently released a request for public feedback on a draft strategy for a zero-trust cybersecurity architecture for the US Government in response to Executive Order 14028 issued last May. Public comments were due September 21. The comments I submitted are below.

Thank you for the opportunity to provide public comment on your draft, Moving the U.S. Government Towards Zero Trust Cybersecurity Principles. I hope that the below comments will inform your decisions as you finalize this policy.


Use of phishing-resistant MFA

Phishing is an important attack vector and must be addressed. The use of phishing-resistant MFA critically prevents the use of credentials by impostor websites and services such as mobile apps. Requiring phishing-resistant MFA by agency staff, contractors, and partners is a logical step, although existing PIV and derived PIV credentials are already phishing resistant. At the present time, PIV credentials are not available to contractors and partners that typically do not require access to federal facilities, so an alternate approach to this problem might be to unify the authentication methods used by these parties to use PIV or equivalently secure authenticators.

Requiring phishing-resistant MFA as an option for public access to federal websites and online services encourages use and familiarization with these authentication methods by the public, in addition to their direct role in blocking phishing attacks. Members of the public that adopt phishing-resistant authenticators also need to be cautioned against the use of other multifactor authentication methods that they might be prompted to use by phishing actors.

Currently, many commercial products that offer phishing-resistant authentication using the WebAuthn standard do not meet the current technical requirements of verifier impersonation resistance in NIST SP 800-63-3 (cited in footnote 4 of the draft) because they bind the authentication to the domain name of the verifier rather than to the communication channel itself. However, this non-compliance does not significantly impact the phishing resistance of these authenticators. It is widely expected that NIST will recognize these authenticators as an alternative method of achieving verifier impersonation resistance in the next revision of that Guideline. For clarity, it would be useful to explicitly recognize these authenticators as phishing-resistant in this policy as well.

Checking passwords against blocklists

This draft notes that CISA will be making a service available to check passwords against known-breached data. Use of a password blocklist is required by NIST SP 800-63B as well. The size of these blocklists should be carefully considered. A blocklist that is too small does not sufficiently protect against the use of common passwords, but a list that includes every common or breached password is likely to frustrate users, who will then focus on coming up with an acceptable password rather than other aspects of password strength such as length. There should also be the ability for individual agencies to supplement these blocklists with agency-specific entries.

The use of common passwords is not the only weakness in password use. Agencies should be reminded of the need to store password verification secrets securely (using, at a minimum, “salting” and iterative hashing) and of the need for rate limiting to blunt online guessing attacks.


DNS encryption

The draft policy notes the importance of encrypting DNS traffic, but seems to be undecided on the use of DNS-over-HTTPS (DoH, which operates in browsers) or DNS-over-TLS (DoT, which is normally implemented in the operating system). There is significant interesting DNS traffic that is not initiated by browsers, such as that coming from email clients, instant messaging applications, and many others. This policy should consider the need for DNS encryption outside the browser as well as for Web traffic.

Encryption of DNS traffic does limit agencies’ ability to inspect DNS requests for indications of malware and other inappropriate behavior, so there is somewhat of a security tradeoff in its implementation. If CISA’s Protective DNS offering is centralized, it may not be possible for individual agencies to employ DNS monitoring for security purposes.


Notwithstanding the removal (by OMB M-18-23) of the requirement to implement DNSSEC that was established by M-08-23, DNSSEC implementation continues to be an effective defense against demonstrated DNS spoofing attacks and in providing a trust framework for data published in DNS. DNSSEC has a single “source of truth” that is easily monitored for fraud, unlike the WebPKI which has in excess of 100 certificate authorities, any of which could potentially publish a rogue certificate. Minimizing external security dependencies is very much in the spirit of the Zero Trust architecture. While Certificate Transparency helps a vigilant domain to detect the mistaken issuance of a certificate to the wrong party, many CAs are in jurisdictions where they could be compelled to issue a certificate and make it available to a bad actor, perhaps in support of a state-sponsored attack. For this reason, the use of DANE in addition to WebPKI, particularly for sensitive applications, should be strongly considered.

Furthermore, M-08-23 was in some cases interpreted as a requirement to DNSSEC-sign .gov domains but not necessarily to implement DNSSEC verification of DNS requests originating within an agency. In contrast many consumer DNS providers, including internet service providers and services such as Google, implement DNSSEC verification thereby giving their users a security advantage that these agencies currently do not have available. This policy should require verification as well as DNSSEC signing by agencies; verification could potentially be an aspect of the CISA Protective DNS program.

Encrypting email traffic

The draft correctly notes the importance of encryption for email traffic. It describes the use of MTA-STS to accomplish this by allowing a domain to advertise a policy that it supports SMTP-over-TLS. However, this publication requires additional infrastructure (web servers) to effect this, and requires caching of previously received policies to overcome the possibility that a bad actor will block the policy advertisement. In contrast DANE, which is deployed on DNSSEC protected domains, provides a way to publish a similar policy without this trust-on-first-use limitation and without the need to stand up additional infrastructure to support policy publication. DANE should be strongly considered as an alternative to MTA-STS for this requirement.

In addition, there is a complementary standard, REQUIRETLS (RFC 8689), that allows the sender of an email message to tag it to indicate that the message must only be sent over a TLS-protected channel, effectively overriding the opportunistic nature of STARTTLS. This most directly satisfies the stated goal of guaranteeing that Federal emails are encrypted in transit. Unfortunately, REQUIRETLS has not received significant deployment, but government interest in this capability would undoubtedly motivate deployment. REQUIRETLS builds upon MTA-STS or DANE.


Please do not hesitate to contact the undersigned if any further information or clarification is needed.

James L. Fenton
Altmode Networks
Los Altos, California

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: