[pkix] TLS Security Policy Draft Update

Phillip Hallam-Baker <hallam@gmail.com> Sat, 20 October 2012 01:08 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DB321F84BA; Fri, 19 Oct 2012 18:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.923
X-Spam-Level:
X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBN6mimEwSP4; Fri, 19 Oct 2012 18:08:28 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B823621F8464; Fri, 19 Oct 2012 18:08:28 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so1174962obq.31 for <multiple recipients>; Fri, 19 Oct 2012 18:08:28 -0700 (PDT)
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=U9A+VHln0SE9UP4Gk5unxDEe1GhVgZxjdICBZ6m9xRM=; b=uTN5k0KLizoRVuV9+xY8RqcRhakFi+t+z07zf8feDsvPe7EC2FgmKXoeVufMd9b26b NoUL+u3MdqryUkceqRk7/oRwpCPwE50l0vI2Be5mTc+zensnXaBMk5Sjn1xAtbSOplzP 9AkqYkdXdoYxLfKmcAeSlyAbz6u0FMHV3qbMIFyL65YQZHrIlyB40sKQMjHrMNWVn2Tu XdjxVTTIkdpnodzsOm7C0uW/GwtBmwyLSTLWhNZ9YW7PLTc40m1AOLiCP2bcNFE7u44a 3numL4nT75Pa0IO+qJN9A+T74jzxMjef5e05qXEQ70k9XBJ7u/pZbtCcuNJIw43FseQu otHQ==
MIME-Version: 1.0
Received: by 10.182.145.35 with SMTP id sr3mr1845874obb.98.1350695308228; Fri, 19 Oct 2012 18:08:28 -0700 (PDT)
Received: by 10.76.27.103 with HTTP; Fri, 19 Oct 2012 18:08:28 -0700 (PDT)
Date: Fri, 19 Oct 2012 21:08:28 -0400
Message-ID: <CAMm+LwhzE02by-HqtDo5VPBeA9eMgrZiCwn_0vLcSqar=+bGdQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: pkix@ietf.org, tls@ietf.org
Content-Type: multipart/alternative; boundary="f46d044630780bf9b904cc734225"
Subject: [pkix] TLS Security Policy Draft Update
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Oct 2012 01:08:32 -0000

http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-02.txt

I am not proposing this as a PKIX WG item as the plan is to close the
group. It may be of interest to PKIX and TLS members however.

This is a slight generalization of the 'MUST STAPLE' certificate and CSR
extension. Specifically the specification permits two types of security
policy to be specified in an X.509v3 cert.

* Minimum TLS Version
* 'Must Staple OCSP token'

The design is slightly more general so that it can co-exist with TLS
extensions that are similar to OCSP token stapling. For example Certificate
Transparency info.


The big advantage to using this is that it allows a client to check
revocation status and to immediately fail if the OCSP token is not provided
as it should be. At present most clients will only fail if they see an
invalid OCSP token, if the token is not returned, they consider it valid.
To do otherwise opens the client to a DoS attack bu DDoS-ing the OCSP
servers.

Note that the TLS protocol handshake provides protection against most forms
of downgrade attack and most importantly cipher suite downgrade (for later
versions at least). So it is not necessary to wire them into the cert. In
fact the only statements that should be wired into the cert are statements
that the server knows that it can ensure compliance with.


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