[perpass] Security delivery model

Phillip Hallam-Baker <hallam@gmail.com> Wed, 29 January 2014 17:11 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96B41A03F9 for <perpass@ietfa.amsl.com>; Wed, 29 Jan 2014 09:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxjyTXLUh2DC for <perpass@ietfa.amsl.com>; Wed, 29 Jan 2014 09:11:14 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 411981A03E9 for <perpass@ietf.org>; Wed, 29 Jan 2014 09:11:14 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id l4so1677513lbv.38 for <perpass@ietf.org>; Wed, 29 Jan 2014 09:11:10 -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=9Q7263fSu04JoEQ9ZcsPrt27Dsz8eljxxlRcxN5MYz8=; b=HGf+2h8RCD0+NCKnd+QlQdK/44wz0w8Lzp73keFVEI6tXAr9A1ukl88F1PE3EEVrOP zctDqSvlp5xskjlbAeeprtT24LyJvHDdSmTEZXZ4TJfmuldrurdvjZlLKMaxelOIHle3 HZKy++yQXG3hiqDsaaVhJLD6kcITzUqDn2VW+P/QHPxnbT/uqA8qOSDAsJTWE1cCh0gX e6F3XGb33OKTk7v3Ttk2I1344AyzPjOeR1MhIXu2NUwLcPVjKlwGBVGS1IxXmLNkG0qc sAGY5K6vly1RJDXoJCH1VPaxwGahNjOCwphnpmi83X2/33HHi47A0JcvzAR8E/q6LrWl 5DxA==
MIME-Version: 1.0
X-Received: by 10.152.87.142 with SMTP id ay14mr6041125lab.7.1391015470455; Wed, 29 Jan 2014 09:11:10 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Wed, 29 Jan 2014 09:11:10 -0800 (PST)
Date: Wed, 29 Jan 2014 12:11:10 -0500
Message-ID: <CAMm+Lwh6mV+5XAOPGWk6aKqMOLQtOqUnFPFgpt6g6mgGst7y9w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: perpass <perpass@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c3560cfe5ed204f11f067c"
Subject: [perpass] Security delivery model
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 17:11:20 -0000

If we are going to secure the net we need more than specifications, we need
running code and configurations to match.

Right now the problems caused by us using SHA1 are vastly less than the
problems caused by systems that are just terribly configured or don't make
the right security checks.

I have an exploit that lets me dump out usernames and passwords enclair
from certain applications despite the apparent use of 'security' because
most of the clients and many of the servers out there are not configured
right. But it does not currently even merit a CERT advisory because it
isn't a bug in the code or the specification, it is a configuration failure.


So here is the proposal, IETF and W3C develop a series of profiles for how
to lock down a service (Web, mail, chat) that provide specific security
protections against specified attacks. The suite would also include
profiles for backbone, datacenter providers etc.

These profiles can then form the basis for a range of security services
that can be fulfilled by providers as appropriate to the needs of the
clients.

So for example, Comodo and the other CAs and some of the DNS registrars can
pitch in on the retail end and provide 'off the shelf' services that are
locked down to a calibrated security profile. Then at the other end of the
scale very large enterprises with a designated CISO would call in the likes
of big consulting companies to deploy.

There would also be business opportunities for independent consultants. In
fact I am not sure that the retail model is going to be viable unless I can
tell an unprofitable customer that their needs are beyond what the flat
service fee model can support and they need to contact an independent
contractor.


This is of course something the industry has traditionally looked to NIST
to provide. But lets face it, that model is dead. It might be five years
before we can get people in a room together. Meanwhile we face real threats.

I see a number of questions here, one of which is what the appropriate
venue is. Another is what community should be involved. While this probably
needs to be an IETF or W3C activity it need not necessarily take place at
IETF meetings. A technical session lumped onto the front of Blackhat while
the admin type folk are in the training sessions might well be a better
venue. We probably want to follow up on Jim Getty's advice to connect to
the Linux Plumbers.

Security protocol designers are not the best folk for finding holes because
most of the holes are created by people doing stuff that is just so stupid
most of us would never think to do it.

But the work does need to be done somewhere and it needs to be an open,
unencumbered specification that draws on open standards.

-- 
Website: http://hallambaker.com/