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.
- Re: [dane] [TLS] Consensus Call on draft-ietf-tls… Viktor Dukhovni
- Re: [dane] [TLS] Consensus Call on draft-ietf-tls… John Gilmore
- Re: [dane] [TLS] Consensus Call on draft-ietf-tls… Viktor Dukhovni