Re: [websec] DNS publication of HSTS and PKP header data using CAA
Jeffrey Walton <noloader@gmail.com> Wed, 08 April 2015 22:48 UTC
Return-Path: <noloader@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 5F9AB1A90DE for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 15:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zxLpkZk258dl for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 15:48:14 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 EEF5C1A90DD for <websec@ietf.org>; Wed, 8 Apr 2015 15:48:13 -0700 (PDT)
Received: by iggg4 with SMTP id g4so52839280igg.0 for <websec@ietf.org>; Wed, 08 Apr 2015 15:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ekpkcQS8AeUs//JRixOOwH8eJjPlOxkW/ex8CC3qWO0=; b=y7piXs/dACjExlbBDZwxI2/axE8M1gkNeu/CZTzU5M+w8KvXNjyLHOvF5FXOQ9NpcB jqFxdZAiWyuQ+QDxnOntae+/99VfT4S4Bi/f/n2TFAc+vArd3t8KfVd9JSVGApurFJPK CZFcp9j2BexA8aPPhEMmmkEWfjcYCDEsr2oH7zg7cZYsQKkBp0l4wI3ECP8/GnU+ZKVD W+mpQvZBET98bFGvkyt3mVScdBTYakuxPIws4dc7t6UXd7jW6YKx2W2gJQk74URrfBbc 1k7QUDbHw/nWzTYAZYuKBqst9NT1fFwvvlU3gd+ciw+MKNZqQk0dmxBztz9CaaVO8hFW n6pA==
MIME-Version: 1.0
X-Received: by 10.107.19.2 with SMTP id b2mr43211845ioj.9.1428533293463; Wed, 08 Apr 2015 15:48:13 -0700 (PDT)
Received: by 10.36.77.15 with HTTP; Wed, 8 Apr 2015 15:48:13 -0700 (PDT)
In-Reply-To: <10738ee1c985e6bd43ec26ae10cb5a16.squirrel@webmail.dreamhost.com>
References: <CAMm+Lwjc_7CWPLgTSy=pX81+NXUguOLZmv0t2YgxTbXotQqZsg@mail.gmail.com> <CAH8yC8=5BYCi9hRtUo8+dwFWgPanooQvVxwr1d0GPGUse2eJ+Q@mail.gmail.com> <10738ee1c985e6bd43ec26ae10cb5a16.squirrel@webmail.dreamhost.com>
Date: Wed, 08 Apr 2015 18:48:13 -0400
Message-ID: <CAH8yC8kDrUVLfxTfg+a_90uTYRrv4rGfKrL9DvMwaB8SqxZ96A@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: ryan-ietfhasmat@sleevi.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/uSWvMiLnvrMbNfi8lhCCb1v5EJQ>
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
Reply-To: noloader@gmail.com
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: Wed, 08 Apr 2015 22:48:15 -0000
>> In the case of installable apps, the information like HSTS and HPKP >> can be placed in the app manifest. Even better, standards like HPKP >> won't need to provide the override because its confused about which >> pinset is the right one to use. Because the HSTS and HPKP information >> was in the manifest during delivery, there will be no question about >> which policy or key to use. > > By "the override", I presume you mean "the ability for a duly authorized > user with administrative access over the machine they own to set policies > for the applications they install", which you've objected to in the past, > in which case, there's no reason at all to assume that the respect for a > user's wishes over that of the developer's would somehow be inverted. How did I know you would object to an effective security measure that minimized the ability to intercept communications :) I'd also cite the same document and claim that when the user installed the application with the preloaded and *known secure* settings, they would not want them arbitrarily overridden because a standard was confused about which pinset was the right one to use. As you succinctly said, its a Priorities of Constituencies. Jeff
- Re: [websec] DNS publication of HSTS and PKP head… Jeffrey Walton
- [websec] DNS publication of HSTS and PKP header d… Phillip Hallam-Baker
- Re: [websec] DNS publication of HSTS and PKP head… Phillip Hallam-Baker
- Re: [websec] DNS publication of HSTS and PKP head… Ryan Sleevi
- Re: [websec] DNS publication of HSTS and PKP head… Ryan Sleevi
- Re: [websec] DNS publication of HSTS and PKP head… Martin J. Dürst
- Re: [websec] DNS publication of HSTS and PKP head… Phillip Hallam-Baker
- Re: [websec] DNS publication of HSTS and PKP head… Joseph Bonneau
- Re: [websec] DNS publication of HSTS and PKP head… Ryan Sleevi
- Re: [websec] DNS publication of HSTS and PKP head… Jeffrey Walton
- Re: [websec] DNS publication of HSTS and PKP head… Ryan Sleevi
- Re: [websec] DNS publication of HSTS and PKP head… Phillip Hallam-Baker
- Re: [websec] DNS publication of HSTS and PKP head… Ryan Sleevi
- Re: [websec] DNS publication of HSTS and PKP head… Phillip Hallam-Baker
- Re: [websec] DNS publication of HSTS and PKP head… ngnoulaye
- Re: [websec] DNS publication of HSTS and PKP head… Jeffrey Walton