Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 12 April 2018 18:32 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DC12DA0D; Thu, 12 Apr 2018 11:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aNzPjqshuLH5; Thu, 12 Apr 2018 11:32:13 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB08126DED; Thu, 12 Apr 2018 11:32:12 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id AA9DC7A3309; Thu, 12 Apr 2018 18:32:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com>
Date: Thu, 12 Apr 2018 14:32:10 -0400
Cc: dane@ietf.org
Reply-To: TLS WG <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/G-3GR_JsAHK_NwZVkC8GhM_paZw>
Subject: Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Apr 2018 18:32:15 -0000


> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <joe@salowey.net> wrote:
> 
> If the answer to 1) is no then please indicate if you think the working group should work on the document to include 
> 
> A) Recommendation of adding denial of existence proofs in the chain provided by the extension
> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
> C) Both

While I am a vocal supporter of (C), I'd like to take a moment to explain why AT LEAST (A)
is needed.

  * The present text requires (Section 3.4) that the server's response
    present a validated TLSA RRset:

	   The first RRset in the chain MUST contain the TLSA record set
           being presented

  * The present text (Section 8) says:

	   Green field applications that are designed to always employ this
           extension, could of course unconditionally mandate its use.

Therefore such "green field" applications (presumably some of the ones
ready to implement now) effectively mandate DNSSEC and TLSA records
at the server, NOT JUST support for the extension.

This needlessly limits the usability of such applications.  The
server domain cannot continue to support the extension and
interoperate with the client if it at some points decides to
stop publishing TLSA records or perhaps even stop using DNSSEC.

It makes a lot more sense for servers to be able to continue to
support the extension, but respond with denial of existence when
when the have no TLSA records or the zone is unsigned (no DS
RRs at some ancestor).  That way a server can communicate its
change of status to a client, which may *then* be willing to
accept alternative authentication (WebPKI, for example).

Option (A) does not change the wire formats, it just relaxes
the requirement to provide TLSA records, and would allow or
encourage the server to return whatever is the truth about
its TLSA records (presense, absence or unsigned zone).  The
client can then act accordingly.

Just (A) would of course still many clients in the dark about
when it might be safe to "mandate" the extension for particular
domains, and I'd be sad about that (if anyone cares :-), but it
is important to realize that not doing (A) is a significant
omission.

I'd like to encourage the authors and WG to amend the draft to
relax section 3.4 to allow (and encourage when applicable)
denial of existence replies.  This would better serve the
"green field" applications that would like to avail themselves
of this extension and require it of all servers, whether they
have DNSSEC and TLSA records or not.

-- 
	Viktor.