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