[Strint-attendees] Fixing the security ecosphere
Phillip Hallam-Baker <hallam@gmail.com> Mon, 24 February 2014 16:42 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: strint-attendees@lists.i1b.org
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by diego.dreamhost.com (Postfix) with ESMTP id 5E7B94801B for <strint-attendees@lists.i1b.org>; Mon, 24 Feb 2014 08:42:53 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id mc6so2539549lab.41 for <strint-attendees@lists.i1b.org>; Mon, 24 Feb 2014 08:42:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vyOT5fiQBltaL7zUWg5GrZFo4iyM9FuoZAI2wOD8+IA=; b=ZicUHRUpMTBEo453iUXjzyL86UJ+TiKc8Q1NM+Jg0JOww0OE1d1kvsNs9QVYrytiE6 nsIvydeIzTiFt2vDABmQEDlNzkXRc8frACqXcCZBDVG8N+l6ZCufQ7CS7MkoJx1C72TT xOxS1b/Pmfyx2FkA4LfeoLAJzcl9qwgKCkbpTgrNraNsgFco8mEs0qMPzjKXJerQFyA1 2Kr6bvjmaXA5SSKeMPFMR7rZO8++d0e9PBl3ZYxUnmYlfQEHu+TIPF6qGE0SyXBBPkWb B7uFhX3IJHqaUgQNTTtXdmdNuJC3HoqBsB7VC0Gxc8VsIB8nobxjEQJ22gd9GysNeU7h d5kQ==
MIME-Version: 1.0
X-Received: by 10.152.36.70 with SMTP id o6mr12605334laj.7.1393260171618; Mon, 24 Feb 2014 08:42:51 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Mon, 24 Feb 2014 08:42:51 -0800 (PST)
Date: Mon, 24 Feb 2014 11:42:51 -0500
Message-ID: <CAMm+LwjthQ5BzaOq4sx-4DEegZQpjU7BrnxCgWfSqL-HRBSFOw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: strint-attendees@lists.i1b.org
Content-Type: multipart/alternative; boundary="089e0160b6189bef3904f329a9c6"
Subject: [Strint-attendees] Fixing the security ecosphere
X-BeenThere: strint-attendees@lists.i1b.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: STRINT Workshop Discussion List <strint-attendees-i1b.org>
List-Unsubscribe: <http://lists.i1b.org/options.cgi/strint-attendees-i1b.org>, <mailto:strint-attendees-request@lists.i1b.org?subject=unsubscribe>
List-Archive: <http://lists.i1b.org/pipermail/strint-attendees-i1b.org>
List-Post: <mailto:strint-attendees@lists.i1b.org>
List-Help: <mailto:strint-attendees-request@lists.i1b.org?subject=help>
List-Subscribe: <http://lists.i1b.org/listinfo.cgi/strint-attendees-i1b.org>, <mailto:strint-attendees-request@lists.i1b.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 16:42:54 -0000
One of the main consequences of Snowdonia is that we can't expect to rely on US government agencies for security advice. Even if we personally trust the people at NIST and the COMSEC section of the NSA, the bulk of the industry does not and will not. There have in any case been serious problems with the old model. NIST interpreted its mandate to be to select security technology for use inside the US government and consequently many of the recommendations made are heavily skewed towards the needs of large bureaucracies rather than the individual users and small businesses that make up the vast bulk of the Internet. Even when the needs of consumers are primary, government recommendations are clouded by politics as witnessed by AG Holder's statement today reacting to the breach of credit card data at Target and other stores with a proposal for a federal breach disclosure law to mitigate the problem rather than require US banks to deploy chip and pin and eliminate it. We have plenty of cryptography technology. Some of that technology could be better with only a little bit of additional effort. But incremental improvement is hard. If we have a protocol with problems A and B then neither will ever be fixed because every time we try to fix A there will be a chorus of disapproval insisting that the real problem is B and when we look at B we will be told that we have to fix B first. What we need is a different approach to building the security ecosystem and I believe a new organization that can replace the role that NIST and the NSA are no longer acceptable guardians of. I'll explain the reasons this needs to be a new organization at the end. For now, what has to be done? First we need to define what our security criteria are. By this I mean really high level abstract criteria such as: 1) Prevent disclosure attack against message content. 2) Limit disclosure attack against Metadata confidentiality to parties trusted by the principals. 3) Require collusion of all carriers to perform traffic analysis. Those three criteria are all technically and politically achievable in my view. We have a clear security requirement 'disclosure attack against asset X' and we have a set of caveats that make the problem tractable according to existing standards or standards that might be created from existing technology. The fewer caveats, the stronger the security criteria. Next we need to define a usability criteria. Gone are the days when we can propose systems that require Internet users to spend their time hacking Linux config files to make a system work. Any system that requires end user participation to work and makes their life harder by a single click is going to fail in today's Internet. Security has to be frictionless at the end-user level. We can give them keys and certificates, that is fine, but this has to be transparent. Secondly we need to define domains of application, for example: Email Messaging. Synchronous messaging (chat, voice, video) Web Browsing. And for a particular domain we need at least one profile that meets one or more security criteria. For example for email client we might have: * Use SSL with RSA2048+ and AES128/SHA256 to secure SUBMIT, IMAP and POP * Authenticate the server cert against the hostname of the service, do not accept self signed certificates or unrecognized roots that were accepted by other applications (e.g. Internet Explorer). * Use NTLM or SCRAM-SHA256 [1] for SASL authentication The last part is the reason why we need this work to be done outside the standards organizations. Because currently we don't have an acceptable SASL mechanism for passwords. Not one. Every single option is defective. The digest based SASL mechanisms listed by IANA use obsolete crypto. NTLM is acceptable but proprietary and SCRAM-SHA256 isn't even listed, only the SHA1 version is. Use of PLAIN and LOGIN within an SSL tunnel IS NOT SECURE. And I will be happy to share the proof. Basically if I can get a victim to visit one Web Site in IE and download my self signed cert, I can perform a MITM attack and read out their usernames and passwords from Gmail. This is the reason that I want a new organization to be looking at this, there is a conflict of interest between writing profiles and standards. If the IETF is doing this work then getting some doubrie required in a profile is just another step in the standards game. Profiles become leverage for the lazy working groups to get their ideas deployed. The profiles have to be driven by security practitioners who are out in the field. The OWASP and Linux plumber types. I don't want NewOrg to solve the problem or write standards because that merely shifts the conflict of interest. But what could happen is that NewOrg does what the CabForum has done when they don't think an IETF security spec is secure: They publish a disagreement on that one area. So the way that I would like the security profile issue to be resolved is that NewOrg would do the following: 1) Determine that the current SASL mechanisms do not support the criteria that all password exchanges be secure against disclosure under all circumstances including to a trusted party or a properly credentialed MITM. I.e. it is not acceptable to rely on SSL or TLS to secure username and password data. 2) Write and approve a defect report that is submitted to IETF (or whatever the change control body is) 3) The IETF makes a fix (an easy short term one in this case, add SCRAM-SHA256 followed by do the right thing with public key crypto blinding) 4) A new profile is published in which the caveat can now be lifted. The charter of NewOrg should be multi-stakeholder but can certainly allow a great deal of scope for government support. One of the chief problems, perhaps the biggest problem in Internet governance right now is finding useful things for governments to do. To be effective, NewOrg need not be a single organization. In fact there are benefits to having more than one. Security is not a uniform commodity. The security requirements that are important in the US are not the same as those important in the EU or Brazil. What really characterizes NewOrg is adoption of the process and interfacing to the standards organizations through formal defect reports and to the public through profiles. So NewOrg need not be chartered top-down, it can emerge from a bottom up process. We went through something similar when phishing hit the banking industry. I was organizing a crisis meeting with the major banks and so was David Jevans at Tumbleweed. A few months later we merged our efforts into what became Anti-Phishing Working Group. -- Website: http://hallambaker.com/
- [Strint-attendees] Fixing the security ecosphere Phillip Hallam-Baker