From nobody Wed Apr 4 14:50:08 2018 Return-Path: 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 39F83120454 for ; Wed, 4 Apr 2018 14:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 syhs_7MbARFc for ; Wed, 4 Apr 2018 14:50:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23417126BF0 for ; Wed, 4 Apr 2018 14:50:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Gfkx0RYTz37L for ; Wed, 4 Apr 2018 23:50:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1522878601; bh=R6qmkCZhFo16Mh1FAjl/ueVW5uawTkHuwS+ojFp2uXQ=; h=Date:From:To:Subject; b=MGc04+tPyBcnGQnh5EZhywhY/UjRWJLbB0PWR9VQwmkU5GSAZ69kpQ5H9VRSS5aVr wz0s57xrw2QI3ihq4n5faK7HRofeOpXRAapVXUKxx57dDE9QwfR1xNxoXnu8yySxow 4VW4VCeNCUEJ3dZ1Kwd15xtNYBptiwL0s5y6GP7k= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vxSVs1eOepEc for ; Wed, 4 Apr 2018 23:49:56 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 4 Apr 2018 23:49:55 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0C043C9A; Wed, 4 Apr 2018 17:49:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0C043C9A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 058644095AB1 for ; Wed, 4 Apr 2018 17:49:55 -0400 (EDT) Date: Wed, 4 Apr 2018 17:49:54 -0400 (EDT) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============5004947575776181399==" Archived-At: Subject: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:50:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============5004947575776181399== Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT FYI, Paul ---------- Forwarded message ---------- Date: Wed, 4 Apr 2018 13:50:15 From: Joseph Salowey To: "" Subject: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension Hi Folks, Some objections were raised late during the review of the draft-ietf-tls-dnssec-chain-extension. The question before the working group is either to publish the document as is or to bring the document back into the working group to address the following issues: - Recommendation of adding denial of existence proofs in the chain provided by the extension - Adding signaling to require the use of this extension for a period of time (Pinning with TTL) This is a consensus call on how to progress this document.  Please answer the following questions: 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work? 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 This call will be open until April 18, 2018. Thanks, Joe --===============5004947575776181399== Content-Type: text/plain; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============5004947575776181399==-- From nobody Wed Apr 4 23:43:54 2018 Return-Path: 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 0117712426E for ; Wed, 4 Apr 2018 23:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7EyOsGJOZwXu for ; Wed, 4 Apr 2018 23:43:50 -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 D3BFB120725 for ; Wed, 4 Apr 2018 23:43:50 -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 w356hjah006492; Wed, 4 Apr 2018 23:43:45 -0700 Message-Id: <201804050643.w356hjah006492@new.toad.com> To: Paul Wouters cc: dane WG list In-reply-to: References: Comments: In-reply-to Paul Wouters message dated "Wed, 04 Apr 2018 17:49:54 -0400." Date: Wed, 04 Apr 2018 23:43:45 -0700 From: John Gilmore Archived-At: Subject: Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:43:52 -0000 > FYI, Looks from this distance like the usual obstruction, i.e. "just give us a few more years of CA revenues, by delaying this standard further by demanding to add stuff that could easily have been added by a followup RFC". John From nobody Tue Apr 10 08:14:12 2018 Return-Path: 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 C5B1612D95E for ; Tue, 10 Apr 2018 08:14:10 -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 s2W-VocQierR for ; Tue, 10 Apr 2018 08:14:09 -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 F311412D95D for ; Tue, 10 Apr 2018 08:14:08 -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 C842B7A3309; Tue, 10 Apr 2018 15:14:07 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 10 Apr 2018 11:14:06 -0400 Message-Id: <5DB72CA0-4AF0-4A23-A19F-9354416272C2@dukhovni.org> Cc: dane-users@sys4.de To: dane@ietf.org X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 15:14:11 -0000 Please read the TLS WG consensus call thread on the DNSSEC chain = extension, and comment for either publish as-is or the changes I and others are = advocating (which IMHO are needed for plausible utility in the web space). Thread: = https://www.ietf.org/mail-archive/web/tls/current/threads.html#25929 Rationale for change: https://www.ietf.org/mail-archive/web/tls/current/msg25936.html Why proposed pinning TTL is analogous to STS and not HPKP: https://www.ietf.org/mail-archive/web/tls/current/msg25956.html --=20 Viktor. From nobody Thu Apr 12 11:32:21 2018 Return-Path: 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 In-Reply-To: Date: Thu, 12 Apr 2018 14:32:10 -0400 Cc: dane@ietf.org Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> References: To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 18:32:15 -0000 > On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: >=20 > If the answer to 1) is no then please indicate if you think the = working group should work on the document to include=20 >=20 > 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. --=20 Viktor. From nobody Thu Apr 12 11:44:57 2018 Return-Path: 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 cc: dane@ietf.org In-reply-to: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> References: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 12 Apr 2018 14:32:10 -0400." Date: Thu, 12 Apr 2018 11:44:52 -0700 From: John Gilmore Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Apr 12 12:05:18 2018 Return-Path: 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 5F82512D9FE; Thu, 12 Apr 2018 12:05:12 -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 oBwMDAWR-2il; Thu, 12 Apr 2018 12:05:10 -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 D941212D864; Thu, 12 Apr 2018 12:05:10 -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 C40A47A3309; Thu, 12 Apr 2018 19:05:09 +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 In-Reply-To: <201804121844.w3CIiqah030722@new.toad.com> Date: Thu, 12 Apr 2018 15:05:09 -0400 Cc: dane@ietf.org Reply-To: TLS WG Content-Transfer-Encoding: 7bit Message-Id: <051D83E8-B6C0-4755-B267-291E7D97D516@dukhovni.org> References: <87FDEE87-EE58-4886-824C-0DE1906B7784@dukhovni.org> <201804121844.w3CIiqah030722@new.toad.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 19:05:12 -0000 > On Apr 12, 2018, at 2:44 PM, John Gilmore wrote: > > Viktor, I believe you have confused a "could" with a "mandate". As to this point, I'm not now and have never been confused about that. The present draft, as explained upthread, perhaps in too many ways and in too many words, offers no value to applications that don't mandate the use of the extension, if the application also excepts WebPKI, and the extension is optional, then a cost/benefit analysis shows that use of the DANE extension offers only complexity and no security benefit. Opportunistic use-cases of the present draft won't get deployed, they make no sense. -- Viktor.