Plan for updating technical configuration/best practices

[znewman01]

I think it's great that this proposal is so specific about e.g. encouraging ECDHE, discouraging RC4, etc. But I worry that for many agencies this will be set-and-forget: if someone comes up with an attack on TLS1.0 or AES 128 is no longer considered sufficient in 2016, what would the plan be to upgrade any agencies that already implemented TLS1.0? My suspicion is that they wouldn't do it on their own accord.

[richardlwarren]

Actually, my suspicion is they won't have implemented prior to that, and be able to leverage upgraded standards as yet another reason for further delaying implementation. That's probably overly cynical, but experience-based nonetheless.

[konklone]

@znewman01 While the proposal text itself (on the homepage) will likely become a lot less fluid, the rest of the pages are intended to be living documents. We've got to hit the balance where the specific proposal text indicates what's required of people, while not putting the technical details in a place that will be challenging to update.

[znewman01]

@richardlwarren fair, and I think

@konklone I think it's a great decision to keep this a living document, but I don't know whether that totally addresses my concern.

I suppose what I'm getting at is that it wouldn't be clear to me as someone reading this proposal that I had an obligation beyond the initial set-up. Am I supposed to keep checking this page? How often? What's the quickest way to find out if something has changed? If there's a catastrophic attack discovered but I don't read the news, how do I find out about it?

I guess I'd like to see the checklist in #53 have as a final item something like "sign up for this email list for important security updates on SSL implementation" or "check back every 3 months" or "register your site here and we'll keep checking your certs for you and alerting you if something's wrong" or something.

It doesn't have to be exactly that, but I think making responsibilities for the future more clear would be good. I know that this proposal will keep changing, and I always hear about it when new SSL vulnerabilities are discovered, but a lot of people wouldn't.

[dnesting]

What you seem to be advocating is something that proactively reviews or scans the configuration of web sites, identifies vulnerabilities such as broken or weak crypto, and obligates the site operator to mitigate the vulnerability. This process largely exists today independently of this https proposal and I believe it would be effective at addressing your concerns. I don't think we need to rely on site operators checking this (or any) web site periodically in order to be secure against real vulnerabilities.

[dstufft]

Perhaps this can simply be settled by adding a FAQ item that says something along the lines that the best practices for TLS are constantly evolving and that any deployment needs to have it's configured periodically checked for current best practices.

[konklone]

I think @dnesting is pointing to the inevitability of public auditing as a compliance mechanism, and that's something that's going to be needed no matter what.

[znewman01]

I think you're absolutely right, @dnesting, but I'd also like to see this information communicated. In my opinion, an FAQ item along the lines of "How do I ensure that my SSL deployment is always up-to-date with regard to current security recommendations?" would be a great idea, as @dstufft suggests.

I'll let y'all decide how/whether to resolve this, but I just wanted to bring it up. It was my first reaction as I read the proposal pretending not to know anything about TLS.

[dnesting]

@konklone @znewman01 Yes, I think such a thing will need to exist (external auditing), but I also believe some of this auditing exists today in the form of security scans. In the interests of open data, we might consider building a new service and dashboard with this type of information on it (because we want to track HTTPS uptake anyway to measure success for this effort, right?), but I'm less concerned about the security implications of poor crypto provided our security scans are effective and comprehensive enough to look for these types of things. We should verify that these security scans exist for all federal web sites and are effective at catching things like this. I'm all for redundancy for reliability, but I have no interest in seeing dueling security scanners with potentially different ideas about what's vulnerable.

And, sorry, yes, @znewman01 I agree once we figure out a good suggestion here a FAQ item as you describe seems useful. Great suggestion.

[NoahKunin]

@znewman01 Quick overview of what we do already:

• we have multiple mechanisms in the Federal Government to let people who are in charge of information systems know if there's a critical vulnerability or something need to be updated. US-CERT is primarily responsible for sending out those notices, and notices get distributed to system owners.
• How we drive toward new best practices or standards is a bit more nuanced. You can see part of that discussion on No mention of NIST SP 800-52r1 #86. NIST is the team responsible for issuing new standards or updating old ones. When appropriate, NIST also runs its own scanning infrastructure across the .gov domain. There's also a Federal CIO and a US Digital Service that produces and distributes best practices, like the Digital Playbook, and distributes said practices across all CIO and technology divisions in Government.

After we drive the policy toward a 1.0, there will be several opportunities to make the policy easy to comply with and help system owners keep their server communications safe. Thanks again for contributing!