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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 08 April 2015 23:40 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 6D6D41B359B for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 16:40:38 -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 7Paf8my9X1H3 for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 16:40:37 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 BC9491B3497 for <websec@ietf.org>; Wed, 8 Apr 2015 16:40:36 -0700 (PDT)
Received: by labbd9 with SMTP id bd9so66214780lab.2 for <websec@ietf.org>; Wed, 08 Apr 2015 16:40:35 -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=1PMaXeJYLq6RVQfxW+jih4g8OWdvnxN2VnuYbGdhPyE=; b=k7OP6O+oc2xAQ/Gv6dQi2Y3g+87TdXTOLdYz3GmW9Vmxtt5jRwjDBGbgMqPLLxwklU OCKknA2uYTfnxC1+9THCvTnGe7RovSJf3zqCnrTP9viLfuShF4jCOLpJDpTqPcqGfJV7 GKSS3TV/eQ1DjkZhK0VXzZjrcR3JpmDBu9jYnJ2ISOWg6cBw88cfWaL/OWyDIGsM40fp 7J7PSgUSSAN0hYUGpS1Y65sx4yMZwFE94EvQT2hSDBlQ2JOa45afF6pqOSu0OF/yITcF Z4XDcjJ9biYbA5+4Nxeyn7KKTihUTI267v7o2bODq3YevmKmRBu3kjC27sie+l5Xqs5q u9/Q==
MIME-Version: 1.0
X-Received: by 10.152.120.8 with SMTP id ky8mr1815040lab.118.1428536435316; Wed, 08 Apr 2015 16:40:35 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 16:40:35 -0700 (PDT)
In-Reply-To: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com>
References: <CAMm+Lwjc_7CWPLgTSy=pX81+NXUguOLZmv0t2YgxTbXotQqZsg@mail.gmail.com> <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com>
Date: Wed, 08 Apr 2015 19:40:35 -0400
X-Google-Sender-Auth: Fo08cGKE3NWIcaEnQg4VVLI20jU
Message-ID: <CAMm+Lwhz1bmE61sinm-faHN7L6NdPA9nH=H4fCdkMtZGPR7m5A@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/_UH3Z9W8jU77iJIU05BqHJulKDc>
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: Wed, 08 Apr 2015 23:40:38 -0000

On Wed, Apr 8, 2015 at 6:35 PM, Ryan Sleevi <ryan-ietfhasmat@sleevi.com> wrote:
> On Wed, April 8, 2015 3:00 pm, Phillip Hallam-Baker wrote:
>>  http://tools.ietf.org/html/draft-hallambaker-webseccaa-00
>>
>>  It is a pretty straightforward proposal:
>>
>>  * Use the CAA record with either the hsts or hpkp tag
>>  * Put the same text you would have put into the CAA record value field
>>
>>  There are a few differences in interpretation. All we are trying to do
>>  here is to help people to close the 'secure after first use' hole, not
>>  replace.
>>
>>  Given that we have quite a bit of use of HSTS headers, providing a
>>  mechanism for publishing this in the DNS looks like being the obvious
>>  approach.
>
> I believe it was so obvious that the IETF has already beat you to the
> punch - RFC 6698.
>
> If it is, as you claim, to close the "secure after first use" hole - which
> is the first time I've heard it called that, versus the "trust on first
> use hole", since "secure after first use" isn't so much a "hole" as a
> "nice thing to have" - then it requires secure DNS, which is back to the
> DNSSEC problem, and if you have DNSSEC and the ability to query arbitrary
> records on the client, well, you might as well just use DANE.

Who said anything about DNSSEC being required?

DANE has totally different syntax and semantics. Adding this mechanism
is very straightforward, just post the same parameters that would be
presented in the HTTP headers in DNS. The mechanism can even work both
ways, a server can use this for discovery.

People in WebSec and DANE decided on different approaches. I see no
reason to foist the inability of the two groups to agree on one
approach onto users of the specs and certainly no reason to hobble
WebSec which is now widely used to make space for an experimental
protocol that has failed.

> Of course, you might mean this as a "How do I discover support" (e.g. for
> building preloaded lists), in which case, that problem already has a
> myriad of solutions.

Having more than one solution for a problem is usually a good reason
to pick one.