IETF Logo Mail Archive

Re: [TLS] [dane] 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: tls@ietfa.amsl.com
Delivered-To: tls@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/tls/-GbTGjF04yncnaAvXgsayWYwojo>
Subject: Re: [TLS] [dane] Consensus Call on draft-ietf-tls-dnssec-chain-extension [AT LEAST (A)]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-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

v2.14.0 | Report a Bug | By Email