Repository navigation
Plan for updating technical configuration/best practices #81
Description
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.
Activity
richardlwarren commentedon Mar 18, 2015
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 commentedon Mar 18, 2015
@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 commentedon Mar 18, 2015
@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 commentedon Mar 18, 2015
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 commentedon Mar 19, 2015
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 commentedon Mar 19, 2015
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 commentedon Mar 19, 2015
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 commentedon Mar 19, 2015
@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 commentedon Mar 20, 2015
@znewman01 Quick overview of what we do already:
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!