Re: [perpass] Security delivery model
Walter Pienciak <w.pienciak@ieee.org> Thu, 30 January 2014 16:49 UTC
Return-Path: <w.pienciak@ieee.org>
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 304D91A0433 for <perpass@ietfa.amsl.com>; Thu, 30 Jan 2014 08:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8dUydOD-ia34 for <perpass@ietfa.amsl.com>; Thu, 30 Jan 2014 08:49:34 -0800 (PST)
Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD51A0421 for <perpass@ietf.org>; Thu, 30 Jan 2014 08:49:34 -0800 (PST)
Received: by mail-oa0-f51.google.com with SMTP id h16so3872660oag.24 for <perpass@ietf.org>; Thu, 30 Jan 2014 08:49:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EHTgfP5xd6Ha2S17ATK3FCmHeR5POSc8LzhDz4vnz+g=; b=JunHujK0VAdkw+T67DECi/D06wVTKYJrfmjAijYG6xeC7ji58jfw0GosUpLficjMtw Wm/7Jcl4G0BK93fxk78t14Q4BaShA0t9akXeodFi6iOpDwuuqsnPhkg/gJXguYA7y8EL XzAoSb6uVA18QVkNIhX0XldRxU79w2x/p+Fn/P9B5fJkeDSTXCVfenWiQKdRuOpaLD/K 3M2UIU6v5GDAbNrrUvwSWykZV89Ce4lnbY5bWcG9n5a3+DxUNeZ43ijRLAz5BZKwImnA EeS6DVfeb2AE3ASYYLCg8sEIQsXgZ8f3o8jJrOqArqFju5uVDwzCUXM1kClb3qU5mXcN RBpA==
X-Gm-Message-State: ALoCoQlHTg80+AYrvv06iOMsXXroQ//NQReo5zQTt5XIf2zUqqWLTdyfL5rxI11fnnGUH2/j6s3k
X-Received: by 10.182.135.194 with SMTP id pu2mr12395703obb.38.1391100571322; Thu, 30 Jan 2014 08:49:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.172.133 with HTTP; Thu, 30 Jan 2014 08:49:11 -0800 (PST)
In-Reply-To: <CAMm+Lwh6mV+5XAOPGWk6aKqMOLQtOqUnFPFgpt6g6mgGst7y9w@mail.gmail.com>
References: <CAMm+Lwh6mV+5XAOPGWk6aKqMOLQtOqUnFPFgpt6g6mgGst7y9w@mail.gmail.com>
From: Walter Pienciak <w.pienciak@ieee.org>
Date: Thu, 30 Jan 2014 09:49:11 -0700
Message-ID: <CAHGGHooM9A_5t5BTrVTW29rFrRmQ10TaBOUCE22M7qMiH9h5cw@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: multipart/alternative; boundary="089e0122a6c066a4bb04f132d753"
Cc: perpass <perpass@ietf.org>
Subject: Re: [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: Thu, 30 Jan 2014 16:49:37 -0000
"Best practices" implementation guides have real value. We've seen them developed for specific application/platform deployment, and other organizations such as USENIX and SANS have shown there is a demand for them by the folks in the trenches. I agree that standards/protocols guides are much more uncommon; to what extent that is due to "out of scope" determination by the employers of standards developers is an open question. But to reiterate: "best practices" guides with a security focus would be a valuable addition to the many efforts underway already. Inexpertly administrated resources will always be an issue, no matter the efforts ranging from random number generation through hardening of transport and data exchange. Walter Walter Pienciak Senior Manager, Technology Community, IEEE Standards Association w.pienciak@ieee.org +1 303 527 0934 On Wed, Jan 29, 2014 at 10:11 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote: > 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/ > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > >
- [perpass] Security delivery model Phillip Hallam-Baker
- Re: [perpass] Security delivery model Walter Pienciak
- Re: [perpass] Security delivery model Orit Levin (LCA)
- Re: [perpass] Security delivery model Phillip Hallam-Baker
- Re: [perpass] Security delivery model Orit Levin (LCA)