[dane] draft-cem-dane-assertion

Carl Mehner <c@cem.me> Thu, 26 March 2015 18:33 UTC

Return-Path: <c@cem.me>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BF1B2A1D for <dane@ietfa.amsl.com>; Thu, 26 Mar 2015 11:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.168
X-Spam-Level:
X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 1CLy5Y0Vdhxe for <dane@ietfa.amsl.com>; Thu, 26 Mar 2015 11:33:28 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 B66781A92EA for <dane@ietf.org>; Thu, 26 Mar 2015 11:33:06 -0700 (PDT)
Received: by lbcgn8 with SMTP id gn8so47412256lbc.2 for <dane@ietf.org>; Thu, 26 Mar 2015 11:33:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:date:message-id:subject:from:to:content-type; bh=l0pmU/j9BzgbmJ5WsXH1fJYz0L+dpWafQdj3XpexD0M=; b=ahlvof3REIbyOjy8Wv4YOgszZHS0CjzPjKphzKOEbIyrFi7PJ49pySVNijfRYKoem6 0AXyjGu8HHCdCSLrRD/T+j7p+1qFwkqQgvHwtmW5EpNQL1WPGGFyAWAGvudY0bJE7Tih m3Kngja/BECDWLLeT83DE8RPd92OLz2kg87U4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=l0pmU/j9BzgbmJ5WsXH1fJYz0L+dpWafQdj3XpexD0M=; b=X3U13h0dkyIN+bcGfh47tQSwNATzwrvc0zmNmJwpTVILpbc4aX/LolvIzdUEIfzNb/ L6c+5ouZ2x1xSUPgb63ZIqMy44JymdB1Evm7l+Ddps3R4X+MjvY05L0VD08kRCoTPXK3 bxvv5Eil5ijQKG0GCsZlw48FhtyggVa2Q2gNPNrwJVDWbWFcSi9q4hVoQNtkp9XDCaRX gWXdcbBCQDNjqY31GFKAaWyCQHgH9GgMdZ393HjUd0xyBwWSeYTy+AYNP53ejHO2egdp 2kjKw7QD25b/6h2jx9eroLanR/doWwDpXILU5L8Azm5sipEiQyJMoLeI9fSeB1CWTYIf mJ8w==
X-Gm-Message-State: ALoCoQmuf7Nzveu0BQQFgL+en8g+HqIUj1oRj30GIQuxcdwuTxA4itDciFlmP8nfAcDGWVmMn6iF
MIME-Version: 1.0
X-Received: by 10.152.243.4 with SMTP id wu4mr14583939lac.33.1427394785221; Thu, 26 Mar 2015 11:33:05 -0700 (PDT)
Received: by 10.25.210.6 with HTTP; Thu, 26 Mar 2015 11:33:05 -0700 (PDT)
X-Originating-IP: [2001:67c:370:176:e07d:6c2:4d32:5347]
Date: Thu, 26 Mar 2015 13:33:05 -0500
Message-ID: <CAEa9xj72p=vNJ2kLcBCb0nW+UMT4jiVJk5ym50AojfqvSFTftw@mail.gmail.com>
From: Carl Mehner <c@cem.me>
To: dane@ietf.org
Content-Type: multipart/alternative; boundary="001a1134282c20b4460512353fc8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/6Bac3f9G7vUrBWXSQn1PY-1y3QA>
X-Mailman-Approved-At: Thu, 26 Mar 2015 11:38:53 -0700
Subject: [dane] draft-cem-dane-assertion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:37:30 -0000

Hello DANE Working Group,

At least one browser (Google Chrome) has experimented with DANE, but
subsequently removed it "due to lack of use"[0]. There is also a Firefox
plugin that will validate DANE records[1]. I submitted a draft to address
this, in order to allow sites that want to use DANE the ability to
explicitly state their intent and allow UAs to only expend resources on
domains where DANE is requested.

http://datatracker.ietf.org/doc/draft-cem-dane-assertion/

I believe, if there is interest, that this could fit part of the problem
statement of the working group charter: to "create documents that describe
how protocol entities can discover and validate these bindings in the
execution of specific applications"[2]

Those familiar with HSTS[3] and HPKP[4] ought to find many of the
directives familiar, there is however a new concept, a 'require' directive.
The reason I included this directive was because the way DANE works; if you
receive a certificate that is valid via PKIX and do not receive any DANE
records, the connection will continue. By using the 'require' directive,
the host operator forces the connection to be validated using both PKIX and
DANE or solely by using DANE every time.

I have also written up some additional thoughts on the subject here: [5]




Carl Mehner

[0] https://www.imperialviolet.org/2011/06/16/dnssecchrome.html

[1] https://www.dnssec-validator.cz

[2] https://datatracker.ietf.org/wg/dane/charter
[3] https://tools.ietf.org/html/rfc6797
[4] https://tools.ietf.org/html/draft-ietf-websec-key-pinning
[5] https://www.cem.me/20141203-hdva.html