Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
John Gilmore <gnu@toad.com> Thu, 12 April 2018 18:44 UTC
Return-Path: <gnu@toad.com>
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 D389012DA0D; Thu, 12 Apr 2018 11:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 cpa-gtMemx53; Thu, 12 Apr 2018 11:44:54 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83829126DED; Thu, 12 Apr 2018 11:44:54 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id w3CIiqah030722; Thu, 12 Apr 2018 11:44:52 -0700
Message-Id: <201804121844.w3CIiqah030722@new.toad.com>
To: TLS WG <tls@ietf.org>
cc: dane@ietf.org
In-reply-to: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org>
Comments: In-reply-to Viktor Dukhovni <ietf-dane@dukhovni.org> message dated "Thu, 12 Apr 2018 14:32:10 -0400."
Date: Thu, 12 Apr 2018 11:44:52 -0700
From: John Gilmore <gnu@toad.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/Xq4rJiyOe3y9p17OA0ltRPfA4r8>
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:44:56 -0000
> * 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. Viktor, I believe you have confused a "could" with a "mandate". The text of this RFC does not require future green field applications to mandate the use of this exension. It merely allows them to do so. None need ever do so. If any ever did, the future RFC could specify how servers which do not have validated TLSA records should handle the situation. Different future protocols might choose different ways to handle this (e.g. don't send the extension at all; or send a validated denial; or send some kind of flag saying that the server doesn't even have a validated denial because it isn't using DNS or because some domain on its path to the DNS root isn't doing DNSSEC or isn't using NSECx records). Please, let this RFC go, rather than requiring that this committee first insert into it a paper spec for what some future protocol should do, without even knowing what the future protocol is. John
- 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