[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/