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

"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Wed, 08 April 2015 22:35 UTC

Return-Path: <ryan-ietfhasmat@sleevi.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 C460F1A909F for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 15:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 nCvub3FcGmzy for <websec@ietfa.amsl.com>; Wed, 8 Apr 2015 15:35:09 -0700 (PDT)
Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCC1A909D for <websec@ietf.org>; Wed, 8 Apr 2015 15:35:09 -0700 (PDT)
Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 8754520058DAC; Wed, 8 Apr 2015 15:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=nNWXdzHZ420wm/ArWxSp4R9c3w8=; b=WztvxfU+ATo+DDCE0 XMf7gtmCatiY1NQGCIXdGf3VmPeg4YjRS8AwyrA6CI35OEZrIwy9gwP8YnPQX2Df vTyTItaVz+N0/2Ww69QXZkgd8WFd5mA0KFzcDpmWxe/WrlSRmEy4ovSzkyw3KrQc IeiZ7Yx+e7SSd94r2QJNgwORbk=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 4C39820058DAB; Wed, 8 Apr 2015 15:35:09 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 8 Apr 2015 15:35:10 -0700
Message-ID: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com>
In-Reply-To: <CAMm+Lwjc_7CWPLgTSy=pX81+NXUguOLZmv0t2YgxTbXotQqZsg@mail.gmail.com>
References: <CAMm+Lwjc_7CWPLgTSy=pX81+NXUguOLZmv0t2YgxTbXotQqZsg@mail.gmail.com>
Date: Wed, 08 Apr 2015 15:35:10 -0700
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/HjkGxesEgxqpo999lBhD2vHFcGI>
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: ryan-ietfhasmat@sleevi.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:35:10 -0000

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.

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.

In either event, I see no reason to standardize Yet Another Way to do the
same thing.