[discuss] Fixing the security ecosphere

Mon Feb 24 17:14:22 UTC 2014

(apologies in advance if you get this more than once)

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140224/b18d9202/attachment-0001.html>