IETF Logo Mail Archive

Re: [websec] DNS publication of HSTS and PKP header data using CAA

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 09 April 2015 01:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE41ACD9F for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 18:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 w1zOBH8qAJ1m for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 18:27:24 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3137A1ACD9C for <websec@ietf.org>; Wed, 8 Apr 2015 18:27:24 -0700 (PDT)
Received: by lbbqq2 with SMTP id qq2so71477343lbb.3 for <websec@ietf.org>; Wed, 08 Apr 2015 18:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AtrtRPEXHpqx2ErC76NMv14OuhRsgR7RHR6nm9sZSZk=; b=Wn9BEVl27EoIWeFom1k6JsHbvUJIouc6HQddG0YGUDisM3vzm+kl7LbIrORoSSv+C9 wBLM1DGamsYH86rSoNjKY0WRYC4nb1vmlmqsNUVRRf4JBOT6yA2BsSe+rq5oaNirq2FC aFtaK7qM0JKvm+IXy+8FgC3djAVx0SizjLBIuPd6bGtDBW3PR/pLawiOfVU7sH+AVG6W RxgGt6+weAxE5sy+LO8e3e2pO4hyTDmEZPezwt75XUx79AkT/y0B1+50QV4Bcs3+I2fb sVAk/gdVgIEN4X7Py+Tt0vZmUlk5yxp+nbwUZ2dTL3NotOENQFCpw3scPjp00kHSn9hr hYcw==
MIME-Version: 1.0
X-Received: by 10.152.88.1 with SMTP id bc1mr2365346lab.79.1428542842731; Wed, 08 Apr 2015 18:27:22 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 18:27:22 -0700 (PDT)
In-Reply-To: <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com>
References: <CAMm+Lwjc_7CWPLgTSy=pX81+NXUguOLZmv0t2YgxTbXotQqZsg@mail.gmail.com> <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> <CAMm+Lwhz1bmE61sinm-faHN7L6NdPA9nH=H4fCdkMtZGPR7m5A@mail.gmail.com> <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com>
Date: Wed, 8 Apr 2015 21:27:22 -0400
X-Google-Sender-Auth: BcXA524QI_tAWnn3g6339FB4pJ4
Message-ID: <CAMm+LwjQE-t=DQRWc95gXYuo-1oKotbKuHzadc5Od+WG+M9_nw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: ryan-ietfhasmat@sleevi.com
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/OJod9dsop-a0wSoB2F5pxprQ_LE>
Cc: websec <websec@ietf.org>
Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 09 Apr 2015 01:27:25 -0000

On Wed, Apr 8, 2015 at 8:41 PM, Ryan Sleevi <ryan-ietfhasmat@sleevi.com> wrote:
> On Wed, April 8, 2015 4:40 pm, Phillip Hallam-Baker wrote:
>>  Who said anything about DNSSEC being required?
>
> If it isn't, then it's not equivalent.
>
> HSTS requires an error free connection - in part to ensure the policy is
> securely delivered.

No it is required to know that the policy is consistent. Which you
certainly want to do if a security policy is going to be cached for 6
months.

The security considerations of security policy mechanisms are all
about not shooting yourself in the foot. That is why I propose to not
consider the record valid for any longer than its DNS time to live.


> HPKP requires an error free connection that is consistent with the policy
> expressed - in part to ensure the policy is securely delivered and
> correctly formed.
>
> If you don't require secure delivery of that, then you're not developing a
> secure solution.

I am not delivering a perfectly secure solution but neither is DANE.
All I am looking to do is to improve on the status quo with as little
extra work as possible.

If DNSSEC is ever deployed AND it becomes visible to clients then it
could be relevant to this spec. But right now DNSSEC is not a viable
mechanism for authenticating DNS RRs at the client. There are other
mechanisms that work just fine for the client-resolver link, including
our own proprietary protocols and the proposal we have made to DPRIV.

v2.8.7 | Report a Bug | By Email