[websec] An alternative approach to Security Policy
Phillip Hallam-Baker <hallam@gmail.com> Sat, 29 October 2011 16:47 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0EF21F8A67 for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 09:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level:
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjauWuwQ8xyx for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 09:47:02 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFE821F8A56 for <websec@ietf.org>; Sat, 29 Oct 2011 09:47:02 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so5455019ggn.31 for <websec@ietf.org>; Sat, 29 Oct 2011 09:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hEr4BGR24X7/vCHMLiNu5ir7cN/dTvrZ7WMbuXyHcm0=; b=Oa4IZ19RQTMMdDqXKBM74E4qFW31Iq0WfQM5Mom9hSnB39U2efbkM17WWvP6tT/LLD 4HyKin2JcEym3vjpz60kbSninGOGLYT4+wAOVJ4ihrym2IRwBHwk3l9oDQvS1GG46dGy nyz0AMNLBRuYxTcYTwL4mSvoT/p/cwXZpQYbE=
MIME-Version: 1.0
Received: by 10.182.226.33 with SMTP id rp1mr1584679obc.18.1319906821541; Sat, 29 Oct 2011 09:47:01 -0700 (PDT)
Received: by 10.182.42.99 with HTTP; Sat, 29 Oct 2011 09:47:01 -0700 (PDT)
Date: Sat, 29 Oct 2011 12:47:01 -0400
Message-ID: <CAMm+Lwj5Ssi_kksNop7Rvkt6g9iCni+rkh_kKEOF5vvq6G3qqA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: websec <websec@ietf.org>
Content-Type: multipart/alternative; boundary="f46d04446b553c0fd504b072c1b3"
Subject: [websec] An alternative approach to Security Policy
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Oct 2011 16:47:03 -0000
I submitted a version of this document last week but wanted to get some additional examples in using the new ni URI proposal before raising it on the list. This has now been done: http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt This is related to the 'Must use TLS', CA-Pinning and Strict Security work here but separates the security policy framework from the mode of distribution completely. We have been discussing security policy in IETF for quite some time. There seem to be two major technical issues that cause problems: 1) Choice of distribution mechanism 2) False positives due to badly administered systems I think I have found the solution to the first: It does not need to be a choice. There are advantages and disadvantages to each approach. DNS is the authoritative source for statements on the DNS but DNSSEC will not be ready for prime time for many, many years. HTTP headers are expedient but only give security after first contact. And DNS and HTTP headers both suffer from the problem of what to do when the attacker blocks access to the online confirmation mechanism completely. Meanwhile pushing out blocklists of 'hot sites' provides effective security but does not scale' Why choose? Each approach has advantages and disadvantages. So why not have a single language for policy statements that is strictly limited to restrictive statements that can be used to create statements that can be carried over any available transport? The false positives problem is a much bigger problem conceptually than in practice. In theory DKIM policy should be causing all sorts of legitimate mail to be refused delivery. What saves the system is the fact that DKIM statements are only one input into anti-spam filters and is only given the weight the data justifies. I see security policy being applied in HTTP and similar cases in the same way. Statements made by domain name owners will in the first instance serve as advice to companies that provide Internet safety products who will combine the data in the security policy statements with data from other sources to arrive at security decisions. Every attack has a human intelligence in there somewhere. Expecting to have effective security without any human intelligence in the defense is probably a mistake. The second approach to overcoming the 'false positives' issue is to observe that reporting a policy violation has much more value than blocking sites. Blocking sites only protects the users who have the security policy capability configured and enabled. Reporting a policy violation enables remediation that can protect the whole Internet community. Next Steps: This particular draft is intentionally targeted at use in a static interchange format. This would be used for defining local security policies (e.g. configuring all the web browsers at bigcorp.com to impose a particular policy for corporate servers) and to be used for emergency, data-driven response. Clearly this should converge with the Google Policy proposal for HTTP. I don't think that there are major differences and would be astonished if this was incompatible. But a general purpose format designed to support more protocols than HTTP will look a little different to one that is designed to tackle the problem at a higher level. -- Website: http://hallambaker.com/
- [websec] An alternative approach to Security Poliā¦ Phillip Hallam-Baker