From nobody Tue May 2 12:07:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB36129C6F for ; Tue, 2 May 2017 12:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-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 vJpMs0IJsecp for ; Tue, 2 May 2017 12:07:34 -0700 (PDT) Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (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 5FD4012EACE for ; Tue, 2 May 2017 12:03:22 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id v42J3KJg116677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 May 2017 15:03:20 -0400 Received: (qmail 5172 invoked by uid 0); 2 May 2017 19:03:20 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 2 May 2017 19:03:19 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 02 May 2017 15:03:15 -0400 From: Lee Howard To: Philip Homburg , Message-ID: Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:07:38 -0000 On 3/16/17, 7:02 AM, "Philip Homburg" wrote: >>1. I do not think there is consensus that having PTRs is or is not a best >>practice, so emphasizing the lack of consensus lets us move on to what an >>ISP can do, if they care to do anything. >>The first paragraph has been overhauled to say "While the need for a PTR >>record and for it to match >> is debatable as a best practice, some network services [see Section 3] >>still do rely on PTR lookups, and some check the source address of >>incoming connections and verify that the PTR and A records match before >>providing service.=3DB2 > >Is it possible to have a separate section about e-mail? > >In my experience, without reverse DNS it is essentially impossible to have >mail delivered to the internet at large. Yes. > >So where most uses of PTR records are a nice to have to can be decided >locally, >for e-mail it is other parties on the internet that force the use of PTR >records. > >At the same time, if someone is capable of operating a mail server then >operating an auth. DNS server is not really out of line. I agree that people reject mail if there=B9s no PTR; I think this is used in fighting spam, based on an inference that if there=B9s no PTR, you=B9re a spam bot rather than a legitimate mail server. The first case listed in 4. Considerations and Recommendations says There are six common uses for PTR lookups: Rejecting mail: A PTR with a certain string or missing may indicate "This host is not a mail server," which may be useful for rejecting probable spam. The absence of a PTR leads to the desired behavior. The draft currently doesn't say the opposite, which is =B3A mail server is therefore expected to have a PTR.=B2 It does say, in 5.1 Using Reverse DNS for Security: For instance, most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match. If they match, but information higher in the stack (for instance, mail source) is inconsistent, the packet is questionable. These records may be easily forged though, unless DNSsec or other measures are taken. The string of inferences is questionable, and may become unneeded if other means for evaluating trustworthiness (such as positive reputations) become predominant in IPv6. [continued below] > >So I'd like some text that describes the importance of reverse DNS for >e-mail >and then basically says that if an ISP allows customers to handle their >own outgoing e-mail then that ISP SHOULD provide customers with a way of >setting up PTR records for those mail servers, even if it is just >delegating >part of the name space by setting up NS records. I=B9ve quoted much of that text above. Given that the document is about residential ISPs, and given the above, plus the guidance that the information should match if it=B9s possible to reconcile them, does this document need an affirmative statement about mail servers?=20 If so, I think I would revise this text: Rejecting mail: A PTR with a certain string or missing may indicate "This host is not a mail server," which may be useful for rejecting probable spam. The absence of a PTR leads to the desired behavior. to say: Evaluating mail servers: no PTR, or a PTR with a certain string, may indicate "This host is not a mail server," which may be useful for rejecting probable spam. Therefore, legimitate mail servers are expected to have a PTR matching forward. But I do think this recommendation is covered under: when a host has a static address and name, AAAA and PTR records should exist and match. > >Do you have a reference for the following statement >Serving ads: "This host is probably in town.province." An ISP that does >not >provide PTR records might affect somebody else's geolocation. No. Given the privacy considerations, I=B9ve changed the example from =B3x.town.province=B2 to =B3string.region=B2 and added privacy considerations. So I need to fix this text anyway. > >Extracting geo information from reverse DNS is very hard. As far as I >know, >geo location services for IPv4 mostly rely on other sources. That=B9s probably true. Given that I need to update it to match what it says in the Privacy Considerations section and the examples, should I just remove mention of geolocation? Or should I tweak it to match the rest, and add text saying, =B3But reverse DNS is not a great source for geolocation information=B2? >=20 > >The following is not clear to me: >Some ISP DNS administrators may choose to provide only a NXDomain >response to PTR queries for subscriber addresses. [...] >Providing a negative response in response to PTR >queries does not satisfy the expectation in [RFC1912] for entries to >match. Users of services which are dependent on a successful lookup >will have a poor experience. For instance, some web services and SSH >connections wait for a DNS response, even NXDOMAIN, before >responding. > >Why would a NXDOMAIN response to a PTR query have a negative impact >on performance? If any, it would be faster because it saves a forward >lookup. > >Maybe you want to say that a PTR lookup has to result in a quick reply, >even it is an NXDOMAIN. A delegation to a name server that does not >respond >will cause a delay in applications that wait for the reverse DNS lookup to >complete. Good note. I think I revised this paragraph several times, and it didn=B9t keep its integrity. Old sentence: Users of services which are dependent on a successful lookup will have a poor experience. Proposed new sentence: Users of services which are dependent on a successful lookup will have a poor experience if they have to wait for a timeout; an NXDomain response is faster. Old sentence: For best user experience, then, it is important to return a response, rather than have a lame delegation. Proposed new sentence: For best user experience, then, it is important to return a response, including NXDomain, rather than have a lame delegation. Resulting new paragraph (unformatted): Some ISP DNS administrators may choose to provide only a NXDomain response to PTR queries for subscriber addresses. In some ways, this is the most accurate response, since no name information is known about the host. Providing a negative response in response to PTR queries does not satisfy the expectation in [RFC1912 ] for entries to match. Users of services which are dependent on a successful lookup will have a poor experience if they have to wait for a timeout; an NXDomain response is faster. For instance, some web services and SSH connections wait for a DNS response, even NXDOMAIN, before responding. For best user experience, then, it is important to return a response, including NXDomain, rather than have a lame delegation. On the other hand, external mail servers are likely to reject connections, which might be an advantage in fighting spam. DNS administrators should consider the uses for reverse DNS records and the number of services affecting the number of users when evaluating this option. > >I don't see a discussion about DNAME. Maybe that's worth adding? Is it? There are several places where the document talks about delegating authority for a prefix, but it never says how. Now that you mention it, I see how it=B9s relevant, but I=B9m on the fence about whether there=B9s anything important to say that hasn=B9t already been said in better documents. Lee From nobody Tue May 2 12:18:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D378129B0F for ; Tue, 2 May 2017 12:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 v7ymfb8GfNkB for ; Tue, 2 May 2017 12:18:50 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A6012946D for ; Tue, 2 May 2017 12:16:10 -0700 (PDT) Received: from [10.88.69.21] (unknown [216.168.230.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C249C61F9E for ; Tue, 2 May 2017 19:16:09 +0000 (UTC) Message-ID: <5908DAF9.90802@redbarn.org> Date: Tue, 02 May 2017 12:16:09 -0700 From: Paul Vixie User-Agent: Postbox 5.0.12 (Windows/20170323) MIME-Version: 1.0 To: dnsop@ietf.org References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:18:52 -0000 Lee Howard wrote: > > On 3/16/17, 7:02 AM, "Philip Homburg" behalf of pch-dnsop-1@u-1.phicoh.com> wrote: > >> In my experience, without reverse DNS it is essentially impossible to have >> mail delivered to the internet at large. > > Yes. since this isn't an ideal or intended state of affairs, let's consider the size and shape of the box, not just what's in there. http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/ -- P Vixie From nobody Tue May 2 14:03:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6786A127B60 for ; Tue, 2 May 2017 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=XZIVlrf9; dkim=pass (1024-bit key) header.d=yitter.info header.b=QdMasSvy 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 6aXrpYpDkf4T for ; Tue, 2 May 2017 14:03:06 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C477C129418 for ; Tue, 2 May 2017 14:00:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id AEAF3BB834 for ; Tue, 2 May 2017 21:00:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1493758815; bh=yx/VVTTl9ddnskdHN0aS8bXmnF8Gv0DxnQ4PcViKO2w=; h=Date:From:To:Subject:References:In-Reply-To:From; b=XZIVlrf9fhEYImHqyoZ8eI5pl3iCeZ2xjwXt7tO+Cf+U3O2g9ESj7SJnQGWaTFoNC d1G6rWaPUz0z7hvyYxiQk1C14PgKYQRL0SCle1el3o32KT/7G0JA59anKPrWXRUL4B iHTx2TDwhU6HXGl/TSM6th/0zbByfFrMv0AT4bsc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N0dqrpGf2mh for ; Tue, 2 May 2017 21:00:10 +0000 (UTC) Date: Tue, 2 May 2017 17:00:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1493758810; bh=yx/VVTTl9ddnskdHN0aS8bXmnF8Gv0DxnQ4PcViKO2w=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QdMasSvyff+zbiEtOubfWS1mRb7/IeoeOzvqF9S9QNNS2q/BBAwZRqdmODzB1IMGl ADOEKrxJlvWTbY3jfOkrgrgxCdpqkLHEje7FC3WLYpF5cJQ22l52FIB2SGIsTTI2Hk SqRLIwsL63X2mDCZGudlQ8VYrhIjBbp4HmBBA5+0= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170502210009.fahwudu7ucaass2g@mx4.yitter.info> References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:03:08 -0000 On Tue, May 02, 2017 at 03:03:15PM -0400, Lee Howard wrote: > >Do you have a reference for the following statement > >Serving ads: "This host is probably in town.province." An ISP that does > >not > >provide PTR records might affect somebody else's geolocation. > > No. Given the privacy considerations, I¹ve changed the example from > ³x.town.province² to ³string.region² and added privacy considerations. So > I need to fix this text anyway. > > > > > >Extracting geo information from reverse DNS is very hard. As far as I > >know, > >geo location services for IPv4 mostly rely on other sources. > > That¹s probably true. Given that I need to update it to match what it says > in the Privacy Considerations section and the examples, should I just > remove mention of geolocation? Or should I tweak it to match the rest, and > add text saying, ³But reverse DNS is not a great source for geolocation > information²? For whatever it's worth, I know of one geolocation effort that uses the names in the reverse as clues about geolocation improvement. I am not able to state who it is or how they use this, but I can testify that it is in fact used that way. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue May 2 15:14:34 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF65012943C; Tue, 2 May 2017 15:14:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: tjw.ietf@gmail.com, warren@kumari.net, dnsop@ietf.org, dnsop-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149376327275.21500.1054590508087731346.idtracker@ietfa.amsl.com> Date: Tue, 02 May 2017 15:14:32 -0700 Archived-At: Subject: [DNSOP] dnsop - Update to a Meeting Session Request for IETF 99 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 22:14:33 -0000 An update to a meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group. --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dhc apparea appsawg homenet dnssd dprive Second Priority: v6ops intarea trans Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks --------------------------------------------------------- From nobody Wed May 3 04:12:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3082C129410 for ; Wed, 3 May 2017 04:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 Nr9M_wm6hrAI for ; Wed, 3 May 2017 04:12:50 -0700 (PDT) Received: from atl4mhob16.registeredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.109]) (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 4E9F5129420 for ; Wed, 3 May 2017 04:10:08 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id v43BA6kF013805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 May 2017 07:10:06 -0400 Received: (qmail 13368 invoked by uid 0); 3 May 2017 11:10:06 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 3 May 2017 11:10:05 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Wed, 03 May 2017 07:10:01 -0400 From: Lee Howard To: Paul Vixie , Message-ID: Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> <5908DAF9.90802@redbarn.org> In-Reply-To: <5908DAF9.90802@redbarn.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 11:12:52 -0000 On 5/2/17, 3:16 PM, "DNSOP on behalf of Paul Vixie" wrote: > > >Lee Howard wrote: >>=20 >> On 3/16/17, 7:02 AM, "Philip Homburg" > behalf of pch-dnsop-1@u-1.phicoh.com> wrote: >>=20 >>> In my experience, without reverse DNS it is essentially impossible to >>>have >>> mail delivered to the internet at large. >>=20 >> Yes. > >since this isn't an ideal or intended state of affairs, let's consider >the size and shape of the box, not just what's in there. > >http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electr >onic_mail/ I think I read that post six years ago, too. :) I don=B9t think that recommendations on fighting spam are in scope for this document, though. Is there text you think should be added? Lee > >--=20 >P Vixie From nobody Wed May 3 05:21:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D70129573 for ; Wed, 3 May 2017 05:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 MusNOCjeMGV9 for ; Wed, 3 May 2017 05:21:15 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AEA129AB2 for ; Wed, 3 May 2017 05:18:30 -0700 (PDT) Received: from linux-hs2j.localnet (unknown [216.168.230.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9850161F9E; Wed, 3 May 2017 12:18:28 +0000 (UTC) From: Paul Vixie To: Lee Howard Cc: dnsop@ietf.org Date: Wed, 03 May 2017 12:18:29 +0000 Message-ID: <2586517.0yFJumZehd@linux-hs2j> Organization: Vixie Freehold In-Reply-To: References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> <5908DAF9.90802@redbarn.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 12:21:17 -0000 On Wednesday, May 3, 2017 11:10:01 AM GMT Lee Howard wrote: > On 5/2/17, 3:16 PM, "DNSOP on behalf of Paul Vixie" > >since this isn't an ideal or intended state of affairs, let's consider > >the size and shape of the box, not just what's in there. > > > >http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_elec= tr > >onic_mail/ >=20 > I think I read that post six years ago, too. :) >=20 > I don=B9t think that recommendations on fighting spam are in scope for th= is > document, though. Is there text you think should be added? if you think the draft you have is the approach you must follow, then no. however, the people fighting about PTR's are doing so because of spam contr= ol.=20 there is no other operable modern need for these records in IP6.ARPA. it's = a=20 fight you can't win, because there is no right answer. i suggest that you offer the PTR people a better way to do what they want t= o=20 do, so that you can create an exit scenario from this debacle that would=20 actually please somebody. vixie From nobody Fri May 5 05:30:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA38126DEE for ; Fri, 5 May 2017 05:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ArBqEJytSDO8 for ; Fri, 5 May 2017 05:30:28 -0700 (PDT) Received: from smtp109.ord1c.emailsrvr.com (smtp109.ord1c.emailsrvr.com [108.166.43.109]) (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 6ABCA1243F6 for ; Fri, 5 May 2017 05:30:24 -0700 (PDT) Received: from smtp22.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id AD9A1E021C; Fri, 5 May 2017 08:30:23 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5BEC4E0202; Fri, 5 May 2017 08:30:19 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-96-255-4-80.washdc.fios.verizon.net [96.255.4.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 05 May 2017 08:30:23 -0400 From: Olafur Gudmundsson Message-Id: <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7A2C3C77-FBF0-4536-AD1F-3764BB84840C" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 5 May 2017 08:30:18 -0400 In-Reply-To: <20170410150917.GA22210@jurassic> Cc: IETF DNSOP WG To: Mukund Sivaraman References: <20170410093847.GA21654@jurassic> <20170410150917.GA22210@jurassic> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 12:30:31 -0000 --Apple-Mail=_7A2C3C77-FBF0-4536-AD1F-3764BB84840C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman wrote: >>=20 >=20 > We kind of restarted the draft adopting RSASSA-PSS, so please can you > review it this time from scratch without looking at the diff? >=20 > Many of the examples will need updating once algorithm numbers are > assigned for them (as for some calculations, the algorithm number is = an > input), so we didn't spend time on wrapping the long lines in this > revision. >=20 Ok I will bite and be the grumpy old man.=20 I strongly advocate against the adoption of this document in current = from.=20 It violates basic interoperability guidelines by defining way to many=20 algorithms with no justification why any of them are better or worse = than others.=20 There is no useful guidance on why these new algorithms are better even = among themselves.=20 One of the biggest hurdles to deployment is not in the 5-20 DNS software = packages in wide use; but in all the 1000=E2=80=99s of Provision systems = around the world, and the crypto libraries found on various Enterprise systems that have = life time of 4-8 years with security-only updates.=20 Lets learn the lessons documented in = https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-= 04 = I=E2=80=99m not convinced that SHA3 vs SHA2 matter at all given the = constraint small data with strict constraints on order and contents is = being signed.=20 Thus why define=20 - 5 new RSA algorithms proposed, why why ? ?=20 - 2 new ECDSA algorithms proposed why why ? ? In another document there 2 other algorithms being proposed at the same = time, that I support as they represent new and faster technology. All this will do is to cause confusion! The RSA KEY size allowed for these new supposed stronger Digest = algorithms is still left at 1024 or 1280 bytes, even though number of = other parts of the the Internet community will not consider signatures = by keys with less than 2048 bits.=20 If there is any reason to go down the path of this document it should = pick ONE RSA and ONE ECDSA algorithm. RSA should be defined sensible guidelines on key sizes; i.e. no keys = below some stronger value in the 1536-2048 byte range. The document is proposing two new DS algorithms WHY? The basic reason for new a DIS digest algorithm is =E2=80=9Cmuch = better=E2=80=9D so pick one and live with it.=20 There was an interesting discussion on a resolver software mailing list = few weeks back about what the RFC=E2=80=99s mean when there are DS = records with different digest=20 algorithm numbers: A domain had 2 DS records one with digest 1 one with = digest 2;=20 They both referred to the same key, but there was a typo/error in the = digest with algorithm 2;=20 Question what should the validator do ?=20 a) only trust the highest digest number?=20 b) trust any DS record ?=20 I.e. a higher number was interpreted by the implementor to mean better = thus only the highest supported number was the only one tried.=20 Additionally this document in its current form contains proposed = algorithm values which IMHO is a NoNo and I hope is removed from future = versions.=20 If there are interoperability tests you can define the numbers you want = to use on web page; not in an internet draft that someone may go ahead = and implement not realizing that the final RFC will have a different = number(s).=20 Olafur --Apple-Mail=_7A2C3C77-FBF0-4536-AD1F-3764BB84840C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <muks@isc.org> = wrote:


We kind of = restarted the draft adopting RSASSA-PSS, so please can you
review it this time from scratch without looking at the = diff?

Many of the examples will need = updating once algorithm numbers are
assigned for them (as = for some calculations, the algorithm number is an
input), = so we didn't spend time on wrapping the long lines in this
revision.


Ok I will = bite and be the grumpy old man. 

I strongly advocate against the adoption of this = document in current from. 
It violates basic = interoperability guidelines by defining way to = many 
algorithms with no justification why any of them = are better or worse than others. 
There is no useful = guidance on why these new algorithms are better even among = themselves. 

One of the biggest = hurdles to deployment is not in the 5-20 DNS software packages in wide = use; but in all the 1000=E2=80=99s of Provision systems around the = world,
and the crypto libraries found on various Enterprise = systems that have life time of 4-8 years with security-only = updates. 

I=E2=80=99m not = convinced that SHA3 vs SHA2 matter at all given the constraint small = data with strict constraints on order and contents is being = signed. 

Thus why = define 
    -  5 new  RSA algorithms = proposed, why why ? ? 
    -  2 new ECDSA = algorithms proposed why why ? ?
In another document there 2 = other algorithms being proposed at the same time, that I support as they = represent new and
faster technology.
All this will = do is to cause confusion!

The RSA = KEY size allowed for these new supposed stronger Digest algorithms is = still left at 1024 or 1280 bytes, even though number of other parts of = the the Internet community will not consider signatures by keys with = less than 2048 bits. 

If there = is any reason to go down the path of this document it should pick ONE = RSA and ONE ECDSA algorithm.
RSA should be defined sensible = guidelines on key sizes;  i.e. no keys below some stronger value in = the 1536-2048 byte range.

The = document is proposing two new DS algorithms WHY?
The basic = reason for new a  DIS digest algorithm is =E2=80=9Cmuch better=E2=80=9D= so pick one and live with it. 

There was an interesting discussion on a resolver = software mailing list few weeks back about what the RFC=E2=80=99s mean = when there are DS records with different = digest 
algorithm numbers: A domain had 2 DS records one = with digest 1 one with digest 2; 
They both referred to = the same key, but there was a typo/error in the digest with algorithm = 2; 
Question what should the validator do = ? 
a) only trust the highest digest = number? 
b) trust any DS record ? 
I.e. a = higher number was interpreted by the implementor to mean better thus = only the highest supported number was the only one = tried. 

Additionally this = document in its current form contains proposed algorithm values which = IMHO is a NoNo and I hope is removed from future = versions. 
If there are interoperability tests you can = define the numbers you want to use on web page; not in an internet draft = that someone may go ahead and
implement not realizing that the = final RFC will have a different = number(s). 

Olafur




= --Apple-Mail=_7A2C3C77-FBF0-4536-AD1F-3764BB84840C-- From nobody Fri May 5 07:04:35 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E48127BA3 for ; Fri, 5 May 2017 07:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 f_HTco_bRjVI for ; Fri, 5 May 2017 07:04:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F04126B6E for ; Fri, 5 May 2017 07:04:30 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 10F08448D75; Fri, 5 May 2017 14:04:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 10F08448D75 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 10F08448D75 Received: from oldenburg.str.redhat.com (ovpn-117-246.ams2.redhat.com [10.36.117.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C3D07ADD0; Fri, 5 May 2017 14:04:29 +0000 (UTC) To: Bob Harold Cc: dnsop References: <24869f89-8335-6ad8-667d-300b852957a1@redhat.com> From: Florian Weimer Message-ID: <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com> Date: Fri, 5 May 2017 16:04:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 05 May 2017 14:04:30 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] Redefining name canonicalization X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:04:33 -0000 On 04/21/2017 05:08 PM, Bob Harold wrote: > I can understand you wanting a "getfqdn" function to return the FQDN (fully > qualified domain name) without doing canonicalization. > > But just so we are clear on the DNS terms, > "access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases" > "e133.b.akamaiedge.net" is the canonical name. > > access.redhat.com is an alias for access.redhat.com.edgekey.net. > access.redhat.com.edgekey.net is an alias for e133.b.akamaiedge.net. > e133.b.akamaiedge.net has address 104.67.69.246 I'm aware of the terminology. I just think that in terms of RFC 3493, it would make sense to restrict the name transformation applied with AI_CANONNAME on the current internet, i.e. clarify that here If the AI_CANONNAME flag is specified and the nodename argument is not null, the function shall attempt to determine the canonical name corresponding to nodename (for example, if nodename is an alias or shorthand notation for a complete name). “alias” does not refer to CNAME chain resolution, but other forms of alias processing (like the slightly historic HOSTALIASES processing). This would help to address long-standing security issues in name canonicalization, e.g. in Kerberos deployments. Thanks, Florian From nobody Fri May 5 10:21:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F67124D37 for ; Fri, 5 May 2017 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 U5gjIT4YHBiQ for ; Fri, 5 May 2017 10:21:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC43129453 for ; Fri, 5 May 2017 10:21:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 943643004EE for ; Fri, 5 May 2017 13:21:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id koBrVceWCQJH for ; Fri, 5 May 2017 13:21:06 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8849F30041F; Fri, 5 May 2017 13:21:06 -0400 (EDT) From: Russ Housley Message-Id: <26802308-28D0-4BC1-BEC4-E5A8C52B7A35@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E861D4F-88B6-41D6-A894-1F919BF286BA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 5 May 2017 13:21:06 -0400 In-Reply-To: <20170410150917.GA22210@jurassic> Cc: IETF DNSOP WG To: Mukund Sivaraman References: <20170410093847.GA21654@jurassic> <20170410150917.GA22210@jurassic> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:21:10 -0000 --Apple-Mail=_4E861D4F-88B6-41D6-A894-1F919BF286BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman > wrote: >=20 > We kind of restarted the draft adopting RSASSA-PSS, so please can you > review it this time from scratch without looking at the diff? >=20 > Many of the examples will need updating once algorithm numbers are > assigned for them (as for some calculations, the algorithm number is = an > input), so we didn't spend time on wrapping the long lines in this > revision. I suggest that many of the options be dropped from this document before = the working group accepts it. I strongly support the move toward RSASSA-PSS or ECDSA. Both of these = offer an improvement over RSA PKCS#1 v1.5. That said, we have a lot of = experience that shows algorithm transitions are slow, so I think the = working group should pick one of these signature algorithms, not both. Why does this document support both SHA2 and SHA3? We know that theses = families of hash algorithms offer the same security. That is, SHA2-256 = and SHA3-256 offer exactly the same security. One could argue that the = reason to support both is because a flaw might be found in one and the = other is there for safety. Instead, I suggest that picking one family = of hash algorithms already provides that safety. One can use SHA2-384 = or SHA2-512 if a flaw is discovered in SHA2-256. So, again, pick one, = not both. Russ= --Apple-Mail=_4E861D4F-88B6-41D6-A894-1F919BF286BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 10, 2017, at 11:09 AM, Mukund = Sivaraman <muks@isc.org> wrote:

We kind of restarted the draft adopting = RSASSA-PSS, so please can you
review it this time from = scratch without looking at the diff?

Many = of the examples will need updating once algorithm numbers are
assigned for them (as for some calculations, the algorithm = number is an
input), so we didn't spend time on wrapping = the long lines in this
revision.

I suggest that many of the = options be dropped from this document before the working group accepts = it.

I strongly = support the move toward RSASSA-PSS or ECDSA.  Both of these = offer an improvement over RSA PKCS#1 v1.5.  That said, we have a = lot of experience that shows algorithm transitions are slow, so I think = the working group should pick one of these signature algorithms, not = both.

Why does = this document support both SHA2 and SHA3?  We know that theses = families of hash algorithms offer the same security.  That is, = SHA2-256 and SHA3-256 offer exactly the same security.  One could = argue that the reason to support both is because a flaw might be found = in one and the other is there for safety.  Instead, I suggest that = picking one family of hash algorithms already provides that safety. =  One can use SHA2-384 or SHA2-512 if a flaw is discovered in = SHA2-256.  So, again, pick one, not both.

Russ
= --Apple-Mail=_4E861D4F-88B6-41D6-A894-1F919BF286BA-- From nobody Fri May 5 15:10:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163F4126DC2 for ; Fri, 5 May 2017 15:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 MP_E0mSPFIXk for ; Fri, 5 May 2017 15:10:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 4ECA4126E64 for ; Fri, 5 May 2017 15:10:17 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 285043493AC; Fri, 5 May 2017 22:10:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DEA5416004C; Fri, 5 May 2017 22:10:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC10F16008E; Fri, 5 May 2017 22:10:13 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YDp2sdSHlum4; Fri, 5 May 2017 22:10:13 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7CDE216004C; Fri, 5 May 2017 22:10:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 966CE6DECBA9; Sat, 6 May 2017 08:10:10 +1000 (AEST) To: Florian Weimer Cc: Bob Harold , dnsop From: Mark Andrews References: <24869f89-8335-6ad8-667d-300b852957a1@redhat.com> <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com> In-reply-to: Your message of "Fri, 05 May 2017 16:04:28 +0200." <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com> Date: Sat, 06 May 2017 08:10:10 +1000 Message-Id: <20170505221010.966CE6DECBA9@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Redefining name canonicalization X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:10:19 -0000 In message <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com>, Florian Weimer wr ites: > On 04/21/2017 05:08 PM, Bob Harold wrote: > > > I can understand you wanting a "getfqdn" function to return the FQDN > (fully > > qualified domain name) without doing canonicalization. > > > > But just so we are clear on the DNS terms, > > "access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases" > > "e133.b.akamaiedge.net" is the canonical name. > > > > access.redhat.com is an alias for access.redhat.com.edgekey.net. > > access.redhat.com.edgekey.net is an alias for e133.b.akamaiedge.net. > > e133.b.akamaiedge.net has address 104.67.69.246 > > I'm aware of the terminology. > > I just think that in terms of RFC 3493, it would make sense to restrict > the name transformation applied with AI_CANONNAME on the current > internet, i.e. clarify that here > > If the AI_CANONNAME flag is specified and the nodename argument is > not null, the function shall attempt to determine the canonical name > corresponding to nodename (for example, if nodename is an alias or > shorthand notation for a complete name). > > alias does not refer to CNAME chain resolution, but other forms of > alias processing (like the slightly historic HOSTALIASES processing). It does mean the end of the CNAME chain. Just because some people misuse CNAME rather than requesting their own type to provide a name to server mapping or using SRV that we should change what the flag means. > This would help to address long-standing security issues in name > canonicalization, e.g. in Kerberos deployments. If you want the search name, then add a flag to request that and extend struct addrinfo by adding a pointer at then end of it which contains the resolution of the search. Yes, sometimes the contents of ai_canonname will be the same as ai_ and sometimes not. getaddrinfo and struct addrinfo are designed to be extended like this. Don't redefine the existing element. Mark > Thanks, > Florian > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat May 6 21:24:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8D0126557 for ; Sat, 6 May 2017 21:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 bw6XQvdXJcxf for ; Sat, 6 May 2017 21:24:30 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9A8126E3A for ; Sat, 6 May 2017 21:24:28 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id v20so15245344vke.2 for ; Sat, 06 May 2017 21:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8n74Wh9cNR+RnxLuohWUbePE5/m6zlfN7EpeFZfshAQ=; b=1fduc9cg8bZQqIeMDOf2QMGxC+ifFZCY1EghUmsCeMCThKIDG3cDC/xzLSvJ/cIfT3 K2Zd0H3yAxHT8W5hg0hiMA6g8OJ2hXvVXNqmvfg7t13wphn3qxxp8iDfp0xE/2LnKZ53 EuPaiSR8iGxZuhiXPGxpeenyyll8y4fjsEBeZqwNTa4lv8h8bKQrmzZ3y4b6bEidE4s7 MrFxBARCRY2s0N3q9BpHM3JXLmThRhGdY/M+TYM3RaTst3Z7rnwsSOQyPFj3+PHgbQrY jQePrqwGDVUMS2ifTnP3DVo4tMXXvLOh8I9HWgA+zF5/Qbl6F4oqbOaXScXka5hHamXj wtsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8n74Wh9cNR+RnxLuohWUbePE5/m6zlfN7EpeFZfshAQ=; b=iTAp9qiE/QJdwdErmthbJxHffcyrA7e9BX4Nk0ql2lq/Yz1D54GsGo2/WRk9fiROCu lOSi36CprnkGq3rd7FhLsqj+pRWkZYMBFfCwfPME/I2Dhy8U9umEGLF2Kj22e618+XI8 pkijBcdCgcmlV4bJRVLwnw0ELXEYGt8AmDgZ/QtHJKdMd6IEKWbg6IIB7EgpTpeRG2cZ jIgko4q0iTfWq5Cjtd9XiYh81SGTwcjb2Lux309Ka4M3Y5gDVS50qfvAkW+tuwWgZ+PE Q4IDfH0S3tDW3Nf3i/sAK12aNeBtBg+6A4uXnKtLY50ecO5OkuOrOZ8INOf+NnGtZYMj riYA== X-Gm-Message-State: AODbwcChh5wjTEgMbRzt0Ng05B2CAoMvcx1pqWv/Y9sfBuPxgW1gmOuc cKfnjk6/OYvKjzuATS/mPW98g/quQ5dB X-Received: by 10.31.136.10 with SMTP id k10mr4658470vkd.51.1494131066897; Sat, 06 May 2017 21:24:26 -0700 (PDT) MIME-Version: 1.0 References: <149360667193.9876.7534874775326889081@ietfa.amsl.com> In-Reply-To: <149360667193.9876.7534874775326889081@ietfa.amsl.com> From: Warren Kumari Date: Sun, 07 May 2017 04:24:15 +0000 Message-ID: To: Joel Halpern , "dnsop-chairs@ietf.org" , gen-art@ietf.org Cc: dnsop@ietf.org, draft-ietf-dnsop-nsec-aggressiveuse.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=001a114517cc7d9d69054ee77f9d Archived-At: Subject: Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-nsec-aggressiveuse-09 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 04:24:32 -0000 --001a114517cc7d9d69054ee77f9d Content-Type: text/plain; charset=UTF-8 Good catch -- these were included in the IETF Last Call notice, and there was discussion with the chairs and responsible AD. They will be noted in the downref registry; however, the write-up should have included a mention of this. I've CCed the chairs / will ask the AD to update the write-up for completeness... W On Mon, May 1, 2017 at 4:44 AM Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-dnsop-nsec-aggressiveuse-09 > Reviewer: Joel Halpern > Review Date: 2017-04-30 > IETF LC End Date: 2017-03-27 > IESG Telechat date: 2017-05-25 > > Summary: This document is almost ready for publication as a Proposed > Standard RFC > > Major issues: > Procedural - ID Nits notes that there are normative references to > RFCs 7129 and 7719. Those are informational RFCs. The shepherd > writeup does not note these downrefs. (I see this was also noted by > Jouni Korhonen, but I do not see a resolution.) > > Minor issues: > > Nits/editorial comments: > > > --001a114517cc7d9d69054ee77f9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good catch -- these were included in the IETF Last Call notice, a= nd there was discussion with the chairs and responsible AD. They will be no= ted in the downref registry; however, the write-up should have included a m= ention of this. I've CCed the chairs / will ask the AD to update the wr= ite-up for completeness...

W

<= /div>


On Mon, May 1, 2017 at 4:44 AM Joel Halpern <jmh@joelhalpern.com> wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-dnsop-nsec-aggressiveuse-09
Reviewer: Joel Halpern
Review Date: 2017-04-30
IETF LC End Date: 2017-03-27
IESG Telechat date: 2017-05-25

Summary: This document is almost ready for publication as a Proposed
Standard RFC

Major issues:
=C2=A0 =C2=A0 Procedural - ID Nits notes that there are normative reference= s to
RFCs 7129 and 7719.=C2=A0 Those are informational RFCs.=C2=A0 The shepherd<= br> writeup does not note these downrefs.=C2=A0 (I see this was also noted by Jouni Korhonen, but I do not see a resolution.)

Minor issues:

Nits/editorial comments:


--001a114517cc7d9d69054ee77f9d-- From nobody Mon May 8 09:30:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BBB127866 for ; Mon, 8 May 2017 09:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 en_SLmljcpmY for ; Mon, 8 May 2017 09:30:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B25D129503 for ; Mon, 8 May 2017 09:30:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1d7lYP-0000DiC; Mon, 8 May 2017 18:30:33 +0200 Message-Id: To: dnsop@ietf.org Cc: Lee Howard From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> In-reply-to: Your message of "Tue, 02 May 2017 15:03:15 -0400 ." Date: Mon, 08 May 2017 18:30:31 +0200 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:30:51 -0000 In your letter dated Tue, 02 May 2017 15:03:15 -0400 you wrote: >I agree that people reject mail if there=B9s no PTR; I think this is used in >fighting spam, based on an inference that if there=B9s no PTR, you=B9re a s= >pam >bot rather than a legitimate mail server. >The first case listed in 4. Considerations and Recommendations says > > There are six common uses for PTR lookups: > > Rejecting mail: A PTR with a certain string or missing may indicate > "This host is not a mail server," which may be useful for rejecting > probable spam. The absence of a PTR leads to the desired behavior. In the case of e-mail, my issue is more with the structure of the document than the actual text. To give an example where I'm coming from. The ISP I use for my home internet connection started out with IPv6 by offering tunnels. Given that tunnels are only used by tech savvy people, a simple editor where you could provide name servers for reverse DNS was offered and this worked well. Now that they offer native IPv6 there is no reverse DNS anymore. For two reasons. The first is that delegating reverse DNS is deemed to be to complex for ordinary users. The solution they want to implement, an editor where users can set individual records for hosts, has such a low priority that it never gets done. It has a low priority because oridinary users don't really need reverse DNS. What seems lost is that the IPv6 users that really need reverse DNS at the moment are the ones that try to have mail delivered and at the same time all of the reasons why oridinary users can't run DNS servers don't apply to that group. Reading the document, those two arguments are hard to find. I.e., in Section 4, I would say that most points are nice-to-haves, except for the one related to e-mail. At the same time, most options in Section 2 are quite tricky, except 2.4. So an ISP reading this draft may not realise that reverse DNS is really important for some customers and is relatively easy to provide to those users. >I=B9ve quoted much of that text above. >Given that the document is about residential ISPs, and given the above, >plus the guidance that the information should match if it=B9s possible to >reconcile them, does this document need an affirmative statement about >mail servers? = So my preference would be something that really stands out and not grouped together with, in my opinion, less important benefits. >That=B9s probably true. Given that I need to update it to match what it says >in the Privacy Considerations section and the examples, should I just >remove mention of geolocation? Or should I tweak it to match the rest, and >add text saying, =B3But reverse DNS is not a great source for geolocation >information=B2? I'd say that if having a location in reverse DNS serves the operational need for the ISP itself, then it's a good idea. Third parties may try to use that information, but it doesn't seem to be essential. By and large geo-location of eyeballs works fine even without location information in DNS. >Proposed new sentence: >Users of services which are dependent on a successful lookup >will have a poor experience if they have to wait for a timeout; an >NXDomain response is faster. Yes, that's clear and an important issue. >Proposed new sentence: >For best user experience, then, it is important to >return a response, including NXDomain, rather than have a lame delegation. I think that technically a lame delegation includes getting an error from the server. So by itself a lame delegation is not a problem. The problem is getting a timeout. From nobody Mon May 8 09:46:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17D9129508 for ; Mon, 8 May 2017 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 t7fBjqgYebgy for ; Mon, 8 May 2017 09:46:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 00227128D44 for ; Mon, 8 May 2017 09:46:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wM7gQ0HW7zp6; Mon, 8 May 2017 18:46:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1494261986; bh=eQmlaIwkYdOU0HJ99cCdHySmrFOYfQCeDr7wpfqxD7k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Mbkh2K+GsIz3ZPEaMd2odtV4GoxIO8Hoi7LHray78vT6kx6lDq2QDqUDwBv3p/SYU yxUyNNmdjTx30Hgx3TlY/ESCoyIU4kfRZimVYYmiJEZ2LMPmiCI4CsE6RcvXqsmwMh XGt5kBXQ3OzAliiqeOyf82OnyHCBSy1tCw7q78S0= 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 Pr4gA_xSrw7v; Mon, 8 May 2017 18:46:23 +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; Mon, 8 May 2017 18:46:23 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 486926EF88A; Mon, 8 May 2017 12:46:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 486926EF88A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 342F540D3587; Mon, 8 May 2017 12:46:21 -0400 (EDT) Date: Mon, 8 May 2017 12:46:21 -0400 (EDT) From: Paul Wouters To: Olafur Gudmundsson cc: Mukund Sivaraman , IETF DNSOP WG In-Reply-To: <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> Message-ID: References: <20170410093847.GA21654@jurassic> <20170410150917.GA22210@jurassic> <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:46:31 -0000 On Fri, 5 May 2017, Olafur Gudmundsson wrote: > I strongly advocate against the adoption of this document in current from.  > It violates basic interoperability guidelines by defining way to many  > algorithms with no justification why any of them are better or worse than others.  > There is no useful guidance on why these new algorithms are better even among themselves.  > > One of the biggest hurdles to deployment is not in the 5-20 DNS software packages in wide use; but in all the 1000’s of Provision > systems around the world, > and the crypto libraries found on various Enterprise systems that have life time of 4-8 years with security-only updates.  > Lets learn the lessons documented in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 > > I’m not convinced that SHA3 vs SHA2 matter at all given the constraint small data with strict constraints on order and contents is > being signed.  I agree. Especially in the light of how hard it is to remove obsolete algorithms. We should have very good reasons to add new ones. > The RSA KEY size allowed for these new supposed stronger Digest algorithms is still left at 1024 or 1280 bytes, even though number > of other parts of the the Internet community will not consider signatures by keys with less than 2048 bits.  Not only that, but the reason specified is to bump RSA from RSASSA-PKCS1-v1_5 to RSASSA-PSS. As far as I know, the security issues of RSASSA-PKCS1-v1_5 are that when using it to _encrypt_ bogus data, it can be used as an oracle to obtain private key bits. That means there is no on-the-wire security issue with RSASSA-PKCS1-v1_5 for Digital Signatures. And if HSMs are used to protect access to private keys, those keys should be marked as "signing only keys" to avoid exposing the private key via this attack if the machine with the HSM is compromised. Paul From nobody Mon May 8 10:16:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083E0129516 for ; Mon, 8 May 2017 10:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=no 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 E6T5tRE7nIYH for ; Mon, 8 May 2017 10:16:05 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA7E1200F1 for ; Mon, 8 May 2017 10:16:05 -0700 (PDT) Received: from jurassic (unknown [115.118.70.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 30F2156A00EC; Mon, 8 May 2017 17:16:01 +0000 (GMT) Date: Mon, 8 May 2017 22:45:57 +0530 From: Mukund Sivaraman To: Paul Wouters Cc: Olafur Gudmundsson , IETF DNSOP WG Message-ID: <20170508171557.GA17895@jurassic> References: <20170410093847.GA21654@jurassic> <20170410150917.GA22210@jurassic> <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 17:16:07 -0000 Hi Paul On Mon, May 08, 2017 at 12:46:21PM -0400, Paul Wouters wrote: > Not only that, but the reason specified is to bump RSA from > RSASSA-PKCS1-v1_5 to RSASSA-PSS. As far as I know, the security > issues of RSASSA-PKCS1-v1_5 are that when using it to _encrypt_ > bogus data, it can be used as an oracle to obtain private key > bits. That means there is no on-the-wire security issue with > RSASSA-PKCS1-v1_5 for Digital Signatures. And if HSMs are used > to protect access to private keys, those keys should be marked > as "signing only keys" to avoid exposing the private key via this > attack if the machine with the HSM is compromised. It isn't that the RSASSA-PKCS1-v1_5 signature scheme is currently broken. Revision 00 of the draft had used the RSASSA-PKCS1-v1_5 scheme to make it easier for implementations, and so I was defending it among colleagues at first. However, RSASSA-PSS is a more robust signature scheme with a more exact proof of security. We evaluated our choice and switched to that for use with SHA-3 in revision 01 after it was pointed out on this list. See "The Exact Security of Digital Signatures - How to Sign with RSA and Rabin", Bellare and Rogaway for why it is an improvement (vs. FDH). http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf One nusiance of PSS is that it uses entropy during signing (a salt value per signature) that may make it inconvenient for signing in environments without an entropy source. However it is possible to to create signatures with a non-random salt (so it was made a "SHOULD" in the draft) with equivalent security to FDH. With the random salt, it is a far more robust scheme for RSA signatures. RSASSA-PKCS1-v1_5 is no longer allowed for new application due to its lack of exact security. I'll reply to the other comments soon. Mukund From nobody Wed May 10 10:46:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC4A12E03D for ; Wed, 10 May 2017 10:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=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 2aIVtx-qiHuK for ; Wed, 10 May 2017 10:46:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C53812DDD2 for ; Wed, 10 May 2017 10:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E8FCC300541 for ; Wed, 10 May 2017 13:46:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FwHiQ1B7W65p for ; Wed, 10 May 2017 13:46:52 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9FA4B3004B6; Wed, 10 May 2017 13:46:52 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A7621989-6F0D-4AA1-B4D5-AE98F0844C27" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 13:46:52 -0400 In-Reply-To: Cc: IETF DNSOP WG To: Paul Wouters References: <20170410093847.GA21654@jurassic> <20170410150917.GA22210@jurassic> <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 17:46:56 -0000 --Apple-Mail=_A7621989-6F0D-4AA1-B4D5-AE98F0844C27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 8, 2017, at 12:46 PM, Paul Wouters wrote: >=20 >> The RSA KEY size allowed for these new supposed stronger Digest = algorithms is still left at 1024 or 1280 bytes, even though number >> of other parts of the the Internet community will not consider = signatures by keys with less than 2048 bits.=20 >=20 > Not only that, but the reason specified is to bump RSA from > RSASSA-PKCS1-v1_5 to RSASSA-PSS. As far as I know, the security > issues of RSASSA-PKCS1-v1_5 are that when using it to _encrypt_ > bogus data, it can be used as an oracle to obtain private key > bits. That means there is no on-the-wire security issue with > RSASSA-PKCS1-v1_5 for Digital Signatures. And if HSMs are used > to protect access to private keys, those keys should be marked > as "signing only keys" to avoid exposing the private key via this > attack if the machine with the HSM is compromised. If we are going to stick with RSA signatures, then I agree that we = should move toward RSASSA-PSS. However, if we are going to make a = change, then it is probably time to move toward the shorter public keys = offered by elliptic cure cryptography. Russ --Apple-Mail=_A7621989-6F0D-4AA1-B4D5-AE98F0844C27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 8, 2017, at 12:46 PM, Paul Wouters <paul@nohats.ca> = wrote:

The RSA KEY size allowed for = these new supposed stronger Digest algorithms is still left at 1024 or = 1280 bytes, even though number
of other parts of the the = Internet community will not consider signatures by keys with less than = 2048 bits. 

Not only that, but the reason = specified is to bump RSA from
RSASSA-PKCS1-v1_5 to RSASSA-PSS. = As far as I know, the security
issues of RSASSA-PKCS1-v1_5 are = that when using it to _encrypt_
bogus data, it can be used as an = oracle to obtain private key
bits. That means there is no = on-the-wire security issue with
RSASSA-PKCS1-v1_5 for Digital = Signatures. And if HSMs are used
to protect access to private = keys, those keys should be marked
as "signing only keys" to avoid = exposing the private key via this
attack if the machine with the = HSM is compromised.

If we are going to stick with RSA signatures, = then I agree that we should move toward RSASSA-PSS.  However, if we = are going to make a change, then it is probably time to move toward the = shorter public keys offered by elliptic cure cryptography.

Russ

= --Apple-Mail=_A7621989-6F0D-4AA1-B4D5-AE98F0844C27-- From nobody Thu May 11 03:58:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B396D12EB97 for ; Thu, 11 May 2017 03:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bTZeJmfU8KIs for ; Thu, 11 May 2017 03:58:09 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F1512EC4D for ; Thu, 11 May 2017 03:55:57 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e65so17350646ita.1 for ; Thu, 11 May 2017 03:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LCC62FvYTgtMvT11kEvs8y9c4V+AR3VO5OIp4Pj7LWE=; b=BJoXPr9EBdjUYsFE0jI8sGeEKoDx6iEqjtax2lPhEKk9tYLYXmLw8k2jjZdej7KrSZ H7YfdMcgT2C4QBFqjjJLPyVUU1oW7xW1lyeHhJLRqprm9oysjTkUqdDJCEIkKnjaRSl1 rhhrgAjOYgCrlPp8HYkpxs+MYbvnQVDnIJGUylJE3uzXm2ArqL1G5VpXBVdOdaBWA85s l0pbPLUdbRB+8s77+lnLLHRuPYEl5k+1jIUpPJGBNec2inTRCPDHEkrHC8P2ndljvzXp FKKVC5qbCAM1VUTQyz1+Br75hGuXNzORmOR9abDafv+Tq+kjfaQoIRD4AUtW7eaKsvE/ zcqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LCC62FvYTgtMvT11kEvs8y9c4V+AR3VO5OIp4Pj7LWE=; b=Qgsz67WBEk1LG94N+DGe7ts6JydS33hC+/b4E1MyRqGgolzUf9VLX4wROBDkddmjek 3SZ2o5Hn6HsidtIYs0qvuPSiotvMWro2dNz/tDtDrSLIrMt4/JUGhTWtKx1f0c5/L3BT 9BXqSnOOMnTdNCqVe9pDOW/Ckl8f22757PvbAAoumOfnngzCUv/rPqahdhKSNhiJ6fCH TeNc9MvwMCENMRLKmTOAbOhDh9PXzh9VEHI3PUp2tZahnYH6qEYnKLa1lhui4Xxzhryn sUH1ViWPX+Vz7yIFOnvpYwbZXmYFtNjhzvHM9cucfwu5JMl4PLdwebdGls3tiijzYq9X no2Q== X-Gm-Message-State: AODbwcD275gWnul0beLbA9Pvge190jb+49T3SX5DJsiLCcObozaL79pl MpMxmvW5uGrJGH794Nf7ug8atE05KT/T X-Received: by 10.36.152.2 with SMTP id n2mr312519itd.41.1494500156482; Thu, 11 May 2017 03:55:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.195 with HTTP; Thu, 11 May 2017 03:55:55 -0700 (PDT) From: tjw ietf Date: Thu, 11 May 2017 06:55:55 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="94eb2c05a688f1a9c9054f3d6efe" Archived-At: Subject: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 10:58:12 -0000 --94eb2c05a688f1a9c9054f3d6efe Content-Type: text/plain; charset="UTF-8" I'm caught up with my day job, and the discussion on this has died down, but it looks like the work is moving along smoothly, it's time to kick off a Call for Adoption on this document. (well, maybe late). This starts a Call for Adoption for: draft-hunt-dnsop-aname The draft is available here: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: Midnight 25 May 2017 Thanks, tim wicinski DNSOP co-chair --94eb2c05a688f1a9c9054f3d6efe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm caught = up with my day=C2=A0job,=C2=A0and the discussion on this has died down, but= it looks like the work is moving along smoothly, it's time to kick off= a Call for Adoption on this document. (well, maybe late).=C2=A0

= This starts a Call for Adoption for:=C2=A0draft-hunt-dnsop-aname


Please review this = draft to see if you think it is suitable for adoption by DNSOP, and comment= s to the list, clearly stating your view.

<= span style=3D"font-family:monospace;font-size:14px">Please also indicate if= you are willing to contribute text, review, etc.

This call for a= doption ends: Midnight 25 May 2017

Thanks,
tim wicinski
DNSOP co-chair
--94eb2c05a688f1a9c9054f3d6efe-- From nobody Thu May 11 03:59:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1A12EBAC for ; Thu, 11 May 2017 03:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VFYp4WFWItjl for ; Thu, 11 May 2017 03:59:41 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A395B129404 for ; Thu, 11 May 2017 03:57:52 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id o12so18797657iod.3 for ; Thu, 11 May 2017 03:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=r4JyPYfjoh6BA8f7hzuivEojmHNezcaHjuPHDT3v35I=; b=X1mGBY8/bB+8mkwjPFZ4pc49Ac2TVBYzqd6j5Y2E+xt0rgLvcJDhw3HknZAoPyKD1u c2so0BTbuWBX4B3G0D2gczQSY1/n/NeG5JIfEnsjWmKbn76STMyaI3dTqlLa4oG9PYc0 qhH7cjfY9TFaErMgaUZ6Bnuza4ejP0LQnXrFOf4kL20WgR5jnKUApdsBo6vQcziG3jfx PFJW1vJQgcaOxJKvtGpTtGc2iYIcFWRX14MLD7qXqhdNoy/Uxulu2GDoXNdS33fd6Xmd rx83TgC1Hvm9A2Sm7GuWV7i5TsKIW9p0Uo6I9pTVXtOigVn/pBkU54dYh+tL/RQThthr 6QCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r4JyPYfjoh6BA8f7hzuivEojmHNezcaHjuPHDT3v35I=; b=Z3tzSdOPXIlzYMy3UNFopB1lJZG1ZT4w5tX6UMfEOBgUX6HhqYArFSuiZmzu/GuzNJ 0+WlXygd2ZuTQ2DU2Zh9sCqR1VHbyuoIBlV6fpdjSuyrhP4injCdTMPjx+sqVyMrbRul jw4cg7FNCyYkuVqYeAvnm1+bMJ7vi4rIl1IBqf8PmG8FAoOeClOJ96HMq0ZItcnSWuyk MuAUv0R2t6qSZuzCGCgxYJD11fVO5ETGzgJL80WXkOAh65a1x7mzU5Hzgi6VmoWK1AVM zqd7+JToWoUm9RDqNojsW2vj9uvZTcghB+1hA/qZDGNaLI7Xa/Tl3lRBccBzQUDVQnwJ 5f4Q== X-Gm-Message-State: AODbwcAx8MrTHM0VHbb6oSajqkYepiImWS0JGhmOmmu6co104YgLCLam AQ2HJYkm/MlJWQodzJgmPyzgL7kHF4W9 X-Received: by 10.107.14.8 with SMTP id 8mr7658530ioo.46.1494500271628; Thu, 11 May 2017 03:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.195 with HTTP; Thu, 11 May 2017 03:57:51 -0700 (PDT) From: tjw ietf Date: Thu, 11 May 2017 06:57:51 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary=001a113fd992ceab77054f3d7523 Archived-At: Subject: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 10:59:43 -0000 --001a113fd992ceab77054f3d7523 Content-Type: text/plain; charset=UTF-8 There was a lot of consensus during our last meeting in Chicago that this should move forward, so it's time that we do so. This starts a Call for Adoption for: draft-kristoff-dnsop-dns-tcp-requirements The draft is available here: https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: Midnight 25 May 2017 Thanks, tim wicinski DNSOP co-chair --001a113fd992ceab77054f3d7523 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= There was a lot of consensus during our last meeting in Chicago that this s= hould move forward, so it's time that we do so.=C2=A0
=
This st= arts a Call for Adoption for:=C2=A0draft-kristoff-dnsop-dns-tcp-requirements
<= div>

Please review this draft to see if you think= it is suitable for adoption by DNSOP, and comments to the list, clearly st= ating your view.

Please also indicate if you are willing to contr= ibute text, review, etc.

This call for adoption ends: Midnight 25= May 2017

Thanks,
tim wicinski
DNSOP co-chair
--001a113fd992ceab77054f3d7523-- From nobody Thu May 11 09:45:52 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C098D129B08 for ; Thu, 11 May 2017 09:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no 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 XO2AWwQACVhx for ; Thu, 11 May 2017 09:45:49 -0700 (PDT) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3D212EC3F for ; Thu, 11 May 2017 09:38:55 -0700 (PDT) Received: by mail-wm0-f41.google.com with SMTP id m123so42506268wma.0 for ; Thu, 11 May 2017 09:38:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=knrxZDoXqGJl1NhuH2wyMu5LfUl8ftB9WXJ8mxlGA8M=; b=W+o55iMLi5jZ/sKPmbWbsPBAOCG+yW2R4b60a4sCvUgoIKdJlSk74YD7QLn28lkWzp wu193UuvAzfROFs/PJz6Aci1p4Rit0YLsd2dkajoOv9oDxmkYdFKQLCheNN3+yVY3Ee+ InCckpgs12j3ZKuqrorSVvqBxBJJkNhJ+WJBkN2yuqbLx3B/RWPDWUB0nL9SDU09N+oI Ecuudd1uLbQbpMEVk8Jx+iItg3XR6eUOLYpE9fnqI73vqpgXMpGTj1GfeeNh3M7cEbQY RO6mWt6EbSiB1aktDbjHNw2YlrgI+HvXHiEcfIMcl5+UjX6ni9EvrHSl0me18XHDJX4u +vLg== X-Gm-Message-State: AODbwcAtLqBWCEMabsdd0JZ+uvsOpu9MZWhZJRLuIzcrE6LgisC94hbt vwPwH9ppd+Jjgw== X-Received: by 10.80.179.209 with SMTP id t17mr38957edd.62.1494520733825; Thu, 11 May 2017 09:38:53 -0700 (PDT) Received: from localhost ([188.206.110.125]) by smtp.gmail.com with ESMTPSA id g48sm336946edc.8.2017.05.11.09.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 09:38:52 -0700 (PDT) Date: Thu, 11 May 2017 18:38:44 +0200 From: Job Snijders To: tjw ietf Cc: dnsop Message-ID: <20170511163844.46tmp5wgmm4t7l2e@Vurt.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:45:51 -0000 On Thu, May 11, 2017 at 06:55:55AM -0400, tjw ietf wrote: > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I support adoption of this draft. > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: Midnight 25 May 2017 I'm willing to review, contribute. Kind regards, Job From nobody Thu May 11 10:03:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68483129C40 for ; Thu, 11 May 2017 10:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 qC4gg-GU0nzf for ; Thu, 11 May 2017 10:03:28 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD85912E6D7 for ; Thu, 11 May 2017 09:59:15 -0700 (PDT) Received: (qmail 39717 invoked from network); 11 May 2017 16:59:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 May 2017 16:59:14 -0000 Date: 11 May 2017 16:58:52 -0000 Message-ID: <20170511165852.34338.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: paul@redbarn.org In-Reply-To: <5908DAF9.90802@redbarn.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:03:29 -0000 In article <5908DAF9.90802@redbarn.org> you write: >> behalf of pch-dnsop-1@u-1.phicoh.com> wrote: >> >>> In my experience, without reverse DNS it is essentially impossible to have >>> mail delivered to the internet at large. >> >> Yes. > >since this isn't an ideal or intended state of affairs, let's consider >the size and shape of the box, not just what's in there. What would be the operational advantage of accepting mail from IPv6 hosts too lame to set up rDNS? R's, John From nobody Thu May 11 10:17:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97912EBD6 for ; Thu, 11 May 2017 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nwHcyq1wxu1t for ; Thu, 11 May 2017 10:17:20 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE1D129C59 for ; Thu, 11 May 2017 10:12:04 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id j29so22664120qtj.1 for ; Thu, 11 May 2017 10:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AiW60oCIYFsaRY+ZT3vrVOkseJrJTgu1PGiZrCN9F5U=; b=AUa72ivetRFbmp4Ns+vjSyT0CzGowvSFhBOTc/UZ7lK0QYzLRsJ9DLfmHa77oVF/Am URxUiRaG0pq+BJuyUurl6qfxqdn9l3tFSfBYoHifxkbF+XJHr9tP/aomuuQugbTvk6f1 1tSVQXmSBEOfcgZulzug6V9mqEgys5SqwvBiQIyY7JlAJE4F9Ra+X8UFKxCyK5+b3zZ1 BT8JmedLcwIiEGiiGrDlRWOZstvA8XqedxOHYScnVAfASRquLTgLf7lqjbqMjK+lq1/u 90Ga9WFRta5OVXCnxAu9uxSyi6696OQLjMJwii8FeIFVcO5oxGykaEkE9TmFLrLK4tJC nl1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AiW60oCIYFsaRY+ZT3vrVOkseJrJTgu1PGiZrCN9F5U=; b=jVjyVXU4H4JML2mMH7LRrHmYc3PnRqrivONA29dDNrnpteY6v2Y+DWXQMe2hDKS5nG nVi7kCXH73OAfFf7/70LCDAlJuDrwfod9XuOG4p0nyQLZYkQd++nphxi3wzff6SCnPHz i+NgWjjoTRUt46OcO6ATdRFH64vU+ZsKlpGFJzqs95/ahSokuPKyuCSdxuquPVizxkqA yiqSC2vmHV0yD9495T8WHyBbTkZ6Qfq3IluY896h/M3qsMiWhHCfrVYJSU697VTyHBBy pDy7D9cLcXgNH+z4FDKnNe0XJKCu/46M0a/AaZ5PxmOpiOlAOIoF8fzFg+84LDq15ZG6 FxSg== X-Gm-Message-State: AODbwcCT1dAtvq10OAjS/hT+YES19V4iR6FO3xntzW8XvxHl0AyJt5k7 JwkAOEj+ybkjT4YRE7O9sn/g6uKf4g== X-Received: by 10.200.46.10 with SMTP id r10mr181633qta.290.1494522723771; Thu, 11 May 2017 10:12:03 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Thu, 11 May 2017 10:12:03 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 11 May 2017 10:12:03 -0700 X-Google-Sender-Auth: duz_vpjcqwndYsca5DROv8OYH5Q Message-ID: To: tjw ietf Cc: dnsop Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:17:22 -0000 At Thu, 11 May 2017 06:55:55 -0400, tjw ietf wrote: > I'm caught up with my day job, and the discussion on this has died down, > but it looks like the work is moving along smoothly, it's time to kick off > a Call for Adoption on this document. (well, maybe late). > > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. I support the adoption. I'm willing to review subsequent versions. Actually I've already reviewed the current version and provided comments: https://www.ietf.org/mail-archive/web/dnsop/current/msg20130.html but as far as I remember I've not seen any response to it from the authors. I hope that was not because the comments were so stupid and simply and silently dismissed. -- JINMEI, Tatuya From nobody Thu May 11 10:20:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7386212EC51 for ; Thu, 11 May 2017 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 8-yTOefrgogY for ; Thu, 11 May 2017 10:20:02 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 6F1DF129BD8 for ; Thu, 11 May 2017 10:14:55 -0700 (PDT) Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.14.4/8.14.4) with ESMTP id v4BHEqUc019558 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 May 2017 19:14:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1494522892; bh=CTLpRyK4aGSkpjsUdIN7A/NmISy7ioK3VRfNAOuwyPg=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=hNSVdh4kR5a6kE9zW/a23jKi1GS7Y9qeC88IZXq0+qFDt2W5Wt/YyimGwJKUrLaHt 6E2zJY8j3PpkRvreapyehrRtA+4ZNV1rNxGY3fJn0ee9v2O9mPYElPt7Z4QL45UMTm lO1ijjZELv1GsXJSoiFjUmqGDm+l8GxpGHj65gcE= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1d8rfw-00049O-4P; Thu, 11 May 2017 19:14:52 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: "John Levine" Cc: dnsop@ietf.org, paul@redbarn.org Organization: m References: <20170511165852.34338.qmail@ary.lan> Date: Thu, 11 May 2017 19:14:52 +0200 In-Reply-To: <20170511165852.34338.qmail@ary.lan> (John Levine's message of "11 May 2017 16:58:52 -0000") Message-ID: <87wp9n48oj.fsf@miraculix.mork.no> User-Agent: Gnus/5.130015 (Ma Gnus v0.15) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:20:08 -0000 "John Levine" writes: > What would be the operational advantage of accepting mail from IPv6 hosts > too lame to set up rDNS? The answer is pretty much the same as the answer to the question: "What would be the operational advantage of accepting mail?" Bj=C3=B8rn From nobody Thu May 11 10:33:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61012EC96 for ; Thu, 11 May 2017 10:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 ENG6PkV4DWR6 for ; Thu, 11 May 2017 10:33:00 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3153812EBCE for ; Thu, 11 May 2017 10:28:11 -0700 (PDT) Received: from [192.168.7.93] (104-7-65-172.lightspeed.sntcca.sbcglobal.net [104.7.65.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 088C761FA2; Thu, 11 May 2017 17:28:10 +0000 (UTC) Message-ID: <59149F29.6090908@redbarn.org> Date: Thu, 11 May 2017 10:28:09 -0700 From: Paul Vixie User-Agent: Postbox 5.0.13 (Windows/20170501) MIME-Version: 1.0 To: John Levine CC: dnsop@ietf.org References: <20170511165852.34338.qmail@ary.lan> In-Reply-To: <20170511165852.34338.qmail@ary.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:33:01 -0000 John Levine wrote: >>>> In my experience, without reverse DNS it is essentially impossible to have >>>> mail delivered to the internet at large. >>> Yes. >> since this isn't an ideal or intended state of affairs, let's consider >> the size and shape of the box, not just what's in there. > > What would be the operational advantage of accepting mail from IPv6 hosts > too lame to set up rDNS? we will never know, because every v6 end system will have a ptr, either naturally, or machine-generated for it, because v6 providers will not want their rank-and-file v6 endsystems to be excluded from important activities such as transmitting e-mail. the operational advantage of not having ptr's for rank and file end systems is much easier to explain, except to v6 endsystem providers. -- P Vixie From nobody Thu May 11 10:38:39 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BEE129C59 for ; Thu, 11 May 2017 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MAgSMNu2; dkim=pass (1536-bit key) header.d=taugh.com header.b=Rs7mob3H 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 ynqOI05kNrHV for ; Thu, 11 May 2017 10:38:35 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF30712E04F for ; Thu, 11 May 2017 10:33:41 -0700 (PDT) Received: (qmail 43184 invoked from network); 11 May 2017 17:33:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a8ae.5914a074.k1705; bh=7P/9bZb7k8mq/DvyAz4qURTYObGBVr61ppzMOndG7hg=; b=MAgSMNu24N3tPR7U3WJMmlGrv8WbleuvrHDRoWpAKJXeVnN2VFFxjsvhJGPxVcjaRdqquDmlobFiaEscIEKdmA0awvpbnNhzPIW06IU2TZz1iJMD2nEcob0U3n7kTjXIBpqSpebzKZNgNByxcsXcBN8X3vilBNVm1flIQa62d0mVMrnVQkxZMejc1Od9wuo+hMHU3fYD7e4sdMiATqEX03CdR7NMIcortKcmNKKGQWiJUGu+SzoZ4vJ0X5CJQ+tm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a8ae.5914a074.k1705; bh=7P/9bZb7k8mq/DvyAz4qURTYObGBVr61ppzMOndG7hg=; b=Rs7mob3HUT8mFNYwahZaKUjxo4xsjV+PfIhF+ienJTrOf2vN0J5FaW9ySttagIm8XW8YEsskHhEkRR3wlsrZgRLC8EgYL1aKh/LVgR2vL/gR5rrbO7PP4MYDDo0uoAj6/xuKkOG4xSvCP7WZsD1Ew/aTmMSQ+pNudzSdiby82xA9V4W8ZhyfsjkfQIeTpIvr9ULdL6hQiKuzHlDvm0qWiBDE0WNRPBRSsz/seN2f6zLCg5L1Nb6VC2o07aqG9YLT Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 11 May 2017 17:33:40 -0000 Date: 11 May 2017 13:33:40 -0400 Message-ID: From: "John R Levine" To: "Paul Vixie" Cc: dnsop@ietf.org In-Reply-To: <59149F29.6090908@redbarn.org> References: <20170511165852.34338.qmail@ary.lan> <59149F29.6090908@redbarn.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:38:37 -0000 >> What would be the operational advantage of accepting mail from IPv6 hosts >> too lame to set up rDNS? > > we will never know, because every v6 end system will have a ptr, either > naturally, or machine-generated for it, because v6 providers will not > want their rank-and-file v6 endsystems to be excluded from important > activities such as transmitting e-mail. You might want to talk to large providers that do v6 now. With only one exception I can think of, they have no plans to do synthesized v6 rDNS, and they routinely block port 25 from all their consumer networks. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 11 10:39:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23924129B59 for ; Thu, 11 May 2017 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 ZpIV33SUrdMr for ; Thu, 11 May 2017 10:39:43 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B764D129BC6 for ; Thu, 11 May 2017 10:34:48 -0700 (PDT) Received: from [192.168.7.93] (104-7-65-172.lightspeed.sntcca.sbcglobal.net [104.7.65.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8A13F61FA2; Thu, 11 May 2017 17:34:48 +0000 (UTC) Message-ID: <5914A0B7.805@redbarn.org> Date: Thu, 11 May 2017 10:34:47 -0700 From: Paul Vixie User-Agent: Postbox 5.0.13 (Windows/20170501) MIME-Version: 1.0 To: John R Levine CC: dnsop@ietf.org References: <20170511165852.34338.qmail@ary.lan> <59149F29.6090908@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:39:44 -0000 John R Levine wrote: > You might want to talk to large providers that do v6 now. With only one > exception I can think of, they have no plans to do synthesized v6 rDNS, > and they routinely block port 25 from all their consumer networks. i'd like to meet your friends. but i'd also like them write an rfc about it. -- P Vixie From nobody Thu May 11 10:46:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09888129BF0 for ; Thu, 11 May 2017 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.479 X-Spam-Level: * X-Spam-Status: No, score=1.479 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=SaX654iO; dkim=pass (1536-bit key) header.d=taugh.com header.b=B114R20b 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 fddVdPHZlO2p for ; Thu, 11 May 2017 10:46:25 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56D5130A94 for ; Thu, 11 May 2017 10:41:19 -0700 (PDT) Received: (qmail 44745 invoked from network); 11 May 2017 17:41:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=aec7.5914a23e.k1705; bh=oW9SfJl5phDAV9SJVXjiKjUw+ygTa4iFUWOULh9ZyG8=; b=SaX654iOAqmOt9Xp7IU36YHTVv5k+GYX5v2e3A011cY1Nntm/iQFnFnFpiLZep3gmnQao9yPBB6ahg0qVPDH9JNSno8GWlndyjBay8xkOiMwyBk9GoGMQ+IWUES8Sg1IZL6oIe7LC2+vaMTvbB5ikgO1B5rzjvWTTm29/wn7JC90n5+oECcKEk6bzrei9Z1bPxBTz9r9566ELiD3NgjfdquL5Eq/G8sRqLxSE7b7RfEh+UMRM/O8NUlgTeDw9JdN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=aec7.5914a23e.k1705; bh=oW9SfJl5phDAV9SJVXjiKjUw+ygTa4iFUWOULh9ZyG8=; b=B114R20bHUlWytlI/v7DXjkIOWQA1Ua84/+NwU3yNvxJ+ryOID5GOmhNgNzIvvaa8QlbYSHW03RXNoGBcPnBgDuJuULolgRXnAZWQoi20FJPYmJ8M9Fdar8lZIi3LbhFskAog81foOBxD+eI/JR3r3gwxsD8rBofclRI4Rza9yLMU5CzSaI0JIaQlExa0p7ScZUc3KTMhMFTKpMW1is5TWtbZGHvlbsj9B12qdDQX+bhfGwnJ79+rjMKrzURVnvY Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 11 May 2017 17:41:18 -0000 Date: 11 May 2017 13:41:18 -0400 Message-ID: From: "John R Levine" To: "Paul Vixie" Cc: dnsop@ietf.org In-Reply-To: <5914A0B7.805@redbarn.org> References: <20170511165852.34338.qmail@ary.lan> <59149F29.6090908@redbarn.org> <5914A0B7.805@redbarn.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:46:26 -0000 >> You might want to talk to large providers that do v6 now. With only one >> exception I can think of, they have no plans to do synthesized v6 rDNS, >> and they routinely block port 25 from all their consumer networks. > > i'd like to meet your friends. but i'd also like them write an rfc about it. You've met a lot of them at M3AAWG. Also see draft-ietf-dnsop-isp-ip6rdns I hope we are not so foolish as to repeat the NAT fiasco and stick our fingers in our ears becuse the rest of the world doesn't work in a way some of us might prefer. The reality is that if you want people to accept your v6 mail, your mail hosts need rDNS, and not rDNS that looks like it was autogenerated by kludges like BULK. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 11 11:37:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AE212947D for ; Thu, 11 May 2017 11:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 3oQP1scj7SWD for ; Thu, 11 May 2017 11:37:38 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031A412EC07 for ; Thu, 11 May 2017 11:32:29 -0700 (PDT) Received: from [192.168.0.16] (unknown [IPv6:2001:610:666:0:5171:a3dd:ab86:36a6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 2E4BE1BD39; Thu, 11 May 2017 20:32:26 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Thu, 11 May 2017 20:32:25 +0200 Message-ID: <3F055CAE-32C9-447A-A067-30DC398B7170@powerdns.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 18:37:40 -0000 Hello Jinmei, On 11 May 2017, at 19:12, 神明達哉 wrote: > I support the adoption. I'm willing to review subsequent versions. > Actually I've already reviewed the current version and provided > comments: > https://www.ietf.org/mail-archive/web/dnsop/current/msg20130.html > but as far as I remember I've not seen any response to it from the > authors. I hope that was not because the comments were so stupid and > simply and silently dismissed. We have not silently dismissed you, and we appreciate the time you took to write it all down. We have compiled a long list of comments to go through, and your email, being extra long, is currently a singular item on that list because it deserves some time to digest. We take every comment seriously, even if we don’t necessarily respond. I hope we can post a new version within a few weeks. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Thu May 11 11:39:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F405D12EC27 for ; Thu, 11 May 2017 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-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 ow4X5DLqN9gR for ; Thu, 11 May 2017 11:39:37 -0700 (PDT) Received: from tmpmail.powerdns.com (tmpmail.powerdns.com [128.199.32.142]) by ietfa.amsl.com (Postfix) with ESMTP id C27AB129C71 for ; Thu, 11 May 2017 11:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tmpmail.powerdns.com (Postfix) with ESMTP id 59A766D937; Thu, 11 May 2017 14:33:43 -0400 (EDT) Received: from tmpmail.powerdns.com ([127.0.0.1]) by localhost (tmpmail.powerdns.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIllCrCQC2Cj; Thu, 11 May 2017 14:33:42 -0400 (EDT) Received: from server.ds9a.nl (unknown [IPv6:2001:470:1f15:bba::42]) by tmpmail.powerdns.com (Postfix) with ESMTP id 7EA8C6D935; Thu, 11 May 2017 14:33:42 -0400 (EDT) Received: by server.ds9a.nl (Postfix, from userid 1000) id 498A9AC33D5; Thu, 11 May 2017 20:33:39 +0200 (CEST) Date: Thu, 11 May 2017 20:33:39 +0200 From: bert hubert To: tjw ietf Cc: dnsop Message-ID: <20170511183339.GF5017@server.ds9a.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 18:39:39 -0000 On Thu, May 11, 2017 at 06:55:55AM -0400, tjw ietf wrote: > I'm caught up with my day job, and the discussion on this has died down, > but it looks like the work is moving along smoothly, it's time to kick off > a Call for Adoption on this document. (well, maybe late). > > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I have reviewed this draft and also have operational & development experience with the authoritative side implementation of something highly similar. In addition, Peter, one of the co-authors, is a swell coworker of mine and a person I enjoy drinking beer with. So take my recommendation with the appropriate grains of salt. But given all that, I heartily recommend ANAME for adoption by DNSOP. Bert PowerDNS From nobody Thu May 11 12:21:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B19A1314BD for ; Thu, 11 May 2017 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 XxHNklPLhS_Z for ; Thu, 11 May 2017 12:21:19 -0700 (PDT) Received: from spamfilter01.streamservice.nl (spamfilter01.streamservice.nl [91.199.167.162]) by ietfa.amsl.com (Postfix) with ESMTP id 76EBC1200F3 for ; Thu, 11 May 2017 12:16:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by spamfilter01.streamservice.nl (Postfix) with ESMTP id 6E80326093 for ; Thu, 11 May 2017 21:16:03 +0200 (CEST) Received: from spamfilter01.streamservice.nl ([127.0.0.1]) by localhost (spamfilter01.streamservice.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyiIedEKr2cS for ; Thu, 11 May 2017 21:16:03 +0200 (CEST) Received: from da01.streamservice.nl (unknown [91.199.167.36]) by spamfilter01.streamservice.nl (Postfix) with ESMTPS id D7A5B2601E; Thu, 11 May 2017 21:15:10 +0200 (CEST) Received: from ip51cd1efc.speed.planet.nl ([81.205.30.252] helo=DESKTOPHVV388B) by da01.streamservice.nl with esmtpa (Exim 4.86) (envelope-from ) id 1d8tYL-0006pq-O5; Thu, 11 May 2017 21:15:09 +0200 From: "Mark Scholten" To: "'tjw ietf'" , "'dnsop'" References: In-Reply-To: Date: Thu, 11 May 2017 21:15:12 +0200 Message-ID: <087001d2ca8a$ea0c54e0$be24fea0$@streamservice.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9HC1AFEJLy0aaJCJKmYDXkQE3baKa3PFg Content-Language: en-us Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:21:21 -0000 > From: tjw ietf [mailto:tjw.ietf@gmail.com]=20 > Sent: Thursday, May 11, 2017 12:56 > > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: = https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for = adoption by DNSOP, and comments to the list, clearly stating your view. I support adoption of this draft. > Please also indicate if you are willing to contribute text, review, = etc. I'm willing to review. Kind regards, Mark From nobody Thu May 11 12:35:57 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109FE130A97 for ; Thu, 11 May 2017 12:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6TaUpEIqoiSA for ; Thu, 11 May 2017 12:35:54 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F784129B97 for ; Thu, 11 May 2017 12:30:33 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f102so27914680ioi.2 for ; Thu, 11 May 2017 12:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Az53eooWTEHbSne3DPSRj12I7pZRDZ/1yUkLjeEOqhs=; b=EFpheofcqFBSL9TRPhKB8ibYHaaH3efhrJF0yDi55ZUbqMQOj2UpBeyWbqr58R1E28 vBJxaZtz61oH/8fXPsgBn9XbHDlv+PDnlpx34oygYm6AgMJhvWe1/UY9ehslvs3STZDg guA6+L/z7j77eoBKio1m5xnmH9Ysb8A0Wa/aAKJ1IfmkhdOzdZ0ItNcrJMO5KKFJwtPQ 0S2WemsPQkMizEHeW7HpkJ68EPrVFk2akcGp927adtRf5GlxgpHa6FTg+dYjN0WtlnaE Htw54fq54s6lY1OMRmglMxHD26cr1mLSaZDPapk1QMgF5z9VrIdbqwRi/CCEpexDUJYy xIcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Az53eooWTEHbSne3DPSRj12I7pZRDZ/1yUkLjeEOqhs=; b=IVauVqRoUgWOknou4Ztsx2JVFF1ncKfsGWEfYksirVUKk3LDJryoPScSlxbWuoU1Hk bOLK3P0Z+XpUYrXO/VlA1ByfaEeEDktxvXaItLp743rzeZaIXYAgu5IOg4ahAj+RBN44 VVwgJzUjONg0K2JnNiU0Q8lnvwI+9GFusnRBtg3tavq9U54NuULQzPqHrEH3URRn2u7n 8LRX0Q0Cz0u6Wid3nCzsWEYjPLHHmH/A1zzgF9pYUPFCcyGXeF6jGE+yRq4HY3VVQ+ma mmFrswwtqqYmHrVUNgwJSglhiqw+JzgDqmD7mc0FTDSgLpRhL8GgAzhlCu1VkeIpNhIj 8mqQ== X-Gm-Message-State: AODbwcCv6Kbqk33n1w8UDVyFd6N60TumHBSgyFEb3kFW4S57D4ykt1CC lfvkrHdAxoWZVNHnlVqVqXDyrsh+GBAT X-Received: by 10.107.51.14 with SMTP id z14mr190472ioz.84.1494531032567; Thu, 11 May 2017 12:30:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.195 with HTTP; Thu, 11 May 2017 12:30:31 -0700 (PDT) In-Reply-To: <087001d2ca8a$ea0c54e0$be24fea0$@streamservice.nl> References: <087001d2ca8a$ea0c54e0$be24fea0$@streamservice.nl> From: tjw ietf Date: Thu, 11 May 2017 15:30:31 -0400 Message-ID: To: Mark Scholten Cc: dnsop Content-Type: multipart/alternative; boundary="001a113a8bc84d5676054f449f85" Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:35:56 -0000 --001a113a8bc84d5676054f449f85 Content-Type: text/plain; charset="UTF-8" JINMEI I've noted your previous remarks as something I would take up with the authors. But thanks for the reminder. tim On Thu, May 11, 2017 at 3:15 PM, Mark Scholten wrote: > > From: tjw ietf [mailto:tjw.ietf@gmail.com] > > Sent: Thursday, May 11, 2017 12:56 > > > > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > > > The draft is available here: https://datatracker.ietf.org/ > doc/draft-hunt-dnsop-aname/ > > > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > I support adoption of this draft. > > > Please also indicate if you are willing to contribute text, review, etc. > > I'm willing to review. > > Kind regards, > > Mark > > --001a113a8bc84d5676054f449f85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
JINMEI

=
I've noted your pre= vious remarks as something I would take up with the authors.=C2=A0 But than= ks for the reminder.

tim

On Thu, May 11, 2017 at 3:15 PM, Mark Scholten &= lt;mark@streamse= rvice.nl> wrote:
> Fro= m: tjw ietf [mailto:tjw.ietf@gmail.co= m]
> Sent: Thursday, May 11, 2017 12:56
>
> This starts a Call for Adoption for: draft-hunt-dnsop-aname
>
> The draft is available here: https://da= tatracker.ietf.org/doc/draft-hunt-dnsop-aname/
>
> Please review this draft to see if you think it is suitable for adopti= on by DNSOP, and comments to the list, clearly stating your view.

I support adoption of this draft.

> Please also indicate if you are willing to con= tribute text, review, etc.

I'm willing to review.

Kind regards,

Mark


--001a113a8bc84d5676054f449f85-- From nobody Thu May 11 14:28:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0786E1294E6 for ; Thu, 11 May 2017 14:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 Ki7N7Exla26d for ; Thu, 11 May 2017 14:28:39 -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 37270129C2A for ; Thu, 11 May 2017 14:22:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wP5f30GSlz3C6; Thu, 11 May 2017 23:22:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1494537723; bh=QoCOPOR4TTQjTiq1uqvYSb11JXifUmsfkjk3FDDV3Kw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GLTdKJQGIlxxfpsr8cxeS/hvPYPRnJmAid0MNgCpfpx2CSJGgMoX23hokZ+2Z2FBM dmqy0pkBccWPE/Uno/sClXGNmNxg2Xgz4Q8zbR1i/HFTSOM9x7+jnhtoHSCHgKUCAh Ey2zhQ0FSScNxzWo0zqN2rOKhTnpGeFIuZq6RTvM= 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 BYLHYdWN42xX; Thu, 11 May 2017 23:22:00 +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; Thu, 11 May 2017 23:21:59 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6896641C1FC; Thu, 11 May 2017 17:21:58 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6896641C1FC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 522274129B74; Thu, 11 May 2017 17:21:58 -0400 (EDT) Date: Thu, 11 May 2017 17:21:58 -0400 (EDT) From: Paul Wouters To: tjw ietf cc: dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 21:28:41 -0000 On Thu, 11 May 2017, tjw ietf wrote: > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, > clearly stating your view. I am against adopting this document. It proposes to create a new RRTPYE that has specialised processing and bundles two problem solutions into one niche solution that has offline DNSSEC signing issues. I think it is better to solve the problem in two dinstict parts: 1) Create an ANAME record that instructs where an AUTH server can get updated data regarding its A/AAAA records. This can be signed without any problem. 2) Create an EDNS0 option allowing arbitrary query types to be bundled. This will allow asking for A+AAAA+ANAME, resulting in getting the latest known records plus a reference where to get updates in one query. There were already drafts out there that address 2) Also, solving 2) allows bund;ing to be used for other record types as well (that don't use _prefixes). Paul From nobody Thu May 11 16:30:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E6412EC38 for ; Thu, 11 May 2017 16:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xj2MQMSCTWol for ; Thu, 11 May 2017 16:30:03 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008BA129C6B for ; Thu, 11 May 2017 16:25:14 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id k74so35644483qke.1 for ; Thu, 11 May 2017 16:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=XpBrqjwbTAkxBtlK0+iz835los8t1lsZ6sd32A9j0nQ=; b=tT2s+wfo3PhZPWFg/rJdAEgCYxp5BF/LLvPrgqZDb/JuQJ76HyHEMjNt0Hq7jYh6Yg t4GWaXtllk2ZujMdcj6hbE5SWfkx2+GFp/bJYT7DTINfgMvDauoJoPozhdhpfD+gxZ3S GyhH7sbVoteKfa46rHWTr7KwYE41tECIpViJBPk2JomsHey1SjgJlvnAWPwwlBVBNBDt rheasbwy7nsum/Ho2Rp4FxO+JKrbmenQ9CBwZaYPRmOKy+y6NNQy5i2I2IpQSpFKZbbz SJw+T04Zn38V2bvd5ZsMzfh8dpEv8rMEPUMSvOxQY2oHMglqXFgOEOa1PZd+xN7z0lWT Dhhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=XpBrqjwbTAkxBtlK0+iz835los8t1lsZ6sd32A9j0nQ=; b=sab8hfxshcffmUFMLr9P7a5P7Wmsu2Yf0ePbVLL3jwuyggwLrEh68eotz6hrFge2e+ fpeta0nzRigGJdXN+ja7RcPfznqkugESUYpyscmTY3D96/1hHL9wLwt21ufn38FPlO3R PjjC4rnpLDE9r8ClAuoiLj0/1JlAhb2OrHehgUDia9RZkFwDz2BXG9nsWy+pUHoMAsWQ dnarbNO7qgunR+g36s9x6mm256kXddZyzvvSxDs5GVYQxXozt4fcALeeI0n7Gvnpj3C+ TAValabMTBwRPXZyGcdg1q6FRq8ubHgk1asb3D2Hy6bnORc+HNFp3EuYI4IQj7uRqyQf Zz8w== X-Gm-Message-State: AODbwcBoLLO2uRXrS/WW5qHhOOaYWWNv4Y1rmPQVhoFRy4QXKL+0ZMK/ x7eyyCUm4N9cdm2gqDl2tRHw3jc0lo0cyvA= X-Received: by 10.55.189.130 with SMTP id n124mr1053469qkf.235.1494545114009; Thu, 11 May 2017 16:25:14 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Thu, 11 May 2017 16:25:13 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 11 May 2017 16:25:13 -0700 X-Google-Sender-Auth: KCajTceGIMiLVsedzp9RlOQfads Message-ID: To: tjw ietf Cc: dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 23:30:06 -0000 At Thu, 11 May 2017 06:57:51 -0400, tjw ietf wrote: > There was a lot of consensus during our last meeting in Chicago that this > should move forward, so it's time that we do so. > > This starts a Call for Adoption for: > draft-kristoff-dnsop-dns-tcp-requirements > > The draft is available here: > https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirement= s/ > > Please review this draft to see if you think it is suitable for adoption = by > DNSOP, and comments to the list, clearly stating your view. I've read draft-kristoff-dnsop-dns-tcp-requirements-02. I don't have a strong opinion on whether dnsop should adopt it. It's a well-written, technically sound document, but I don't see something substantially new in it. I think RFC7766 already pretty clearly states TCP is a MUST. While some additional clarification provided by this draft may also be useful, I'm personally not convinced that it's sufficiently substantial that justifies the overhead and resource consumption of the wg. If this were a yes-or-no vote, I'd probably vote for 'no'. That said, I wouldn't be opposed to adopting it either, and if it's adopted I'm willing to review subsequent versions. > Please also indicate if you are willing to contribute text, review, etc. Finally, a few comments on the current version: - Section 2.2 At least two new, widely anticipated developments were set to elevate the need for DNS over TCP transactions. The first was dynamic updates defined in [RFC2136] and the second was the set of extensions collectively known as DNSSEC originally specified in [RFC2541]. The former suggested "requestors who require an accurate response code must use TCP", [...] I'm not sure if DDNS update bolsters the need for TCP. In my understanding DDNS update exchanges are largely done over UDP today (e.g., ISC's nsupdate utility uses UDP by default): =E2=88=92v Use TCP even for small update requests. By default, nsupdate use= s UDP to send update requests to the name server unless they are t= oo large to fit in a UDP request in which case TCP will be used. And I don't see any new trend that changes this practice. - Section 3 o Recursive servers (or forwarders) MUST service TCP queries so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients. The term "forwarder" can be ambiguous (see, e.g, RFC7766). You might want to use a different term to be clearer. -- JINMEI, Tatuya From nobody Fri May 12 03:41:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723E12EA54 for ; Fri, 12 May 2017 03:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 mlMvyziSQy-2 for ; Fri, 12 May 2017 03:41:46 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 CFA9F12EAA1 for ; Fri, 12 May 2017 03:35:29 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45041) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1d97uw-000MuA-dc (Exim 4.89) (return-path ); Fri, 12 May 2017 11:35:26 +0100 Date: Fri, 12 May 2017 11:35:26 +0100 From: Tony Finch To: =?UTF-8?B?56We5piO6YGU5ZOJ?= cc: tjw ietf , dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-244749770-1494585326=:2058" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 10:41:50 -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. --1870870841-244749770-1494585326=:2058 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > I'm not sure if DDNS update bolsters the need for TCP. In > my understanding DDNS update exchanges are largely done over UDP > today (e.g., ISC's nsupdate utility uses UDP by default): Well, that depends on the transaction size :-) My servers fairly frequently handle updates containing hundreds or records. And `nsupdate` basically assumes that TCP is available - it doesn't give the caller a way to find out what the server's maximum update size is. (Similarly, my `nsupdate` wrapper `nsdiff` also assumes transactions can be up to 64KB in size.) So I think you'll be sad if you try to deploy an UPDATE server without TCP. Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: Southwest 5 to 7 veering west 4 or 5. Moderate or rough, becomin= g moderate. Thundery showers. Good, occasionally poor. --1870870841-244749770-1494585326=:2058-- From nobody Fri May 12 04:51:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111DF12EB68 for ; Fri, 12 May 2017 04:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, 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 IUjXCzDUD5_a for ; Fri, 12 May 2017 04:51:26 -0700 (PDT) Received: from aharp.iorc.depaul.edu (aharp.iorc.depaul.edu [140.192.218.132]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2C128A32 for ; Fri, 12 May 2017 04:45:53 -0700 (PDT) Received: from p50.localdomain (localhost [127.0.0.1]) by aharp.iorc.depaul.edu (Postfix) with ESMTP id 8CD83199C; Fri, 12 May 2017 11:45:52 +0000 (UTC) Date: Fri, 12 May 2017 06:45:52 -0500 From: John Kristoff To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: tjw ietf , dnsop Message-ID: <20170512064552.5910d314@p50.localdomain> In-Reply-To: <7d22771823c74fdd86e99340f1b9464c@XCASPRD01-DFT.dpu.depaul.edu> References: <7d22771823c74fdd86e99340f1b9464c@XCASPRD01-DFT.dpu.depaul.edu> Reply-To: jtk@aharp.iorc.depaul.edu MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 11:51:28 -0000 On Thu, 11 May 2017 23:25:13 +0000 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I've read draft-kristoff-dnsop-dns-tcp-requirements-02. Thank you for taking the time to read, review, and comment on it! > I think RFC7766 already pretty clearly states TCP is a MUST. IETF RFC 7766 does very explicitly declare TCP is a MUST in the context of DNS implementation. It is also very explicit about not declaring this to be so from an operational standpoint, although with a strong warning about the consequences. The last paragraph is Section 1 in that document is the operative text. It was that in addition to my own operational and teaching experience I felt made this draft necessary. I tried to make this case at the meeting in Chicago and elsewhere that this is an important distinction that matters. I can try to make this case more compelling and convincing in the text. > I'm not sure if DDNS update bolsters the need for TCP. [...] > And I don't see any new trend that changes this practice. I see Tony has chimed on this so I'll simply add that the goal of Section 2 was not necessarily intended to make or bolster the modern argument for carrying DNS over TCP. In fact, the purpose was to help show how it is difficult to conclude one way or another whether carrying DNS over TCP is an operational requirement or not. I can make this objective more explicit at the beginning of that section. > The term "forwarder" can be ambiguous (see, e.g, RFC7766). You > might want to use a different term to be clearer. Thanks again, I can try to make the wording and meaning more precise. John From nobody Fri May 12 05:21:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9E12741D for ; Fri, 12 May 2017 05:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6ByonGzXbvlN for ; Fri, 12 May 2017 05:21:38 -0700 (PDT) Received: from atl4mhob02.registeredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) (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 23DE512EB3A for ; Fri, 12 May 2017 05:16:52 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob02.registeredsite.com (8.14.4/8.14.4) with ESMTP id v4CCGoYt015009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 May 2017 08:16:50 -0400 Received: (qmail 3812 invoked by uid 0); 12 May 2017 12:16:50 -0000 X-TCPREMOTEIP: 88.128.80.77 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.53.150.208?) (lee@asgard.org@88.128.80.77) by 0 with ESMTPA; 12 May 2017 12:16:49 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 12 May 2017 08:16:42 -0400 From: Lee Howard To: Paul Vixie , John Levine CC: Message-ID: Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt References: <20170511165852.34338.qmail@ary.lan> <59149F29.6090908@redbarn.org> In-Reply-To: <59149F29.6090908@redbarn.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 12:21:41 -0000 On 5/11/17, 1:28 PM, "DNSOP on behalf of Paul Vixie" wrote: > > >John Levine wrote: >>>>> In my experience, without reverse DNS it is essentially impossible >>>>>to have >>>>> mail delivered to the internet at large. >>>> Yes. >>> since this isn't an ideal or intended state of affairs, let's consider >>> the size and shape of the box, not just what's in there. >>=20 >> What would be the operational advantage of accepting mail from IPv6 >>hosts >> too lame to set up rDNS? > >we will never know, because every v6 end system will have a ptr, either >naturally, or machine-generated for it, because v6 providers will not >want their rank-and-file v6 endsystems to be excluded from important >activities such as transmitting e-mail. If =B3v6 provider=B2 includes =B3residential ISP=B2 (the topic and audience for this draft), then the inability to transmit email is by design. That is: ISPs commonly prevent residential users from sending email (by default). They say this in their Terms of Service, they block port 25, and they don=B9t publish PTRs. This is consistent with recommendations by M3AAWG[1] and BITAG[2], for instance. [1]=20 https://www.m3aawg.org/sites/default/files/document/MAAWG_Port25rec0511.pdf =20 [2] https://www.bitag.org/documents/Port-Blocking.pdf I=B9m pretty sure this is a consensus position. > >the operational advantage of not having ptr's for rank and file end >systems is much easier to explain, except to v6 endsystem providers. People who run mail servers generally understand these limitations. The BITAG paper does recommend clear disclosure and methods to opt-out. Makes sense to me: I want a human decided they want their system to send mail, not a bot. Lee From nobody Fri May 12 08:30:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD912F4B2 for ; Fri, 12 May 2017 08:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fn_uVnbv0S5V for ; Fri, 12 May 2017 08:30:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCB812741D for ; Fri, 12 May 2017 08:25:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y201so50630504qka.0 for ; Fri, 12 May 2017 08:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MsuKVqVPqjtgSpVVPCEIhaCwzGqK2ODMzDgIwKw/zHY=; b=SOPwmdTe3zp9bfQSx/NuGJGWeTsyIMuXkRaGsira/jnHuk8pe0wQNOkANERf+JWer/ Yyf9TQUQ/UkiMzQszDh1yuqNywE2yM0wCEo79R/rRVsgMEp6UEWgkN07xXmVQz3oamvj AUD0EU+EeJYPZrqMnh0ettmhY9e/zsTYjM7Iko/yQFFjmQSec1JwiE3Zp8aMIDT8xanf eABHOjMaYv1seA8ShJ2Upq1dY+IrHP0ssmUMIKyJFWJO/8P9HyakwikIxnin/H/tSBOs OBpqOqcp3uC1umHIeOGTK49KiXR2yKwBrbf7ZW89qv/ZtlmHvM0WirTHrtOjZFK3f75U FESQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MsuKVqVPqjtgSpVVPCEIhaCwzGqK2ODMzDgIwKw/zHY=; b=Ygl1exDhEKD99apqaba7Nw0wNvVXe3u152GOgpHwfOZLMA8rwwgfh9cxusr/Y2I8Gx g6+B31Pvc2zoH2Zq3m/0JziDFW2olTH4ln+ZiydlOFutti1Vt1/faycKQi1+TM1ou3q+ i+jvPGjPZeS3CtuQ1CZDvQWWdCwgzSqC7GBx+wIZBC4nFinuqv5Qoj2RSxWqbx96bscP cOF7+jBRGTG8ZZweo1CouE9oYTgMQ01cwrXWISl795zEy24We0GIka8AyqAU8FS4ZG+B Gc349lpkDSEmTeFKwBm0mAnFpF4fgxjDyEdzDGD0SkA9z6LtI9wojBDeMDBJo6mkYDyD gyIg== X-Gm-Message-State: AODbwcAPmVNybRjJFHRGN8fDNA5Z5jZrK/Eov5z4/oMEixXD5AvixKjH ejsqgO27boTItb8/ccLwax/DULNj0OuyoS8= X-Received: by 10.55.123.132 with SMTP id w126mr3862286qkc.311.1494602741298; Fri, 12 May 2017 08:25:41 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Fri, 12 May 2017 08:25:40 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 12 May 2017 08:25:40 -0700 X-Google-Sender-Auth: ZkrW3dcPFTXGcFn281lbQD2xa38 Message-ID: To: Tony Finch Cc: tjw ietf , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:30:31 -0000 At Fri, 12 May 2017 11:35:26 +0100, Tony Finch wrote: > > I'm not sure if DDNS update bolsters the need for TCP. In > > my understanding DDNS update exchanges are largely done over UDP > > today (e.g., ISC's nsupdate utility uses UDP by default): > > Well, that depends on the transaction size :-) My servers fairly > frequently handle updates containing hundreds or records. > > And `nsupdate` basically assumes that TCP is available - it doesn't give > the caller a way to find out what the server's maximum update size is. > (Similarly, my `nsupdate` wrapper `nsdiff` also assumes transactions can > be up to 64KB in size.) > > So I think you'll be sad if you try to deploy an UPDATE server without TCP. I didn't make that comment to say we can deploy DDNS without TCP. Citing the draft text again: At least two new, widely anticipated developments were set to elevate the need for DNS over TCP transactions. The first was dynamic updates defined in [RFC2136] and the second was . The former suggested "requestors who require an accurate response code must use TCP", while the later This read to me that DDNS elevates the need for DNS over TCP as RFC2136 suggests to use TCP for an accurate response code (because TCP is reliable but UDP isn't) and requestors are actually following that suggestion. My comment was to point out that this is probably not the case in today's common practice: I suspect many requestors don't too much worry about this particular point and don't really use TCP at least for that reason by overriding utilities' default. Of course, in some deployments the transaction size can be quite large and require TCP. I don't know how common such a deployment is, but regardless of that, I don't think the current draft text tries to say that. If the actual intent is that large DDNS transactions can require TCP, it should simply say so (it doesn't have to cite the above suggestion of RFC2136; it's even a confusing distraction in that sense). And, to that end, it's not even specific to DDNS. Even a normal query response can be too large to fit in a UDP message even with EDNS(0). So, in summary, I basically try to say I don't see anything special about DDNS here. Anyway, this is a pretty minor technical detail. I don't think it affects the overall quality of the draft very much. -- JINMEI, Tatuya From nobody Fri May 12 08:52:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5212EBE2 for ; Fri, 12 May 2017 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iKxqe1773mf0 for ; Fri, 12 May 2017 08:52:39 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A61112EB23 for ; Fri, 12 May 2017 08:47:01 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id l7so9246476qte.1 for ; Fri, 12 May 2017 08:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UOHUe7qGH3QPcj0irQ5RywR9OMQxzkaejKST+LxbTGw=; b=Zql6faqCbIWRwjepJr0av4QqPxkkKcN/Nh5UMdTqferK6QIrNS3Se+GPTRzSTc9waw 4NYRcU7vLgcM3xwkGrFeCWb6DMfET6YAlYkiLejpPjMv1B58Miy9/AxSNgiG6tuSOvDf 99kbLj1GRLjmjeEZYf5QzplxEe5pBdBoqOofcA24oWRkQsXdFe7XaSWhpbjB9vtM4/ke k+dp73XXZk8XxSFsdnKgujz0b9IabUmEYyYJIkZGAwDRF8lXsNzaJ/KOrTuDe6e61o6i 2n1i4oVbqSN0zWzfiosBfQ6uXvq3ELH07aFOt75eJzMWUdmAZOXKEf8bLJhGivaWlCyo wbPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UOHUe7qGH3QPcj0irQ5RywR9OMQxzkaejKST+LxbTGw=; b=gwtY8Pj/gAmOxm8bh+ILariOslLh4IVTHwHvfYyh/DJRScd1rs2JZsHiVQ9DvWZZWk kkBqp7Gh80iKvHidiD6IMjNP5DCOc+QqQJ/0jWWknfeMUGdDNBeovd/V/44Ty3Z4sAqE vyv/0DADWwUUPMOUAhAbd0zlTb1VOW+nZ9BB7gbnj9z6EM+VB4avVdbu/j7EBcKNyzsU NBraOesiKn4pIWdsvNYoqv6YBRyRUoSof2c60hzU6LF0cobhZPPcndNO7Fo+dkWY/pBj efM/vqdMEzaKApntrUcQUsA/YxYp9vReU5aSYVvx2/YmCSgMNvL3DxjCw5iW0Bb+T27X SkRg== X-Gm-Message-State: AODbwcAXfhWUYIq3cxxCgfBFfCRkUHSGeVKxNkam3FBh3ZfWvNG3lTFf 42J2AVrBobCMg5RC6oufoqQVC9XTqQ== X-Received: by 10.200.46.10 with SMTP id r10mr4189857qta.290.1494604020449; Fri, 12 May 2017 08:47:00 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Fri, 12 May 2017 08:46:59 -0700 (PDT) In-Reply-To: <20170512064552.5910d314@p50.localdomain> References: <7d22771823c74fdd86e99340f1b9464c@XCASPRD01-DFT.dpu.depaul.edu> <20170512064552.5910d314@p50.localdomain> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 12 May 2017 08:46:59 -0700 X-Google-Sender-Auth: xtJ9yQnK1t3TxGEl7aF3QhqQ-ns Message-ID: To: jtk@aharp.iorc.depaul.edu Cc: tjw ietf , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:52:41 -0000 At Fri, 12 May 2017 06:45:52 -0500, John Kristoff wrote: > > I've read draft-kristoff-dnsop-dns-tcp-requirements-02. > > Thank you for taking the time to read, review, and comment on it! > > > I think RFC7766 already pretty clearly states TCP is a MUST. > > IETF RFC 7766 does very explicitly declare TCP is a MUST in the context > of DNS implementation. It is also very explicit about not declaring > this to be so from an operational standpoint, although with a strong > warning about the consequences. The last paragraph is Section 1 in that > document is the operative text. It was that in addition to my own > operational and teaching experience I felt made this draft necessary. I > tried to make this case at the meeting in Chicago and elsewhere that > this is an important distinction that matters. I can try to make this > case more compelling and convincing in the text. I understand this draft tries to focus on an operational standpoint. It states the intent pretty clearly. It's just that I wasn't convinced about the need to publish a separate RFC for that purpose with all the overhead. But, if a new version provides more compelling arguments about the need it might change my mind. And, in any case, I wouldn't be surprised if others see stronger need for a separate operational document - it can be quite subjective. That's why I said I wouldn't be (necessarily) opposed to > > > I'm not sure if DDNS update bolsters the need for TCP. > [...] > > And I don't see any new trend that changes this practice. > > I see Tony has chimed on this so I'll simply add that the goal of > Section 2 was not necessarily intended to make or bolster the modern > argument for carrying DNS over TCP. In fact, the purpose was to help > show how it is difficult to conclude one way or another whether carrying > DNS over TCP is an operational requirement or not. I can make this > objective more explicit at the beginning of that section. Regarding this, see my followup response to Tony. -- JINMEI, Tatuya From nobody Sat May 13 05:20:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DEA120454 for ; Sat, 13 May 2017 05:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 HYXiInhf9g1g for ; Sat, 13 May 2017 05:20:02 -0700 (PDT) Received: from mango.plexis.eu (mango.plexis.eu [77.72.150.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CA8126FB3 for ; Sat, 13 May 2017 05:19:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mango.plexis.eu (Postfix) with ESMTP id 921EBECB for ; Sat, 13 May 2017 14:19:18 +0200 (CEST) Received: from mango.plexis.eu ([127.0.0.1]) by localhost (mango.plexis.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iOB5hutkPrw for ; Sat, 13 May 2017 14:19:16 +0200 (CEST) Received: from aardbei.mobile.plexis.eu (unknown [195.77.54.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mango.plexis.eu (Postfix) with ESMTPSA id B28063AD for ; Sat, 13 May 2017 14:19:16 +0200 (CEST) Date: Sat, 13 May 2017 14:19:13 +0200 From: Pieter Lexis To: dnsop@ietf.org Message-ID: <20170513141913.75398443@aardbei.mobile.plexis.eu> In-Reply-To: References: X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 12:20:04 -0000 Hi Tim et al., On Thu, 11 May 2017 06:55:55 -0400 tjw ietf wrote: > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I support the adoption of this draft by the working group. I have some reservations on the requirements for recursors in this draft, but this will be discussed at length I believe. > Please also indicate if you are willing to contribute text, review, etc. As Peter is a direct colleague of mine, I will not supply a review, but am willing to provide text. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com From nobody Sun May 14 03:16:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED19129B08 for ; Sun, 14 May 2017 03:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 K8FzCGKqYXhd for ; Sun, 14 May 2017 03:16:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 01444129B17 for ; Sun, 14 May 2017 03:14:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1d9qWq-0000DcC; Sun, 14 May 2017 12:13:32 +0200 Message-Id: To: dnsop@ietf.org Cc: Lee Howard From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20170511165852.34338.qmail@ary.lan> <59149F29.6090908@redbarn.org> In-reply-to: Your message of "Fri, 12 May 2017 08:16:42 -0400 ." Date: Sun, 14 May 2017 12:13:30 +0200 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 10:16:24 -0000 >>we will never know, because every v6 end system will have a ptr, either >>naturally, or machine-generated for it, because v6 providers will not >>want their rank-and-file v6 endsystems to be excluded from important >>activities such as transmitting e-mail. > >If =B3v6 provider=B2 includes =B3residential ISP=B2 (the topic and audience= > for >this draft), then the inability to transmit email is by design. >That is: ISPs commonly prevent residential users from sending email (by >default). They say this in their Terms of Service, they block port 25, and >they don=B9t publish PTRs. This is consistent with recommendations by >M3AAWG[1] and BITAG[2], for instance. >People who run mail servers generally understand these limitations. The >BITAG paper does recommend clear disclosure and methods to opt-out. Makes >sense to me: I want a human decided they want their system to send mail, >not a bot. I wonder if with the EU netneutrality laws it is possible to have a blanket block if port 25 outbound. Historically, many ISP that wanted to upsell business accounts would actually block port 25 inbound. Which does prevent relays but not bots sending spam. Of course having an option where the customer can request to port to be opened and then have it closed by default is best. But that may be too expensive for many ISPs. But my goal was not to say something about whether port 25 should be blocked or not. But just that based on todays internet and spam filtering, if an ISP allows customers to send mail, then the ISP has to provide the customer with a way of setting up reverse DNS. I don't really care whether a reverse DNS check is good or bad when it comes to filtering spam. It is just a reality that enough parties are using such checks that without reverse DNS you have a serious issue getting mail delivered. From nobody Mon May 15 07:57:26 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC17129B8B; Mon, 15 May 2017 07:57:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149486024486.11940.15684743124758238626@ietfa.amsl.com> Date: Mon, 15 May 2017 07:57:24 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 14:57:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Special-Use Domain Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-04.txt Pages : 27 Date : 2017-05-15 Abstract: The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-04 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 15 15:45:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B491294C8 for ; Mon, 15 May 2017 15:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 A6gclfOziw9v for ; Mon, 15 May 2017 15:45:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 8D57D126D85 for ; Mon, 15 May 2017 15:42:31 -0700 (PDT) Received: from [10.20.67.175] (104.red-83-48-50.staticip.rima-tde.net [83.48.50.104]) by mail.nic.cz (Postfix) with ESMTPSA id 4D62060187 for ; Tue, 16 May 2017 00:42:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1494888149; bh=t7bKVwUVWXqT6fIcTwmoukL3oR8PuYhlSiUZKmSoHx4=; h=To:From:Date; b=oJ/bo2D5kwPrnXcYt+4cxrdwxx+JJ+gVdsUhjEF0UbrVQGOD8BijDB9rADIofYN9U nwOmvaocJ8/HTQ3YUaSFD6pjHK/SCFc71IFI6wtz/SN7//gEj98xlloOlLvp8ldgb5 cl3Qc56Dpz1rMXle1NWngUd6bO5GtXawaJug3DT0= To: dnsop@ietf.org References: <20170410093847.GA21654@jurassic> <20170410150917.GA22210@jurassic> <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <904cda8d-50eb-b49d-30af-a33cb7155893@nic.cz> Date: Tue, 16 May 2017 00:42:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <36190869-0215-4BA9-AF9E-297CA4035849@ogud.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 22:45:10 -0000 On 5.5.2017 14:30, Olafur Gudmundsson wrote: > >> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman > > wrote: >>> >> >> We kind of restarted the draft adopting RSASSA-PSS, so please can you >> review it this time from scratch without looking at the diff? >> >> Many of the examples will need updating once algorithm numbers are >> assigned for them (as for some calculations, the algorithm number is an >> input), so we didn't spend time on wrapping the long lines in this >> revision. >> > > Ok I will bite and be the grumpy old man. > > I strongly advocate against the adoption of this document in current from. > It violates basic interoperability guidelines by defining way to many > algorithms with no justification why any of them are better or worse > than others. > There is no useful guidance on why these new algorithms are better even > among themselves. > > One of the biggest hurdles to deployment is not in the 5-20 DNS software > packages in wide use; but in all the 1000’s of Provision systems around > the world, > and the crypto libraries found on various Enterprise systems that have > life time of 4-8 years with security-only updates. > Lets learn the lessons documented > in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 > > I’m not convinced that SHA3 vs SHA2 matter at all given the constraint > small data with strict constraints on order and contents is being signed. > > Thus why define > - 5 new RSA algorithms proposed, why why ? ? > - 2 new ECDSA algorithms proposed why why ? ? > In another document there 2 other algorithms being proposed at the same > time, that I support as they represent new and > faster technology. > All this will do is to cause confusion! > > The RSA KEY size allowed for these new supposed stronger Digest > algorithms is still left at 1024 or 1280 bytes, even though number of > other parts of the the Internet community will not consider signatures > by keys with less than 2048 bits. > > If there is any reason to go down the path of this document it should > pick ONE RSA and ONE ECDSA algorithm. > RSA should be defined sensible guidelines on key sizes; i.e. no keys > below some stronger value in the 1536-2048 byte range. > > The document is proposing two new DS algorithms WHY? > The basic reason for new a DIS digest algorithm is “much better” so > pick one and live with it. > > There was an interesting discussion on a resolver software mailing list > few weeks back about what the RFC’s mean when there are DS records with > different digest > algorithm numbers: A domain had 2 DS records one with digest 1 one with > digest 2; > They both referred to the same key, but there was a typo/error in the > digest with algorithm 2; > Question what should the validator do ? > a) only trust the highest digest number? > b) trust any DS record ? > I.e. a higher number was interpreted by the implementor to mean better > thus only the highest supported number was the only one tried. > > Additionally this document in its current form contains proposed > algorithm values which IMHO is a NoNo and I hope is removed from future > versions. > If there are interoperability tests you can define the numbers you want > to use on web page; not in an internet draft that someone may go ahead and > implement not realizing that the final RFC will have a different number(s). > > Olafur Very well said, Olafur. I'm also against adoption of this document in its current form. -- Petr Špaček @ CZ.NIC From nobody Tue May 16 09:36:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92115129AD2 for ; Tue, 16 May 2017 09:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=depht-com.20150623.gappssmtp.com 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 Xd1-AAn1LChm for ; Tue, 16 May 2017 09:36:07 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D469D12EC0A for ; Tue, 16 May 2017 09:31:55 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id d127so126353913wmf.0 for ; Tue, 16 May 2017 09:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht-com.20150623.gappssmtp.com; s=20150623; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=mxbG3mYO4LCV9hqkF+THOQ8y8YQ8IdsLzPRniUFLtq0=; b=D8dAFWyncA8Jn+0vUlckq2JKDBiJY7YWeJjIfYuTjszQS1GGm/Ozpe5URisfTVevY6 njUr+ToLCXkaJ45vP69KUcCPON+5ju7+AUmBEhkI71+c95LeQCOrGL8zrapZtF0Yz0De Ww2vgTjmRJqgzq/SbqYdekS8eUXzgKdwpBnycJlpbw51zz5ProsoDw+iiFm5xdOTZyUT eE01JAMM2rPtww4QGXyoF1DxufiiWFWkPXqtt3ba2Np1C3IU4vxDxMP/A8JCWzyUP3um yeEpWE+cdgAAG5vQsZg7GJJhL8ybF1+l8Ais/D3+uDsG7SkL128mP9YU0zlPhe8iBmKp +LmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=mxbG3mYO4LCV9hqkF+THOQ8y8YQ8IdsLzPRniUFLtq0=; b=DeRTO7ykXZuDypd4/U5VL19E5eqs3sZYsCqaC2NfZnzv5opllQdlPFvCrwl0q419Xr /pOMql6FxBmxPJ/1bw1CzRcZ94org7K5Yoka0+spyac/k8Ow+S93S/ikJGl2MGiUZysE Gij9pNnK1M7wn5q52l9xT9EFr+KwwiJJrxMvZQdnJqWnkRP2W3xoixmYD07gAADX3iuH 41VUyMU61hn/rInLGrECK+tXMf3oXl+vCRoAFizWGqn3B1tqrHbiXcJnfw+n7BAe+nl5 yuQZ9b1yr34voEzDMrzfq+ai21baOkzegJmU+2PB+jVnPixzueRRrEh6dLo0XC9ApK+d oFfA== X-Gm-Message-State: AODbwcBmvSIUPXGcFgNsW3ORK7fYwLxQvLmegLiAmh4ZR8Kg84Y6XdF6 AFa4cbMNj4L0dcNU1UE= X-Received: by 10.28.143.70 with SMTP id r67mr7474596wmd.1.1494952314035; Tue, 16 May 2017 09:31:54 -0700 (PDT) Received: from ANMC-3678.local ([2601:143:8003:2fd0:215a:b42c:5bfc:8316]) by smtp.gmail.com with ESMTPSA id w186sm3827540wme.26.2017.05.16.09.31.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 09:31:53 -0700 (PDT) References: <149486024486.11940.15684743124758238626@ietfa.amsl.com> From: Andrew McConachie To: dnsop@ietf.org Message-ID: <385cc66e-4919-04ce-ab27-feca3537ae07@depht.com> Date: Tue, 16 May 2017 12:31:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <149486024486.11940.15684743124758238626@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:36:09 -0000 On 5/15/17 10:57, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Special-Use Domain Names Problem Statement > Authors : Ted Lemon > Ralph Droms > Warren Kumari > Filename : draft-ietf-dnsop-sutld-ps-04.txt > Pages : 27 > Date : 2017-05-15 > > Abstract: > The Special-Use Domain Names IANA registry policy defined in RFC 6761 > has been shown through experience to present unanticipated > challenges. This memo presents a list, intended to be comprehensive, > of the problems that have been identified. In addition it reviews > the history of Domain Names and summarizes current IETF publications > and some publications from other organizations relating to Special- > Use Domain Names. > > The use of the term 'meaning' in this document is problematic. Meaning is something that humans do, not machines. What I believe we're actually interested in is scoping and binding. How a name is scoped and what object it gets bound to, not what it means. For example the text: "Domain Names with unambiguous global meaning are preferable to Domain Names with local meaning which will be ambiguous. Nevertheless both globally-meaningful and locally-special names are in use and must be supported." Should probably be changed to: "Domain Names with unambiguous global bindings are preferable to Domain Names with local bindings which will be ambiguous. Nevertheless both globally-scoped and locally-scoped names are in use and must be supported." This is more akin to how programming language designers discuss this subject.[1] I don't want to delve into the usage of 'meaning' in RFC 2826 itself, but there are a couple other uses of 'meaning' in this I-D that I believe should be removed, and I am happy to send text if people agree. I'm also worried that some readers of this document might interpret its use of 'global' or 'local' in a geographic sense, and not a scoping sense. But I don't know how to deal with this. Perhaps it's just a risk. Thank you for all your hard work on this, Andrew [1] https://www.python.org/dev/peps/pep-0227/ From nobody Tue May 16 12:03:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06A0129C67 for ; Tue, 16 May 2017 12:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 kzESHkahPEiR for ; Tue, 16 May 2017 12:03:55 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F3612EAB0 for ; Tue, 16 May 2017 11:59:26 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id y201so138419164qka.0 for ; Tue, 16 May 2017 11:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qp0A/qbfF8M5SrpqvBA9pS4ULFwU3pv0jdBpAKnyw+M=; b=UCNJNAmUK2QInJ9faGHzdQi/WHwMdXfHczBT8yNIW2yKsTJ+J3ho0TRQGQPoU3n9Me XkRvGq2JAnIHRqw9y4XchxuHOenuzpdrh8LEaKkZYwHbjPCWGkwHp1V5Gk1j0BVkXSL1 r57iHpVexLuC6QJB8L0lzTNP4MjayYpE/tFWSACSoqzNgjG83Ko6mXbAW2dZPDnkRkKs SkTGc8gBafcVpXsFiEBsv2kR+n3vN4nXBOpb3zm7/5Gl3JeWSdM8/2cL20QSbNgoQbIv uNqAA/iZph3/09c70S+mpCvQlieNK7+zLlqsfNNRJOWAPHMvwuGb/nOQStYF8ViXEbGH l7sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qp0A/qbfF8M5SrpqvBA9pS4ULFwU3pv0jdBpAKnyw+M=; b=N2T2tawX9hBz9qfwt2/bquPzS1lEGJlKBB3R3jtX6oZp+eDLdkW3RBVQwEiwfp+EFO 22eRaMQlL++D4SIz+2lHsyDc02V240yqw09THJ+NHoibIa/MCC8QyijOmqJPgjVqt1MM K/Q1nDTEv+oKqSkEqK6AmXgpSdTFP8FdIXPBBjKR8ZhjIgsHflqdxP5evBzuUdn3W/uq dOy6emxsTw7D1YHBYxUauTrGVKv5dh5h4n80+H0rsIokRssRZzRSLe7TyHdJN9hAEcYw tcYgJwpfoXj/x7Hx9bTfAqTOMC5dnM+TZ860Z4L7MK/ytnWtL79vNXw4r7Y0GHK1oOll tbBw== X-Gm-Message-State: AODbwcDc1cFr5KtoGGcbuLrYllpW95WYRo0E3r/xCRP92sgnfN6B9TYs HhPrNe9m13RHdQ== X-Received: by 10.55.33.70 with SMTP id h67mr12683825qkh.163.1494961165827; Tue, 16 May 2017 11:59:25 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id z53sm77460qth.43.2017.05.16.11.59.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 11:59:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <385cc66e-4919-04ce-ab27-feca3537ae07@depht.com> Date: Tue, 16 May 2017 14:59:23 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <78C25F2F-BD18-46CB-BB34-C58ABA79502A@fugue.com> References: <149486024486.11940.15684743124758238626@ietfa.amsl.com> <385cc66e-4919-04ce-ab27-feca3537ae07@depht.com> To: Andrew McConachie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 19:03:58 -0000 I think that "meaning" is more likely to be understood than "binding," = although I think your technical point is valid. Same with = global/local. I'll see if I can add some clarifying text. Thanks for = the review! > On May 16, 2017, at 12:31 PM, Andrew McConachie = wrote: >=20 >=20 >=20 > On 5/15/17 10:57, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Domain Name System Operations of the = IETF. >>=20 >> Title : Special-Use Domain Names Problem Statement >> Authors : Ted Lemon >> Ralph Droms >> Warren Kumari >> Filename : draft-ietf-dnsop-sutld-ps-04.txt >> Pages : 27 >> Date : 2017-05-15 >>=20 >> Abstract: >> The Special-Use Domain Names IANA registry policy defined in RFC = 6761 >> has been shown through experience to present unanticipated >> challenges. This memo presents a list, intended to be = comprehensive, >> of the problems that have been identified. In addition it reviews >> the history of Domain Names and summarizes current IETF = publications >> and some publications from other organizations relating to = Special- >> Use Domain Names. >>=20 >>=20 > The use of the term 'meaning' in this document is problematic. Meaning = is something that humans do, not machines. What I believe we're actually = interested in is scoping and binding. How a name is scoped and what = object it gets bound to, not what it means. >=20 > For example the text: > "Domain Names with unambiguous global meaning are preferable to > Domain Names with local meaning which will be ambiguous. > Nevertheless both globally-meaningful and locally-special names > are in use and must be supported." >=20 > Should probably be changed to: > "Domain Names with unambiguous global bindings are preferable to > Domain Names with local bindings which will be ambiguous. > Nevertheless both globally-scoped and locally-scoped names > are in use and must be supported." >=20 > This is more akin to how programming language designers discuss this = subject.[1] I don't want to delve into the usage of 'meaning' in RFC = 2826 itself, but there are a couple other uses of 'meaning' in this I-D = that I believe should be removed, and I am happy to send text if people = agree. >=20 > I'm also worried that some readers of this document might interpret = its use of 'global' or 'local' in a geographic sense, and not a scoping = sense. But I don't know how to deal with this. Perhaps it's just a risk. >=20 > Thank you for all your hard work on this, > Andrew >=20 > [1] https://www.python.org/dev/peps/pep-0227/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue May 16 14:47:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7512EAB0 for ; Tue, 16 May 2017 14:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 WhladYRyRGp4 for ; Tue, 16 May 2017 14:47:30 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BB2128AB0 for ; Tue, 16 May 2017 14:42:16 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id y201so142065076qka.0 for ; Tue, 16 May 2017 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B05iibLsV+NYKuYVJCoHZ+fB01ixEV7w5rgGI0evUxA=; b=Mag/sxxrc9VXfkG4SQBEXVY6xoybyxv4T8eH36NthLu3udqJGIXu8rSmfFcqjDenSS 23KiO++qvD7Eiorx2gxh0hzZ9c7j96Zfg+WzO/pvL1vyP1KoRnYXxbGJjzGlPRynzyGQ DfQ2o53uBms2hCr2aGRID6/szvC/N7Zdi9XGIEWwSwZn5uIP+vp+NTE+44A6++4TrEzD 7iP0xdBbcYeSCgpvumb2wKll8ytiQAG1W6ynfiulc6kNkphDcDG2c392uajI9Sgen1Yd VdDeLoCtkq9gPodDZIlUzyfrJqUdlBj8MPb6elJZ+hoEtMZTevqfWE734K02ilPDfXhC YmHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B05iibLsV+NYKuYVJCoHZ+fB01ixEV7w5rgGI0evUxA=; b=kZD2hhX/4gEco6uLRCYpGzdP1bDEbU3vBcy35V3e94VICDR5M6KLf6Dxz5TVWliLZZ fIyOgKbGgo5Udft/ztA87Cn6urj7k8hmhQD21JHyRd59h8JB7qhRcklkCBJztG0tsK5w Y9p1/bUSvMPzFrLZlHNVSrjYergPzOa06dvqw9zGQ7/V4vkrZvOC8SFm8VeVNAttk33W 4r5J5dnbxiAdbEb4TK+H+7hmK45exg0a7Ofg4B6E5xS7iuxF1wAjeW48ynNmgT8kSyur z+dhgqit6yp63geJ3hLocDVVSLIIW6PfB3HdGMCqaTGIjUKJrhXYNnCzqfrgeZ5t71Du 4iWQ== X-Gm-Message-State: AODbwcCQGk6w/Ra3/1ofH/DTMPRYXFuyzcjsHgHLEFvj5Ww5aAsarSFz PPjpvc1YJuSr46uD X-Received: by 10.55.154.138 with SMTP id c132mr53365qke.293.1494970935361; Tue, 16 May 2017 14:42:15 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d200sm26208qkg.50.2017.05.16.14.42.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 14:42:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <385cc66e-4919-04ce-ab27-feca3537ae07@depht.com> Date: Tue, 16 May 2017 17:42:13 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <639B527D-7263-4726-B992-05B329C40E31@fugue.com> References: <149486024486.11940.15684743124758238626@ietfa.amsl.com> <385cc66e-4919-04ce-ab27-feca3537ae07@depht.com> To: Andrew McConachie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 21:47:31 -0000 Would the following change address your concerns? Section 4.1.1., paragraph 3: OLD: o The Internet requires a globally unique namespace NEW: o The Internet requires a globally unique namespace: a namespace in which any given name refers to the same information (has the same meaning) no matter who requests that information and no matter from which specific name server they request it. Section 4.1.1., paragraph 4: OLD: o Private networks may operate private namespaces, but still = require that names in the public namespace be globally unique. NEW: o Private networks may operate private namespaces, with names that have meanings only locally (within the private network) but still require that names in the public namespace be globally unique. This is to the paragraphs preceding the one you commented on, but I = think it does a good job of introducing the concepts used in the = paragraphs you commented on, in a fairly natural way.= From nobody Wed May 17 10:52:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77A2129AB7 for ; Wed, 17 May 2017 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=depht-com.20150623.gappssmtp.com 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 GvpxSMdgWsRL for ; Wed, 17 May 2017 10:52:14 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B6E12EB28 for ; Wed, 17 May 2017 10:47:35 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id d127so24746282wmf.0 for ; Wed, 17 May 2017 10:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=YkUe/Ch0qqAmgJs4fKrFlz8TTfXrUvLjMK9pyDHtkog=; b=JgB66chH2xWDfOdq71YAaG1eCX9yEKU49H36l5Q6tgQweNtRRYau4BnZKufxxIsePM bgJ1yqRv3/qns4hJo7eOCwZuJaVeVMj0xDSPhogR3Q1M/GYeSJcYy1YCq9GSt6+dqmm/ uSa1ev2L21VJamRvxQQUa0WFoV4pDtp/CZhVY4EYXwWxBXmsg98Mvi31rwhKFUyMA/PG BhBw+FrJBFOm8D5/5a0KOskrS1BMOHudYuNKiEcbRK5u4eLGr6C+ID32nm6ZLKXSbLmW Y98u4SxBEG6hOO4qHyddoyGHbL13egiuTi4wKv5Hlt7yH0SMSJNHY6TyMaHkaGJmvfXm LvpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YkUe/Ch0qqAmgJs4fKrFlz8TTfXrUvLjMK9pyDHtkog=; b=sXvAeJaTn/VSf3v3yqMZBL5ky66FRHWkyfPmpDRC7bbol8U+spbVsmDF28fErxuo+g c+uZB6Mzngcgd91sef8Un6IPqSwjfL9tcA2aHpLtk2SjxD5EYEPQSKuFSX4kRvjaHF8a sBkRIzk44KUOMa/OWXEq+gi1mYbI/C5k/enFglweDLvZFKnl1l3ldyQFRmt7D1cf9s6b opY620Yq770tsHf7xoe/GWwPnXXhdJduxQRA317H/ElKoBD/wk0H/JY3IYOIJ99gTNvI YHo3O6dUHswTOET71wyLUK8Ko6MIEu6SL5BfDV4VJCL2HMpS3YxO5uLfnlr78hk9ewYD CVXg== X-Gm-Message-State: AODbwcDZJqKNKBhZ3Hf8I6wf7B4SexaOdxgoSi42Y972lZAm1aiTePkq 0ZqAWKFbWslSzd6PORQ= X-Received: by 10.28.178.201 with SMTP id b192mr3121094wmf.127.1495043254131; Wed, 17 May 2017 10:47:34 -0700 (PDT) Received: from ANMC-3678.local ([2601:143:8003:2fd0:450a:4ea0:e221:6b41]) by smtp.gmail.com with ESMTPSA id c37sm2800840wra.16.2017.05.17.10.47.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 10:47:33 -0700 (PDT) To: Ted Lemon Cc: dnsop@ietf.org References: <149486024486.11940.15684743124758238626@ietfa.amsl.com> <385cc66e-4919-04ce-ab27-feca3537ae07@depht.com> <639B527D-7263-4726-B992-05B329C40E31@fugue.com> From: Andrew McConachie Message-ID: <4d606b44-18db-f836-8a30-e8581ce8e15c@depht.com> Date: Wed, 17 May 2017 13:47:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <639B527D-7263-4726-B992-05B329C40E31@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 17:52:16 -0000 On 5/16/17 17:42, Ted Lemon wrote: > Would the following change address your concerns? > > Section 4.1.1., paragraph 3: > OLD: > > o The Internet requires a globally unique namespace > > NEW: > > o The Internet requires a globally unique namespace: a namespace in > which any given name refers to the same information (has the same > meaning) no matter who requests that information and no matter > from which specific name server they request it. > > > Section 4.1.1., paragraph 4: > OLD: > > o Private networks may operate private namespaces, but still require > that names in the public namespace be globally unique. > > NEW: > > o Private networks may operate private namespaces, with names that > have meanings only locally (within the private network) but still > require that names in the public namespace be globally unique. > > > This is to the paragraphs preceding the one you commented on, but I think it does a good job of introducing the concepts used in the paragraphs you commented on, in a fairly natural way. Yes. I think it makes clear to the reader what is _meant_ by 'meaning' throughout the document. Thanks, Andrew From nobody Fri May 19 04:52:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C714B12ECBD for ; Fri, 19 May 2017 04:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 kGRSPFRipOq3 for ; Fri, 19 May 2017 04:52:21 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FAF12ECBF for ; Fri, 19 May 2017 04:46:20 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id y190so10521071vkc.1 for ; Fri, 19 May 2017 04:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oerdDHblbdQcUgvqYa/va76QZd+pEDqFT3BWdzX4kZQ=; b=u5hUpdHFi9eHWFVHqpUXmATJ5KqaAPoqOFpJWEH86j3OiQQ5NaSvQ0LJOCYdZwnJz1 HwVu1r9Z55d6czScYIXTQceWZHWfcv9vQ8x1+S7Dsivcj8NS0yuEsUDytPeCGMbZzi3u cBM+VqIRSX0Kg3ccHpGq9flmXoijO1KBL1DLI9e77teXAj9OyBZl6VfQCkVz6g3qS+D1 oLl6xQuSw8ZiQDGqF/2MoT4Oc5Kinvj97MU9jDHf9MZhnVvHrdMxYSf0tL6VBZ4Rkb4h N8hv2u1yWJBsNX7BVlbZHClxDlAm4yXTsI6YpizsoFAa15QaVgBCSVAj0GdhkDldMDKP b1eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oerdDHblbdQcUgvqYa/va76QZd+pEDqFT3BWdzX4kZQ=; b=MijADkbEiccrWa4FOyL3Wlt4vmMoSCT0vdCEv0N+QQLHWMN+Yhav7kcFi6T1d5hC2j +MwOpRroWjOv5iJsfmgNWwMsZCHDmSNdbewhg/4v1FPMzrs6R0iLx8ajIaVFJjvUqSvb 7Fx3g2DNjZqxJKmI3j4euutEzrpn/PcN7pZMdaxM1nRdWcCNFseUIzht9ZMzLrHoqzTo vsPyAkpDcG00Y/HoEfMxEn3WByDIjGPHjmtTx0fMsokjLHMcdmcIpN/h4Q8VO1Oy27ff k1Jj+DVHLZgfGr5mtyj0F6afztdY9HgFGxGcYe1ySUZ7pFThey1jnUUW+KpnYZG3Ld41 kTbA== X-Gm-Message-State: AODbwcDTg87nQ7R0dOGeLgws7ak1GnFT+YPXwkYrbDZr6wUbikTjKPvS Y/CRLRmtkTbSRZONzTshZknoWGTCI9IPfFI= X-Received: by 10.31.191.21 with SMTP id p21mr1575641vkf.7.1495194379095; Fri, 19 May 2017 04:46:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Fri, 19 May 2017 11:46:08 +0000 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a114db288d626bc054fdf11a4" Archived-At: Subject: [DNSOP] Fwd: INVITATION: IETF Overview and Special-Use Domain Names Problem Statement Last Call Webex - Tuesday May 23, at 1700-1830 UTC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 11:52:24 -0000 --001a114db288d626bc054fdf11a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear DNSOP, Because the special use names topic has some overlap/ interest for ICANN, we wanted to invite ICANN participants to participate in the IETF last call. There will be a WebEx for this -- it won't really discuss the content of the SUTLD document (we want people to read the document itself), instead it will describe the IETF process and then how to provide feedback on the document (send mail to the list :-)) This is less likely to be useful for IETF participants (y'all already know the process), but the invite is below if you'd like to join. W W ---------- Forwarded message --------- From: David Olive Date: Tue, May 16, 2017 at 4:11 PM Subject: INVITATION: IETF Overview and Special-Use Domain Names Problem Statement Last Call Webex - Tuesday May 23, at 1700-1830 UTC To: soac-leaders@icann.org Cc: Warren Kumari , David Conrad , suzworldwide@gmail.com , Ralph Droms < rdroms.ietf@gmail.com>, Alissa Cooper , Duncan Burns < duncan.burns@icann.org>, Soininen, Jonne (Nokia - FI/Espoo) < jonne.soininen@nokia.com> INVITATION FROM THE IETF TO THE ICANN COMMUNITY *This session is intended to help the ICANN community understand the IETF process and productively participate in the discussion of a document on Special Use Names that may be of interest.* The DNSOP Working Group within the IETF has recently completed work on a problem statement document on Special-Use Domain Names (draft-ietf-dnsop-sutld-ps-03 - https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ ). The IETF will soon be initiating their final comment period for the document =E2=80=93 the IETF Last Call. The IETF would like to invite the ICANN community to share their input on the document. This session will start with an overview of the IETF last call process and how it works. It will then have a short summary of the SUTLD document, and describe how to provide comments. It would be helpful for participants to have read "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force" (https://www.ietf.org/tao.html ) * This session will be held via WebEx on Tuesday, May 23, at 1700 -1830 UTC. Webex participation details are included below.* *Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=3Dm1333532ce167e4a5a09b1d42d00= 2b632 (going to this link in advance of the meeting will allow you to generate a calendar invitation)* *Join by phone:* *1-877-668-4493 Call-in toll free number (US/Canada)* *1-650-479-3208 Call-in toll number (US/Canada)* *Meeting number: 310 638 156* *Meeting password: LastCall* --001a114db288d626bc054fdf11a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear DNSOP,

Because the special use names top= ic has some overlap/ interest for ICANN, we wanted to invite ICANN particip= ants to participate in the IETF last call.=C2=A0

T= here will be a WebEx for this -- it won't really discuss the content of= the SUTLD document (we want people to read the document itself), instead i= t will describe the IETF process and then how to provide feedback on the do= cument (send mail to the list :-))

This is less li= kely to be useful for IETF participants (y'all already know the process= ), but the invite is below if you'd like to join.

<= div>W

W


---------- Forwarded message ---------
From: David Ol= ive <david.olive@icann.org&= gt;
Date: Tue, May 16, 2017 at 4:11 PM
Subject: INVITATION: IETF Ove= rview and Special-Use Domain Names Problem Statement Last Call Webex - Tues= day May 23, at 1700-1830 UTC
To: soac-leaders@icann.org <soac-leaders@icann.org>
Cc: Warren Kumari <warren@kumari.net>, David Conrad <david.conrad@icann.org>, suzworldwide@gmail.com <suzworldwide@gmail.com>, Ralph Droms <= rdroms.ietf@gmail.com>, Ali= ssa Cooper <alissa@cooperw.in&g= t;, Duncan Burns <duncan.burns= @icann.org>, Soininen, Jonne (Nokia - FI/Espoo) <jonne.soininen@nokia.com>

<= br>

<= span style=3D"font-size:11.0pt">INVITATION FROM THE IETF TO THE ICANN COMMU= NITY

=C2=A0

This session is intended to help the ICANN communi= ty understand the IETF process and productively participate in the discussi= on of a document on Special Use Names that may be of interest.

= =C2=A0

=C2=A0 =C2=A0The DNSOP Working Group within the IETF has recently = completed work on

=C2=A0 =C2=A0a problem statement document on Special= -Use Domain Names

=C2=A0 =C2=A0(draft-ietf-dnsop-sutld-ps-03 -<= u>

= =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dns= op-sutld-ps/=C2=A0).=C2=A0 The

=C2=A0 =C2=A0IETF will soon be init= iating their final comment period for the document =E2=80=93 the=C2=A0

=C2=A0 =C2=A0IETF Last Call. The IETF would like to invite the ICANN commu= nity to share their input=C2=A0

=C2=A0 =C2=A0on the document.

= =C2=A0

=C2=A0 =C2=A0This session will start with an overview of the IETF = last call process and how it works.

=C2=A0 =C2=A0It will then have a s= hort summary of the SUTLD document, and describe

=C2=A0 =C2=A0how to p= rovide comments.

=C2=A0

=C2=A0 =C2=A0It would be helpful for part= icipants to have read "The Tao of IETF: A

=C2=A0 =C2=A0Novice'= ;s Guide to the Internet Engineering Task Force"<= /p>

=C2=A0 =C2=A0(https://www.ietf.= org/tao.html=C2=A0)

=C2=A0

=C2=A0 =C2=A0This session will = be held via WebEx on Tuesday, May 23, at 1700 -1830 UTC.=C2=A0 Webex partic= ipation details are included below.

=C2=A0=

Meeting = Link:=C2=A0https://ietf.webex.com/ietf/j.php?= MTID=3Dm1333532ce167e4a5a09b1d42d002b632=C2=A0(going to this link in ad= vance of the meeting will allow you to generate a calendar invitation)

=C2=A0

Join by phone:

1-877-668-4493 Call-i= n toll free number (US/Canada)

1-650-479-3208 Call-in toll numb= er (US/Canada)

=C2=A0

Meeting number: 310 638 156

Meeting password: LastCall

=C2=A0

=C2=A0

=C2=A0

--001a114db288d626bc054fdf11a4-- From nobody Fri May 19 06:02:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DF3129422 for ; Fri, 19 May 2017 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 W9J9-qePgeAl for ; Fri, 19 May 2017 06:02:00 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC6712EC91 for ; Fri, 19 May 2017 05:54:57 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l14so34329541ywk.1 for ; Fri, 19 May 2017 05:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ST4dKSILDhenCyzEkJqvqLBHAGqp9MgwQDS0x9U7qeA=; b=Qap82cP7ym8qA5NB8AZkGtJelKUFVs2YErAebA+YYhJ7TFbeJgvGJ3wKIxGchdkpoS 6feOzaMdFNZFdD1B5BItFaMK+jAu3O3IxlxnsArD1l/XzFEeiDzLPqVk+my+WVwI3xJB 1htAzkLdPMXlVy5qP4d0LO/DHlslkqMYv41XcdB/Tsq1HJlyKnk+TkiSonkDBdE/nuCm +6Ud8ri0Lr8iEsZMBA8a2Gl38pYQi3fDB/atDzN0WF9MoTqckv8Tirxdv+qYStZ7TfQy 8mKI6d1M7hOfzhSCY5Foh//icJrg3yVqkQP2B8GHDaD/TldRfIMGGlJfgxODN0esmoEH l/JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ST4dKSILDhenCyzEkJqvqLBHAGqp9MgwQDS0x9U7qeA=; b=LmEydTpRweSJPVeYMOoiY/tJa8Fx/scQNqBH4F5kwYexuhYu5E9swli/QdoSNfsqGs 5GHTT/fAHugHKnU5xUy+tqnS4OhwNUEW6cNA2pM34iKjqMzdnI2a3sNqw9z+LyZktRK9 QvlIdtSLaQYM4gjfx9+RTMTYXwo0oHgy60RypDrNaHakkdBnKzA7JBgItWM4ftksv+/1 l2xlsLCLxXuCFTeBlWZaVEAEsYZ5vMBuWuVY3q9N3OaZPsMOya5i+kWMb/uy5rUTG5ty V+AQ6O2i1/tmHWhOS6p09OHB0/S9NqwUk9wHtji3ZcDIKc1vIY37mGsDel3+DTmpeUBk n4sw== X-Gm-Message-State: AODbwcAmNhqvUIFfYMCSeiYhHHyhWpGdFiUX3dffUOdKGDnswe12/Rqx CP2EdXRS62QTby0MXuhDEoo44iewPekL X-Received: by 10.13.217.140 with SMTP id b134mr7881448ywe.4.1495198496617; Fri, 19 May 2017 05:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.161.148 with HTTP; Fri, 19 May 2017 05:54:56 -0700 (PDT) In-Reply-To: References: From: Bob Harold Date: Fri, 19 May 2017 08:54:56 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a114fb58e42acff054fe00723" Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 13:02:02 -0000 --001a114fb58e42acff054fe00723 Content-Type: text/plain; charset="UTF-8" On Thu, May 11, 2017 at 6:55 AM, tjw ietf wrote: > ... > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: https://datatracker. > ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: Midnight 25 May 2017 > > Thanks, > tim wicinski > DNSOP co-chair > I support adoption and will review. -- Bob Harold --001a114fb58e42acff054fe00723 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, May 11, 2017 at 6:55 AM, tjw ietf <tjw.ietf@gmail.com= > wrote:
= ...
This starts a Call for Adoption for:=C2=A0draft-hunt-dnsop-aname


Please review this draft to see if you thi= nk it is suitable for adoption by DNSOP, and comments to the list, clearly = stating your view.

Please also indicate if you are willing to con= tribute text, review, etc.

This call for adoption ends: Midnight = 25 May 2017

Thanks,
tim wicinski
DNSOP co-chair

I support adoption = and will review.

--=C2=A0
Bob Harold

--001a114fb58e42acff054fe00723-- From nobody Fri May 19 07:51:47 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D219128B91 for ; Fri, 19 May 2017 07:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 XgL4HwPLXpEB for ; Fri, 19 May 2017 07:51:44 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D080128DE7 for ; Fri, 19 May 2017 07:51:44 -0700 (PDT) Received: (qmail 72200 invoked from network); 19 May 2017 14:51:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 May 2017 14:51:43 -0000 Date: 19 May 2017 14:51:21 -0000 Message-ID: <20170519145121.4989.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:51:45 -0000 In article you write: >Please review this draft to see if you think it is suitable for adoption by >DNSOP, and comments to the list, clearly stating your view. I think we should adopt it as a starting point, but it needs a lot of work before it can be published. In particular, I agree with Paul W that ANAME has to work with offline signing, since a lot of us have no plans to do online signing, ever. I don't necessarily agree with his way to make that happen. Perhaps it could be more like CNAME and return the A/AAAA records with the original names and signatures. R's, John From nobody Fri May 19 10:15:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E8A129557 for ; Fri, 19 May 2017 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.522 X-Spam-Level: * X-Spam-Status: No, score=1.522 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 odF-XcdqDLtw for ; Fri, 19 May 2017 10:15:51 -0700 (PDT) Received: from mail.kahlerlarson.org (twister.kahlerlarson.org [104.237.149.128]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE6D128DF3 for ; Fri, 19 May 2017 10:15:51 -0700 (PDT) Received: from [IPv6:2620::2830:110:ddc6:678c:2af8:c7e1] (unknown [IPv6:2620:0:2830:110:ddc6:678c:2af8:c7e1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTPSA id CB4BF1F630; Fri, 19 May 2017 17:15:50 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/html; charset=us-ascii X-Apple-Auto-Saved: 1 X-Apple-Mail-Remote-Attachments: YES From: Matt Larson X-Apple-Base-Url: x-msg://56/ In-Reply-To: X-Apple-Windows-Friendly: 1 Date: Fri, 19 May 2017 13:15:50 -0400 Cc: dnsop X-Apple-Mail-Signature: SKIP_SIGNATURE Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tjw ietf X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 17:15:53 -0000
On May 11, 2017, at 6:55 AM, tjw ietf <tjw.ietf@gmail.com> = wrote:

I'm caught up with my = day job, and the discussion on this has died down, but it = looks like the work is moving along smoothly, it's time to kick off a = Call for Adoption on this document. (well, maybe = late). 

This starts a Call for Adoption for: draft-hunt-dnsop-aname

The draft is available here: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/

Please = review this draft to see if you think it is suitable for adoption by = DNSOP, and comments to the list, clearly stating your = view.

Please = also indicate if you are willing to contribute text, review, = etc.

This call = for adoption ends: Midnight 25 May = 2017

I= support adoption and will review. The market has spoken (long ago) that = something like this is needed, so we might as well standardize = it.

Matt

= From nobody Fri May 19 13:09:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D1A129601 for ; Fri, 19 May 2017 13:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vICJ5OKDA16C for ; Fri, 19 May 2017 13:09:57 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE252127867 for ; Fri, 19 May 2017 13:09:56 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id o12so53972672iod.3 for ; Fri, 19 May 2017 13:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LrPUCvBziW1Ll3vEV0BOSqStkOjEIcJ1ljYKopRVVB4=; b=XxSkhSm/atuvphRHQtuIb12GFIWemC7AonKRHHYgqHGr5RElt5htyF4b7aU0fth0TO SoXnaIrxDrr72aP4WzwLKv/TvRd80SuvUNtZ9PObxYY3m5lt+nQhfhYHjIoyIH5g8fnJ znjv0PnvTK57kavpi/OLZCvczHlXkwU/D2fmJFq9Ubi0tsf+tQMB6+al+vDMcT/Zneow lN5n72EwcCoUqxJUjlWeuexI188K+mVNyKeEukhVnoAPXfYmh/vQ1V1akujLVBlsR/34 B/JB9qJRRTLRq5UTvCqf5/w6WyA8fNoaWkQTrv7lFxlyiFlajshd8Zu/4zFsn3pA3rJn SM/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LrPUCvBziW1Ll3vEV0BOSqStkOjEIcJ1ljYKopRVVB4=; b=ZBwsIcqAa2qPoYt5x52AwzF176qs6v4qYsOm2ECPM4NqByMfBfbz+7mKXAyoi2LW/s BBn60Xf4XIX/BqAI8bMkSEnWEOx7cHGQGZE4E6LpJSL6Zqf5ZxxaMxUgAEeuFNwUyj7p HBKKV1N29u425yRXYXcykRPcDoubS4T3c9acuWPcMOBixr1DrioptGMGb9OOmoCwLmN/ QULgymeN9AIKSVEo/vxCVZcj9iyTgs2VELdd/w7UNHQF/7Op6OtlNS7Hq27jRmHNbnES Vs81KukfuoLO1iReBg7OTnVTT267QuU3D7j1uIPp3NoOE47irPjqTcOUWlb4EK4Wp92u Mr2A== X-Gm-Message-State: AODbwcBoCxdyF1HMGP4sQv3KbPVaZY/dLSi3XiierW0jTyIrui5rBoUC QAe3zCGjm/uJTXGhqAvSoD+53kOidA== X-Received: by 10.107.128.216 with SMTP id k85mr11803843ioi.115.1495224596273; Fri, 19 May 2017 13:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.44.13 with HTTP; Fri, 19 May 2017 13:09:55 -0700 (PDT) In-Reply-To: References: From: william manning Date: Fri, 19 May 2017 13:09:55 -0700 Message-ID: To: Matt Larson Cc: tjw ietf , dnsop Content-Type: multipart/alternative; boundary="001a113f96e4eba10c054fe61a2a" Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 20:09:58 -0000 --001a113f96e4eba10c054fe61a2a Content-Type: text/plain; charset="UTF-8" I will review. I support adoption. On Friday, May 19, 2017, Matt Larson wrote: > > On May 11, 2017, at 6:55 AM, tjw ietf > wrote: > > I'm caught up with my day job, and the discussion on this has died down, > but it looks like the work is moving along smoothly, it's time to kick off > a Call for Adoption on this document. (well, maybe late). > > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: https://datatracker. > ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: Midnight 25 May 2017 > > > I support adoption and will review. The market has spoken (long ago) that > something like this is needed, so we might as well standardize it. > > Matt > > --001a113f96e4eba10c054fe61a2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will review. I support adoption.

On Friday, May 19, 2017, Matt Lar= son <matt@kahlerlarson.org&= gt; wrote:

On May 11, 2017,= at 6:55 AM, tjw ietf <tjw.ietf@gmail.com> = wrote:

= I'm caught up with my day=C2=A0jo= b,=C2=A0and the discussion on this has died down, but it looks like the wor= k is moving along smoothly, it's time to kick off a Call for Adoption o= n this document. (well, maybe late).=C2=A0

This starts a Call for Adoption for:=C2=A0draft-hunt-dnsop-aname


Please review thi= s draft to see if you think it is suitable for adoption by DNSOP, and comme= nts to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.<= /span>

This call for adoption ends: Midnight 25 M= ay 2017

I support adoption an= d will review. The market has spoken (long ago) that something like this is= needed, so we might as well standardize it.

Matt<= /div>

--001a113f96e4eba10c054fe61a2a-- From nobody Mon May 22 08:30:53 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B41F01200CF; Mon, 22 May 2017 08:30:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546704472.24735.15566276762755962935.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 08:30:44 -0700 Archived-At: Subject: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dnsop-nsec-aggressiveuse-09=3A_=28with_COMMENT=29?= X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:30:45 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dnsop-nsec-aggressiveuse-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One smallish, unimportant editorial comment: In section 5, e.g.: "If the negative cache of the validating resolver has sufficient information to validate the query, the resolver SHOULD use NSEC, NSEC3 and wildcard records aggressively." it seems like the word "aggressive" has some meaning which was at least not clear to me. Is there a difference in negative caching and aggressive negative caching? If this word should provide any additional information on what to do could you maybe further explain? From nobody Tue May 23 05:22:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92A129B14 for ; Tue, 23 May 2017 05:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 TY6bt2PawcI0 for ; Tue, 23 May 2017 05:22:38 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7271294AC for ; Tue, 23 May 2017 05:22:37 -0700 (PDT) Received: from [62.232.251.194] (port=26661 helo=[192.168.12.23]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dD8pg-0002jL-4r for dnsop@ietf.org; Tue, 23 May 2017 13:22:36 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_33CF0CBA-B1C0-4158-A652-BDD6DD5D9C12" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 23 May 2017 13:22:34 +0100 References: To: IETF DNSOP WG In-Reply-To: Message-Id: <87BAB987-605C-412B-ABE9-947FDDA17B40@sinodun.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 12:22:40 -0000 --Apple-Mail=_33CF0CBA-B1C0-4158-A652-BDD6DD5D9C12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 May 2017, at 11:57, tjw ietf wrote: > This starts a Call for Adoption for: = draft-kristoff-dnsop-dns-tcp-requirements >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements= / = Hi,=20 I=E2=80=99ve reviewed this draft and as stated previously support = adoption as a companion document to RFC7766.=20 Minor comments: Section 2.2: I think the argument around DNSSEC can be bolstered by the = fact that recent root ZSK and upcoming KSK rollovers involved large = responses.=20 Section 2: I think it might be useful to include a section in section 2 = describing the fact that the lack of, or very limited implementation of = TCP also fed the perception that it was a security risk.=20 Section 6.3 s/[RFC7766] is might be/[RFC7766] might be/ Should there be a section in Section 6 about RFC7858 (DNS-over-TLS)? And = since it is stated as TCP related development should RFC2136 be there = (even though it is discussed earlier)? How about including a reference to = https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ = ? Regards Sara.=20= --Apple-Mail=_33CF0CBA-B1C0-4158-A652-BDD6DD5D9C12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 May 2017, at 11:57, tjw ietf <tjw.ietf@gmail.com> = wrote:

This starts a Call for Adoption for: draft-kristoff-dnsop-dns-tcp-requirements

The draft is = available here: https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-r= equirements/

Hi, 

I=E2=80= =99ve reviewed this draft and as stated previously support adoption as a = companion document to RFC7766. 

Minor comments:

Section 2.2: I think the argument around DNSSEC = can be bolstered by the fact that recent root ZSK and upcoming KSK = rollovers involved large responses. 

Section 2: I think it might be useful to include a = section in section 2 describing the fact that the lack of, or very = limited implementation of TCP also fed the perception that it was a = security risk. 

Section 6.3  s/[RFC7766] is might be/[RFC7766] might = be/

Should = there be a section in Section 6 about RFC7858 (DNS-over-TLS)? And since = it is stated as TCP related development should RFC2136 be there (even = though it is discussed earlier)?

How about including a reference to https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ ?

Regards

Sara. 
= --Apple-Mail=_33CF0CBA-B1C0-4158-A652-BDD6DD5D9C12-- From nobody Tue May 23 13:05:47 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 090BB12EAFF; Tue, 23 May 2017 13:05:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149556993903.28413.15691435664602759957.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 13:05:39 -0700 Archived-At: Subject: [DNSOP] Adam Roach's Yes on draft-ietf-dnsop-nsec-aggressiveuse-09: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:05:39 -0000 Adam Roach has entered the following ballot position for draft-ietf-dnsop-nsec-aggressiveuse-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems like a good change; the description is well written and easy to understand; and the logic seems sounds and well-explained. The abstract should remove the parentheses from the second paragraph, as they form an important (as opposed to incidental) part of the description of the update. From nobody Tue May 23 14:38:23 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20322124BE8; Tue, 23 May 2017 14:38:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149557549612.28496.162892586130531100.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 14:38:16 -0700 Archived-At: Subject: [DNSOP] Ben Campbell's Yes on draft-ietf-dnsop-nsec-aggressiveuse-09: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 21:38:16 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dnsop-nsec-aggressiveuse-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Adam's comment about the parenthetical phrasing in the abstract. I see the intent for text in square brackets to be removed. Did I miss instructions to the RFC Editor to that effect? Most likely they will figure it out, but explicit instructions would be better. From nobody Tue May 23 22:41:02 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EDD127868; Tue, 23 May 2017 22:40:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149560445570.28419.14767177653896917226@ietfa.amsl.com> Date: Tue, 23 May 2017 22:40:55 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 05:40:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-01.txt Pages : 12 Date : 2017-05-23 Abstract: This document describes the math behind the minimum time-length that a DNS zone publisher must wait before using a new DNSKEY to sign records when supporting the RFC5011 rollover strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 23 23:08:55 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB0D1200F3; Tue, 23 May 2017 23:08:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149560612196.28439.16392515299810104170.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 23:08:41 -0700 Archived-At: Subject: [DNSOP] Suresh Krishnan's No Objection on draft-ietf-dnsop-nsec-aggressiveuse-09: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 06:08:42 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-dnsop-nsec-aggressiveuse-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It would have been nice to use a AAAA record in the examples. From nobody Wed May 24 08:20:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE5F128ACA; Wed, 24 May 2017 08:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=SbnPKEIS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=erndEDdb 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 s_OqqGSfw5H5; Wed, 24 May 2017 08:20:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F071294B3; Wed, 24 May 2017 08:20:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D6552209F5; Wed, 24 May 2017 11:20:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 24 May 2017 11:20:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=2OtqLQ1pNEHAXKIgV3 bjgDYlX6OhOuHdLziuELYDlmE=; b=SbnPKEISbl0Tk7v89vxzAYyk8k5RZiImlZ +DA6xrUY//34Ya2C0EDBfXZenKLdYFBzdKdskfE2TRRdZ9+SlHJlKnS+v4Pv+ipX 8FwaAp4nEZhHeuqUiOvGyF6AInJTWMAe61kEtQVyVrtrxJT4k1eH4/rDoAH1Eg8F yhzw2qOujxkwYNyujmI+N3Gq94OQaDWOb4g4A/6kMm7ELAkHOo33phISldDEsKVX ei8y+QgKVFF8o9LcX85uADOCDh61RcsHApQEje3Zp2L0/jEcT7U0c3P6nf+zJJ3S W6zuxBDSQSpxoJWLQJle9bXFg05rPChaW//5oHinJPV/JW/lmftA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=2OtqLQ1pNEHAXKIgV3bjgDYlX6OhOuHdLziuELYDlmE=; b=erndEDdb uQIPkO7KP4PBpHF50ytJk4NPQv+rk33/gDC8oGpac8DJ8wzy3TI8mGjre5/YIq41 G39AjmLTwR4C/tX7Y+Rmw/C93R5PEFV0vvZu8Vk43P3SPbyj/ztyTMQD+1etSety JqbUEoDZ7kOx7Z96dtwWW+vJAQHVsDwQAq2b2LSyGtzXVJCV1pGIReog8vJHEh5S MMVC1eITBhVDyObc+9Q3jArTCH7w+mXzJ/NwvUEfEostbKPobhFxOr0vQEwUkLY5 /FIoM55TCF5xxbRt5ZWFkwSpM4/gZjvKAI9/IOve0LW7bfY0rgMNzb92wOjmQfn5 RIPlsc1mczG3YA== X-ME-Sender: X-Sasl-enc: q90UqMI/Iv8Lum8RjXcq88SCjtMJh8zrSvJkty5Qcfc4 1495639231 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id C84FB7E263; Wed, 24 May 2017 11:20:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149360667193.9876.7534874775326889081@ietfa.amsl.com> Date: Wed, 24 May 2017 11:20:29 -0400 Cc: "gen-art >> General area reviewing team" , dnsop@ietf.org, draft-ietf-dnsop-nsec-aggressiveuse.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <149360667193.9876.7534874775326889081@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [DNSOP] [Gen-art] Genart telechat review of draft-ietf-dnsop-nsec-aggressiveuse-09 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 15:20:35 -0000 Joel, thank you for your review. I have balloted No Objection. Alissa > On Apr 30, 2017, at 10:44 PM, Joel Halpern wrote: > > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-dnsop-nsec-aggressiveuse-09 > Reviewer: Joel Halpern > Review Date: 2017-04-30 > IETF LC End Date: 2017-03-27 > IESG Telechat date: 2017-05-25 > > Summary: This document is almost ready for publication as a Proposed > Standard RFC > > Major issues: > Procedural - ID Nits notes that there are normative references to > RFCs 7129 and 7719. Those are informational RFCs. The shepherd > writeup does not note these downrefs. (I see this was also noted by > Jouni Korhonen, but I do not see a resolution.) > > Minor issues: > > Nits/editorial comments: > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 24 10:58:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA3E12940D; Wed, 24 May 2017 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gXsczgT1tGFG; Wed, 24 May 2017 10:57:59 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD411200E5; Wed, 24 May 2017 10:57:56 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id f55so161942564qta.3; Wed, 24 May 2017 10:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=oZAuGQzl3CryrA33vnXRHO8C9mkw2GJkOiFm7pKddb8=; b=oGbfK5NASpn5LO+Z7Nn8BvRhQJPz4ErH+1drlziy6mIT2LMqJTAS0jdzof6+QzySkk S2A+iUuL9IiENhSBisnOzusQkrbi9kitakXs3dbyB/cvb0A3b2p+m4HwWhEy6NSh+Buc Boq5rFuy0IjL6Ufc+5KTbcTlxHkYfbsV4wuzbEbrpFlo5qRxti7f6Rxjzy8vdBzrh1gm EmTGmBfICh4/rrfpQ65lHKYiThvhinb90Q2SD+/omvwLGb2UmrpyXAmfHcsUZYxrTwFw bzWVU4AuNhuGq5tKqg9IcRY65shGeH4zisVQLWa/J3yQgphnQ4o9xTIqCB4SS+E1kYRs Rx4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=oZAuGQzl3CryrA33vnXRHO8C9mkw2GJkOiFm7pKddb8=; b=fQeQYrTUruR1VjfM6gdtv+midAEb4tq8d8A+bJ0FJpgYyxfmnHho6uzPLm2y4u03kD fSiqBTkNWhtTJ73Im/gIBmAf6EIpx4UVOIvQzBJbNistyPman8Z5jsl3PHH4HhdwvH0B li0ZIoNkgLBzWt4YZ2wgEJkE7WNDkOgq6RY1VHIzqd4UnHOlsM7z3/FuR6KsbbYRAFQR dSs8LSgzSy7JlrUuUFnoZOrYoNpGYUJNgNNNLgjAmqz8qOCGu1r9VUb4OqemhT8t6Rze iG98CwgBU4rkPGLX7eF5DPwSV2qvHJU+dmvqtwvGcZ16osOoN4WWaE5JvvCTmhalfMpf kRdQ== X-Gm-Message-State: AODbwcDGBSPzB690wRCeezLxHUsezDu0wwejH8CurpvibWRbQX37Dne/ 9v+g0Du5/rGom5faUYWv3Mwx0WcKN4gydBE= X-Received: by 10.237.37.21 with SMTP id v21mr36675498qtc.97.1495648675413; Wed, 24 May 2017 10:57:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Wed, 24 May 2017 10:57:55 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 24 May 2017 10:57:55 -0700 X-Google-Sender-Auth: ef5IKhqWJnfigIVp2B7lOIRbk50 Message-ID: To: draft-tale-dnsop-serve-stale@ietf.org Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [DNSOP] comments on draft-tale-dnsop-serve-stale-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 17:58:01 -0000 I've read draft-tale-dnsop-serve-stale-00. Overall I think we need something like this in practice. Even if, technically, it violates the current protocol standards, the background motivation is a real operational issue and I believe we should provide some standard-compliant mitigation. Of course, the end result may be very different from what's currently described in this draft, but I think this is a good start for the goal. I have a few minor comments on the current version: - I suspect it should include 'Updates: 1035 (if approved)' in the top boilerplate. - Section 3 If the answer has not been completely determined by the time the client response timer has elapsed, the resolver SHOULD then check its cache to see whether there is expired data that would satisfy the request. If so, it adds that data to the response message and SHOULD set the TTL of each expired record in the message to 1 second. The recommended value of the client response timer is 1.8 seconds, so end clients will see this amount of delay for queries for which this technique is needed (most notably while the corresponding authoritative servers are under a DoS attack and unreachable). I wonder whether this is really acceptable in terms of user experience. According to the draft this implementation has been actually used in the field (correct?). If so, were the end users okay with the delay? Also, it's not clear to me why the TTL is set to 1 second. Since it's actually expired, a zero TTL seems to be a more sensible choice here (a similar feature of unbound uses a zero TTL). If there's a specific reason to avoid 0, it would be better to explain it explicitly. - Section 4 Canonical Name (CNAME) records mingled in the expired cache with other records at the same owner name can cause surprising results. This was observed with an initial implementation in BIND, where a hostname changed from having a CNAME record to an IPv4 Address (A) record. BIND does not evict CNAMEs in the cache when other types are received, which in normal operations is not an issue. However, after both records expired and the authorities became unavailable, the fallback to stale answers returned the older CNAME instead of the newer A. I suspect this is quite specific to internal implementation details of BIND, specifically that RRsets of a name is maintained in a single-linked list, newer RRsets are prepended to the list, and on lookup the last found one is used if the list contains both CNAME and the exact type (A in this example). Is my guess correct? If so, while this is really an interesting topic and probably worth sharing, it's probably better to clarify it's specific to a particular implementation architecture. -- JINMEI, Tatuya From nobody Wed May 24 12:57:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31E7129B21 for ; Wed, 24 May 2017 12:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 lqwmBLL_-KW1 for ; Wed, 24 May 2017 12:56:58 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 741CF129AA3 for ; Wed, 24 May 2017 12:56:58 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-04v.sys.comcast.net with SMTP id DcNMdbzQtscBPDcOvdNBXN; Wed, 24 May 2017 19:56:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1495655817; bh=RE9MJucRqLpRVlrFq/BFaLT/eLX3yOcqWlf2YcOUgIo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=HGuLuzbDQY25mBNv5MUfvJcl8pcZ7YJh3cCe28PqhPWCWzJzDgprhx1GxrVyclVvx R6yWrQj17qycdZXwkLFJm6TgT4bggMlb21gcRfXlmPc9mjH8eAFgRgOLErXxvFF4DU cuKqvglulAuQ7G2TnalSkPIg0wRz+ehLspyJQJ4yBFYr4CTgFAQ/s60/xXN+ZSTO6u SASaUmDOUNAVVra76xeWdrCYUTDx6cuec/eqJH2iEtjuBfUp0Xd7uwiF9oNHuX/bCp Vxwj6+By3WHehnPG1sF2U9sM7HnZTAO54QVbnNxs9IzVVaNh7PRITUAlGRyC3B6l+/ aTyQr4T77SxLQ== Received: from [IPv6:2601:152:4400:a2e0::106f] ([IPv6:2601:152:4400:a2e0::106f]) by resomta-ch2-17v.sys.comcast.net with SMTP id DcOudCu5pbkqIDcOvdx1V5; Wed, 24 May 2017 19:56:57 +0000 To: "dnsop@ietf.org" References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> From: Michael StJohns Message-ID: <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> Date: Wed, 24 May 2017 15:56:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149560445570.28419.14767177653896917226@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfEKuaij9SjBlvDKO9hT1ywHOMyQejZg2pIQdm3NIGfm7VqPEagsheOSK2pCA0sjGr/rNmObEOWtfkBdGdQRFSF1CMbjdG4XIg9+naIZDhei2nPtZ5cnk euDtx6DPqXYbOvCWpQtwb35lLVguDosTbFYPyB6gmnGRhfjgPr9C0iig Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 19:57:00 -0000 I did a quick review - it's improving, but still is getting the basics wrong. This document is written with language that works only with the start with one key/one key in/one key out/end with one key model for trust anchor keys. 5011 specifically recommends that there be at least two trust anchor keys and this document doesn't quite get the problem statement right given that both 5011 and DNSSEC support a steady state of more than one trust anchor key. The actual issues related to the problem stated (of publisher guidance) are "How long must a publisher wait after publishing a new key before revoking ALL previous trust anchors?" And "How long to wait before signing ONLY with the newest key?" (These are actually the same question looked at from slightly different angles). The issue is not the more limited generic question of how long to wait before you start signing with the new key. (Please avoid the phrasing "use the key" throughout). For example, consider a trust point with trust anchor keys A, B and where A is generally signing the DNSKEY RR Set at the trust point. The publisher desires to replace A with a new key C. The publisher generates C, signs the RRSet with B and publishes the RRSet containing B and C. At time T+holddown, C has probably joined the first of many validator trust point sets. At some time T+holddown+N, most of the live validators will have added C. At this point the publisher revokes A, publishes a trust set with A, B, C and signed with A and B and continues this for at least the hold down time. At which point the published RRSet is now B, C signed by B (C is a standby key) and most validators trust points have B,C installed in them. (Or B signed by B for that matter - "Missing" is an abnormal state, not an illegal one and was there mainly because RRSet size issues mostly weren't brought up while 5011 was being discussed). Note that A could have been revoked starting with the first publication of C at the cost of reducing the validator trust anchor set to a single key. That would be the model for an emergency revocation of A. So: Minimum time to start signing with the new key is the hold down time (you can sign earlier, but no validator will trace trust through it so why bother?). Minimum time to wait before revoking all previous trust anchors OR signing the RRSet ONLY with the new key is hold down time counted from expiration date of the signature over previous DNSKey RRSET plus some slop - in the example the slop is 7 days and that's a reasonable value for the parameters. That's also the minimum time a new key should be published and signed even if you're planning on using it as a backup key and not including it in further RRSets for now. Note that the example in the draft at section 6 is missing a consideration. It's not the expiration time, but the expiration date that needs to be considered - if you issue a new RRSet while the signature on the old one has only 4 days to go, you have the 4 day exposure, not 10. Mike On 5/24/2017 1:40 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Security Considerations for RFC5011 Publishers > Authors : Wes Hardaker > Warren Kumari > Filename : draft-ietf-dnsop-rfc5011-security-considerations-01.txt > Pages : 12 > Date : 2017-05-23 > From nobody Wed May 24 13:28:25 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1A912878D; Wed, 24 May 2017 13:28:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149565769669.8677.4425005044081922286.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 13:28:16 -0700 Archived-At: Subject: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-nsec-aggressiveuse-09: (with COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 20:28:17 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dnsop-nsec-aggressiveuse-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I should ballot Discuss, so we can all tell Warren how awesome this draft is on the telechat itself. More seriously, I'm pretty sure I was Gen-ART reviewer for the RFC being updated, and this update seems very much like the right thing to do. From nobody Wed May 24 14:20:18 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA635129BDB; Wed, 24 May 2017 14:20:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149566081678.8673.10769889510675870005@ietfa.amsl.com> Date: Wed, 24 May 2017 14:20:16 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:20:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Aggressive use of DNSSEC-validated Cache Authors : Kazunori Fujiwara Akira Kato Warren Kumari Filename : draft-ietf-dnsop-nsec-aggressiveuse-10.txt Pages : 17 Date : 2017-05-24 Abstract: The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a range, and positive answers from wildcards. This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. It may also help increase resilience to certain DoS attacks in some circumstances. This document updates RFC4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. RFC Editor, please remove before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- ietf-dnsop-nsec-aggressiveuse. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec-aggressiveuse-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 24 14:25:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353CE129B21 for ; Wed, 24 May 2017 14:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 3LMkuBkx027R for ; Wed, 24 May 2017 14:25:24 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BA2129BC6 for ; Wed, 24 May 2017 14:25:23 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id x71so82442534vkd.0 for ; Wed, 24 May 2017 14:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b6rTqI1dtyN2nrnzXzuOa9YRSI9Hyi1naQfopa6i7wY=; b=JIWy0tGAWPjJRJ8eVzmrTV5YRpKs+8TY1EuuAGKz1mlXq5xfFfVkhhrT+DmfwLrYag k/pi1GIOb7+qtqEMjCJmeyi8VBtNGNKxKdci96gzlifoiiSrlJ8b0MK/f+YmFOU1MUSc KIFKGw4KJOCtMjF0dvwC6+L4EOvcmZt1qZB2TznUoz/QPge9f8X5gJ591ipoEpZj7Mrc rOOFll9VtMCglMYW6EMJOg92NK9RfQ2e7oEYP5LCB7DZEE3G3zM1/q55nRTe7pezVPBB A6QBIE1Def1AAXf/kfqBqy71FJm6mINnqqOoYhY2wo601ogJYrGlA8iN1O6mG1bquxPI VZjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b6rTqI1dtyN2nrnzXzuOa9YRSI9Hyi1naQfopa6i7wY=; b=ddXwbNDCIk5XyRhO+eMPvL/vUv8hMwl3U/hd4eADBjXP//jfHHegL+HtkouZZWroPv gSboZyyYE4n8oR948NE37FD6yq1Fy4Oy7v6sQODFC1tGymfbl4+dsZuRWYHP9czOsp57 5M54hlyhYJasjlcFeUOSmLV5mVd1oXkLvfEYEM6x4bhiK9GfUwnitViPKhe+0aW0qsJQ S5OZupPgGk3YAP8hXrYvsYzLTD7P04HL3w38SL3rXi+kvle/ROeytpeF02wp04WaWeLq zkghPoYakhmFwt9V92Fr3baLD9aX6nRCt7Kh73XnS6u1Uus+F6CKRO3Zt28bK2YNe0Zu dK2Q== X-Gm-Message-State: AODbwcARDpVQjmp21w5XLYXOIyz/MkULkNu70opNntjfe5w1+9dd1k7O +DRzbV/c2V0ka8dlB1F74pXQkQIgVy4J X-Received: by 10.31.173.142 with SMTP id w136mr15075295vke.125.1495661122475; Wed, 24 May 2017 14:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Wed, 24 May 2017 14:24:42 -0700 (PDT) In-Reply-To: <149546704472.24735.15566276762755962935.idtracker@ietfa.amsl.com> References: <149546704472.24735.15566276762755962935.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Wed, 24 May 2017 17:24:42 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , "dnsop-chairs@ietf.org" , dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnsop-nsec-aggressiveuse-09=3A_=28with_COMMENT=29?= X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:25:26 -0000 On Mon, May 22, 2017 at 11:30 AM, Mirja K=C3=BChlewind wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dnsop-nsec-aggressiveuse-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > One smallish, unimportant editorial comment: > In section 5, e.g.: "If the negative cache of the validating resolver has > sufficient > information to validate the query, the resolver SHOULD use NSEC, > NSEC3 and wildcard records aggressively." > it seems like the word "aggressive" has some meaning which was at least > not clear to me. Is there a difference in negative caching and aggressive > negative caching? If this word should provide any additional information > on what to do could you maybe further explain? Yup, you are right - aggressively wasn't well defined. I've just submitted a new version with: "the resolver SHOULD use NSEC, NSEC3 and wildcard records aggressively." -> "the resolver SHOULD use NSEC, NSEC3 and wildcard records to synthesize answers as described in this document". It also addresses the other IESG comments (basically remove parens around a bit in the intro, and also explicitly ask the RFC Editor to remove the bits in square brackets ""Ed note: Text inside square brackets ([])"... W --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed May 24 14:38:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A244129BC6 for ; Wed, 24 May 2017 14:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 xeFQhzXREVxT for ; Wed, 24 May 2017 14:38:46 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B06128792 for ; Wed, 24 May 2017 14:38:46 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 5C46B207CF; Wed, 24 May 2017 14:38:46 -0700 (PDT) From: Wes Hardaker To: Michael StJohns Cc: "dnsop\@ietf.org" References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> Date: Wed, 24 May 2017 14:38:45 -0700 In-Reply-To: <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> (Michael StJohns's message of "Wed, 24 May 2017 15:56:56 -0400") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:38:48 -0000 Michael StJohns writes: > This document is written with language that works only with the start > with one key/one key in/one key out/end with one key model for trust > anchor keys. 5011 specifically recommends that there be at least two > trust anchor keys and this document doesn't quite get the problem > statement right given that both 5011 and DNSSEC support a steady state > of more than one trust anchor key. Mike, I agree with everything you wrote. But I believe that (nearly) everything you wrote is about how you believe everyone *should* be using 5011. IE, guidance as to the recommended way to use DNSKEYs within a zone, how many to have, good practices about using them and publishing them, how many keys should be used to sign the records, etc. And all of that sounds like incredibly useful information. But that's not at all what this document is trying to address. We're trying to address the fact that almost no one is currently using your recommended practice and nearly everyone is using the "add a new key, switch to it after period X, and then remove the old key". This is the current real world reality, including with the root zone. So though you're absolutely right that you could have 3 keys (and likely should) and could double-sign as well with multiple keys, few actually do this. And the current root-key roll plan certainly doesn't either. Our goal is only to document the *minimum* requirements for rolling a key and making use of it as quickly as possible. Out of scope is "the preferred best practice". With that in mind, do you have a specific objection to some technical piece that does fall in that scope? we'd certainly like to hear it (especially with text provided). I'd also love to see DNSOP take on an additional document that handles the wider problem of "best practice" that would include your entire plan. I'd certainly support for it's adoption. > So: Minimum time to start signing with the new key is the hold down > time (you can sign earlier, but no validator will trace trust through > it so why bother?). This is a valid point and we need to look at the wording. Because we really mean "the minimum time at which you can *only* sign with a new key". You're absolutely right there. > Minimum time to wait before revoking all previous trust anchors OR > signing the RRSet ONLY with the new key is hold down time counted from > expiration date of the signature over previous DNSKey RRSET plus some > slop 1) it's really the second half, and the first half doesn't matter. It doesn't matter whether you revoke or not. The important statement is if you sign only with a key newer than the hold down time plus "slop" (and to use your own argument: there could be multiple introduced keys, and the point being you can't sign with *only* any of them until that key's hold down plus slop). 2) It's the slop we're trying to define. IE, what's the minimum time you must way before signing with only a fairly new key. It's not "slop", it's a required time period and a hard minimum fact (the 2*TTL is really the only true "slop"). > in the example the slop is 7 days and that's a reasonable value > for the parameters. No, that's one of my points: it's 17 days, not 7. 7 would leave you vulnerable to the attack in question, assuming you were signing only with a key published at T+37. You must wait until T+47 at minimum. > Note that the example in the draft at section 6 is missing a > consideration. It's not the expiration time, but the expiration date > that needs to be considered - if you issue a new RRSet while the > signature on the old one has only 4 days to go, you have the 4 day > exposure, not 10. I keep following you in the above and agreeing with it until the end. Most importantly, "expiration time" is not the right wording. You're absolutely right there, and we need to define it more carefully using the expiration (sigexpire) date. I'll look into that. I'm not sure what "new RRSet" you're envisioning for the rest. We really only care about the replay time of the RRSIGs on only the K_old set. [There are certainly more complex examples we could throw into the mix, such as publishing multiple keys over lapping in time periods, but I don't see the benefit of confusing the reader with an even more complex example]. -- Wes Hardaker USC/ISI From nobody Thu May 25 10:00:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B03129B43 for ; Thu, 25 May 2017 10:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 pIZMZbFUYE65 for ; Thu, 25 May 2017 10:00:50 -0700 (PDT) Received: from aharp.iorc.depaul.edu (aharp.iorc.depaul.edu [IPv6:2620:0:2250:2115:c0a7:18f5:bca1:ba92]) by ietfa.amsl.com (Postfix) with ESMTP id 1238F129B53 for ; Thu, 25 May 2017 10:00:50 -0700 (PDT) Received: from p50.localdomain (localhost [127.0.0.1]) by aharp.iorc.depaul.edu (Postfix) with ESMTP id 182D618FB; Thu, 25 May 2017 17:00:49 +0000 (UTC) Date: Thu, 25 May 2017 12:00:48 -0500 From: John Kristoff To: Sara Dickinson Cc: IETF DNSOP WG Message-ID: <20170525120048.1477cea5@p50.localdomain> In-Reply-To: References: Reply-To: jtk@aharp.iorc.depaul.edu MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 17:00:52 -0000 On Tue, 23 May 2017 12:22:34 +0000 Sara Dickinson wrote: > I=E2=80=99ve reviewed this draft and as stated previously support adoptio= n as > a companion document to RFC7766. Thank you for your review. > Section 2.2: I think the argument around DNSSEC can be bolstered by > the fact that recent root ZSK and upcoming KSK rollovers involved > large responses. Thank you, we can note that in a future revision. > Section 2: I think it might be useful to include a section in section > 2 describing the fact that the lack of, or very limited > implementation of TCP also fed the perception that it was a security > risk. The references Cheswick, W. and S. Bellovin book in section 2.4 I think may largely sums up the general concern. Maybe the section 2.4 is not correctly titled or incompletely detailed to highlight your point. Any specific text or additional references are welcome of course. > Section 6.3 s/[RFC7766] is might be/[RFC7766] might be/ Thank you. > Should there be a section in Section 6 about RFC7858 (DNS-over-TLS)? Yes, thanks for pointing that out. That section is still work in progress. > And since it is stated as TCP related development should RFC2136 be > there (even though it is discussed earlier)? Probably should be there. Need I worry about section 6's length at all? It could take up a significant portion of the document given the way this section is going. Note, this section was added based on some earlier feedback that having this sort of list might be helpful. >=20 > How about including a reference to > https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ ? Looks potentially worth including this sort of work in section 4. Thanks again, John From nobody Thu May 25 10:15:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336FB1293F9 for ; Thu, 25 May 2017 10:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 XPd_Ox_5IP5G for ; Thu, 25 May 2017 10:15:43 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2E62F127444 for ; Thu, 25 May 2017 10:15:43 -0700 (PDT) Received: from [169.254.97.229] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v4PHFCRY033488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 May 2017 10:15:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.97.229] From: "Paul Hoffman" To: "dnsop@ietf.org" Date: Thu, 25 May 2017 10:15:40 -0700 Message-ID: <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> In-Reply-To: References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 17:15:44 -0000 Most people reading an RFC about the DNS probably expect it to be about the public DNS we know. That public DNS currently has one KSK, and there are no plans to change that (although there might be in the future). Given that, and given Mike's comments on the doc, I propose the following. Change the Abstract from: This document describes the math behind the minimum time-length that a DNS zone publisher must wait before using a new DNSKEY to sign records when supporting the RFC5011 rollover strategies. To: This document describes the math behind the minimum time-length that a DNS zone publisher must wait before using a new DNSKEY to sign records when supporting the RFC5011 rollover strategies in zones that have a single key signing key. Just before Section 1.1, add a paragraph: This document describes only the case where a zone has only a single key signing key (KSK). It does not apply to zones that have multiple KSKs. The current public DNS has a single KSK covering the root zone, and this document focuses mostly on that KSK in its discussion. --Paul Hoffman From nobody Thu May 25 11:27:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77677124D85 for ; Thu, 25 May 2017 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 bfJb1_kUlvP4 for ; Thu, 25 May 2017 11:27:08 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88798129C16 for ; Thu, 25 May 2017 11:27:08 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id b68so107214121ywe.3 for ; Thu, 25 May 2017 11:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D7zFwcw2/qfD4Vu09Ot/EeWBU01ug5uCKgX2FvT/4rc=; b=MMAbTD+1HsQuyBRe3SxMOQ8KwqS2YFKovMSQ/3n8kiIEKyadLG91qlCKGZfsWuIlGG Q2im5BoFR7uUKW36AAL2NPCb2+YFCh/Bbgr6QazJ+H1qRlggXjxJtrc6TPBqkegr9kzf dAvq5A1QKeOhiQAwXqxx4WYq4O/+U3+ALtSrD0+RKzJCYmkk3scS4wrKHQOfn6aRQ/TO FDS5ny7xby4pw220LWf12XJRu5/E9mvRi6oYgZnl9HOzM/H3hjIZs+RA6Y+spQFJQ4qS YFKrEXw/TprZufnl/h1wARDAarhrO6r10AKBBbj/vhjJjQ7qdJiRNpcR2iTtoY/8v03p OmKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D7zFwcw2/qfD4Vu09Ot/EeWBU01ug5uCKgX2FvT/4rc=; b=ftod4jjEpsrqwk2sa1DCpE+aT3NNGVBuYxDOEJ6x7dCryuyzhFH5+3BOhkvorWtCUj f8cjkEgsDRQpmAtbj69EOjvC3svCWBGGRjTPYmTdiZN1f6l1XqPlTCWwUdPD/x5O15u7 R6pom4q5kdfO+PaXOi32bqy25FohQAymMSuugc0DdSqV25VXxrlnwVimaCGhp9ZAldts 70mECa+p726NuTc+nlJ2YHntfZku3+ls3PqvgiNnA4mvnst8RQXEnS8bZK6/2LwqBQU/ LPiuZqbuRDGNVVAiP6xEsn68So1iduu5MGwrpXMRjfFwwhb4nTiu670/LMqTXU11pOsw nUlg== X-Gm-Message-State: AODbwcByhqXc07mK6vCg47GslbXffrE9G434wacRI66/mL/ENEFaEi1c N4FCUSlZlERO8R/IbJl/OqzA0xoj31wL538= X-Received: by 10.13.217.140 with SMTP id b134mr33204306ywe.4.1495736827681; Thu, 25 May 2017 11:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.161.148 with HTTP; Thu, 25 May 2017 11:27:06 -0700 (PDT) In-Reply-To: <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> From: Bob Harold Date: Thu, 25 May 2017 14:27:06 -0400 Message-ID: To: Paul Hoffman Cc: "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a114fb58e4aaee805505d5e80" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:27:10 -0000 --001a114fb58e4aaee805505d5e80 Content-Type: text/plain; charset="UTF-8" On Thu, May 25, 2017 at 1:15 PM, Paul Hoffman wrote: > Most people reading an RFC about the DNS probably expect it to be about > the public DNS we know. That public DNS currently has one KSK, and there > are no plans to change that (although there might be in the future). Given > that, and given Mike's comments on the doc, I propose the following. > > Change the Abstract from: > This document describes the math behind the minimum time-length that > a DNS zone publisher must wait before using a new DNSKEY to sign > records when supporting the RFC5011 rollover strategies. > To: > This document describes the math behind the minimum time-length that > a DNS zone publisher must wait before using a new DNSKEY to sign > records when supporting the RFC5011 rollover strategies in zones > that have a single key signing key. > > Just before Section 1.1, add a paragraph: > > This document describes only the case where a zone has only a single key > signing key (KSK). It does not apply to zones that have multiple KSKs. The > current public DNS has a single KSK covering the root zone, and this > document focuses mostly on that KSK in its discussion. > > --Paul Hoffman Although the root zone is mentioned, I don't think "this document focuses mostly on that KSK" I might be wrong, but it would seem to me that the doc covers two situations: 1. How long to wait after publishing a key before signing exclusively with that key. 2. How long after you stop signing with a key before you remove it. And both should apply no matter how many keys a zone happens to have. -- Bob Harold --001a114fb58e4aaee805505d5e80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, May 25, 2017 at 1:1= 5 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Most people reading an RFC a= bout the DNS probably expect it to be about the public DNS we know. That pu= blic DNS currently has one KSK, and there are no plans to change that (alth= ough there might be in the future). Given that, and given Mike's commen= ts on the doc, I propose the following.

Change the Abstract from:
=C2=A0 =C2=A0This document describes the math behind the minimum time-lengt= h that
=C2=A0 =C2=A0a DNS zone publisher must wait before using a new DNSKEY to si= gn
=C2=A0 =C2=A0records when supporting the RFC5011 rollover strategies.
To:
=C2=A0 =C2=A0This document describes the math behind the minimum time-lengt= h that
=C2=A0 =C2=A0a DNS zone publisher must wait before using a new DNSKEY to si= gn
 =C2=A0 =C2=A0records when supporting the RFC5011 rollover strategies in zon= es
=C2=A0 =C2=A0that have a single key signing key.

Just before Section 1.1, add a paragraph:

This document describes only the case where a zone has only a single key si= gning key (KSK). It does not apply to zones that have multiple KSKs. The cu= rrent public DNS has a single KSK covering the root zone, and this document= focuses mostly on that KSK in its discussion.=

--Paul Hoffman

Although the r= oot zone is mentioned, I don't think "this document focuses mostly= on that KSK"

I might be wrong, but it would = seem to me that the doc covers two situations:
1. How long to wai= t after publishing a key before signing exclusively with that key.
2. How long after you stop signing with a key before you remove it.
=
And both should apply no matter how many keys a zone happens to have.<= /div>

--=C2=A0
Bob Harold

=

--001a114fb58e4aaee805505d5e80-- From nobody Thu May 25 12:22:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9344D128DE5 for ; Thu, 25 May 2017 12:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 At0KMmZAGsJX for ; Thu, 25 May 2017 12:22:14 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDFB127876 for ; Thu, 25 May 2017 12:22:14 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id v27so188532839qtg.2 for ; Thu, 25 May 2017 12:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=yvrNJgU4LykrAI96774F2uhcKBavG1+40N58zTlnYiU=; b=tlGWBnX7J7zpuwtNWwPJZYxcYnb2a6uCRysBpRc5TxOJOitUuEjrPBTQkgOD2wGJKO F09L+8I1GOcq8P+VRumxyKmu+TTjt+9sgP05MalSUXOl396bbmh5JaNnyaUXIaEjZe2D d6TfZ4PJ95Tet+ePDJDxMe8dorV7P/SoNbjq/5rpoYBI9GKQAewOz4uvmj+uQ4/44wOn +4zIgmvevUGnOZD4ym4qmpkjmLofrjDP4EMfRxqPBhlmf+D1cd5Idv8s7rjKgtS9kQgH frMb2uK+OqKCelMM+tkMHI/D2jk94eWTrRzd9QYxGFBGxXoeZH3Wot/1YzqQHvm3utbC s7Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yvrNJgU4LykrAI96774F2uhcKBavG1+40N58zTlnYiU=; b=ROYByDz4KkJ+951yZdTM3CXpqlkZD98CJ6xjHPDO/CXN9YW3SkQD4ofdi5cshB+1RR j2p7R3dzjmBbfGfwOGYcPEQ1f5jW729WBLQFectc9mAQ/E9xckwB1SrKbXqzUJ4hk6D9 zLmdlqkM6p0MlLel6SDoaaC5UiQ0d9B8Jwbac6fDIcYHTAsjF8yI+Y3WFC5lMiSvSNvh SsyAy8TdroNvp/HcoBxCwhNzzbXJF2dEQv9+qizKOMRWt4cbVsoGiIdT7vdn9Xa4Tb5g 7nKQqqsrAFJGsfytqWzSGnzOe1kxTRl14mSWfNGkCdbjn/EPNh+MvGbhbk7PBcScSxM6 zZTw== X-Gm-Message-State: AODbwcB3mCo4HYbf2mph9GzsWV3IC3yIrZZCWQub0aNknuczbtIRT5q0 P8bwVqUoQZITRr/m8Q4= X-Received: by 10.200.52.165 with SMTP id w34mr44675378qtb.77.1495740133364; Thu, 25 May 2017 12:22:13 -0700 (PDT) Received: from ?IPv6:2601:152:4400:a2e0::1077? ([2601:152:4400:a2e0::1077]) by smtp.gmail.com with ESMTPSA id m7sm5231935qtm.10.2017.05.25.12.22.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 12:22:11 -0700 (PDT) To: dnsop@ietf.org References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> From: Michael StJohns Message-ID: <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> Date: Thu, 25 May 2017 15:22:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:22:17 -0000 Hi Paul - I appreciate that both you and Wes have new skills related to mind reading about my intents, but you're probably reading the wrong mind. I have stated the question a publisher needed to answer fairly succinctly in the past: "How long must a publisher wait until it is reasonably certain that a new key has been installed as a trust anchor in all but a slim minority of live DNS 5011 resolvers?" That question is the correct one to answer because it covers all the rest: "How long should a publisher wait after publishing a new key before it signs the trust point DNSKEY RRSet with ONLY that key?" Same answer as to the question above because you have to wait to stop signing with all the other trust anchors until the trust anchor uptake rate for the new key at the resolvers is sufficient (for some value of sufficient). "How long should a publisher wait after publishing a new key before it revokes ALL of the old trust anchor keys?" Same answer to the above, and incidentally forces you to only sign with the new key. Note that the answers to the question the document asks are different than as stated (because of the one in/one out assumption): "How long must a publisher wait after publishing a new key before it signs the trust point DNSKEY RRSet with that key?" Answer is that it may begin signing the RRSet immediately upon publication, resolvers will not start tracing trust through that key until at least the hold down time. The publisher may indeed delay signing as long as it wants as long as there are other trust anchor keys available. "How long must a publisher wait after a publishing a new key before it revokes an older trust anchor key?" Answer is that it depends on how many trust anchor keys are assumed to be in most resolver's set. If only one, then you wait until you are "reasonably certain that a new key has been installed as a trust anchor..." If its more than one, then it depends on the trust point's policy of how many keys to keep more than anything. The important part in this document is getting a handle on the publication uptake time for most resolvers given a new key. The rest of the guidance flows from that. My specific point is that this document should talk to the protocol, not limit the discussion to current practices - especially since current practices are really a proper subset of the allowed behavior. I do understand what the root is doing right now, and you're both correct that I wish they were using at least a two key trust anchor set as steady state. But that still doesn't obviate my point about writing the document to the protocol and not the practice. In the current document, I'd rewrite the math and discussion to deal with how I framed the question (e.g. its about how long it takes to populate enough resolvers). If there is then a desire to talk about the current root update process, then do that as an appendix or an example and I think doing the analysis against the current root key update process is a good idea. Later, Mike On 5/25/2017 1:15 PM, Paul Hoffman wrote: > Most people reading an RFC about the DNS probably expect it to be > about the public DNS we know. That public DNS currently has one KSK, > and there are no plans to change that (although there might be in the > future). Given that, and given Mike's comments on the doc, I propose > the following. > > Change the Abstract from: > This document describes the math behind the minimum time-length that > a DNS zone publisher must wait before using a new DNSKEY to sign > records when supporting the RFC5011 rollover strategies. > To: > This document describes the math behind the minimum time-length that > a DNS zone publisher must wait before using a new DNSKEY to sign > records when supporting the RFC5011 rollover strategies in zones > that have a single key signing key. > > Just before Section 1.1, add a paragraph: > > This document describes only the case where a zone has only a single > key signing key (KSK). It does not apply to zones that have multiple > KSKs. The current public DNS has a single KSK covering the root zone, > and this document focuses mostly on that KSK in its discussion. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu May 25 14:31:45 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34A512941D for ; Thu, 25 May 2017 14:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 x1JLHPlKAq8G for ; Thu, 25 May 2017 14:31:43 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D0E127863 for ; Thu, 25 May 2017 14:31:43 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0F3772087E; Thu, 25 May 2017 14:31:43 -0700 (PDT) From: Wes Hardaker To: Bob Harold Cc: Paul Hoffman , "dnsop\@ietf.org" References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> Date: Thu, 25 May 2017 14:31:42 -0700 In-Reply-To: (Bob Harold's message of "Thu, 25 May 2017 14:27:06 -0400") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 21:31:45 -0000 Bob Harold writes: > I might be wrong, but it would seem to me that the doc covers two situations: > 1. How long to wait after publishing a key before signing exclusively with that key. Thank you. That is exactly the intent of the document. > 2. How long after you stop signing with a key before you remove it. Actually, it's how long you have to wait before removing a key that you set the revoke bit on. > And both should apply no matter how many keys a zone happens to have. Yes yes yes. It has nothing to do with the number of keys. It's purely the "if you exclusively sign with a (any) new key before it has been published for this length of time, you're vulnerable to attack". -- Wes Hardaker USC/ISI From nobody Thu May 25 18:52:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1097312EB06 for ; Thu, 25 May 2017 18:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Rtku9Q9GMRhn for ; Thu, 25 May 2017 18:52:28 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 E0BD412EB04 for ; Thu, 25 May 2017 18:52:28 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CBD3F3493A2; Fri, 26 May 2017 01:52:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BC31216003D; Fri, 26 May 2017 01:52:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A8D07160048; Fri, 26 May 2017 01:52:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G0xkT5ogAnxD; Fri, 26 May 2017 01:52:25 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2E85616003D; Fri, 26 May 2017 01:52:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C1FE979B8C4F; Fri, 26 May 2017 11:52:22 +1000 (AEST) To: Michael StJohns Cc: dnsop@ietf.org From: Mark Andrews References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> In-reply-to: Your message of "Thu, 25 May 2017 15:22:10 -0400." <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> Date: Fri, 26 May 2017 11:52:22 +1000 Message-Id: <20170526015222.C1FE979B8C4F@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 01:52:31 -0000 These questions are why I don't like RFC5011. There is lots of missing metadata about DNSKEYs that exists in CERTs. We could supply this metadata in TBD records at the apex of the zone which are like extended DS records (I will call these records VU records). Things like "valid until" where validators go insecure if they no longer have any stored trust anchors with a "valid until" in the future. Where zone operators commit to signing with the DNSKEY until after the "valid until" time has passed. e.g. . VU where these records get updated periodically if you want to extend the life of the matching DNSKEY record. A KSK key rollover would involve publishing a new VU record along with the new DNSKEY record. . VU . VU If a validator is off line during the KSK rollover then it would continue to have just . VU and if it is restarted after it would start in insecure mode. Similarly if it just misses a updates of the VU records to extend the DNSKEY's lifetime it would start up insecurely. . VU to . VU Mark In message <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com>, Michael StJohns writes: > Hi Paul - > > I appreciate that both you and Wes have new skills related to mind > reading about my intents, but you're probably reading the wrong mind. > > I have stated the question a publisher needed to answer fairly > succinctly in the past: > > "How long must a publisher wait until it is reasonably certain that a > new key has been installed as a trust anchor in all but a slim minority > of live DNS 5011 resolvers?" > > That question is the correct one to answer because it covers all the rest: > > "How long should a publisher wait after publishing a new key before it > signs the trust point DNSKEY RRSet with ONLY that key?" Same answer as > to the question above because you have to wait to stop signing with all > the other trust anchors until the trust anchor uptake rate for the new > key at the resolvers is sufficient (for some value of sufficient). > "How long should a publisher wait after publishing a new key before it > revokes ALL of the old trust anchor keys?" Same answer to the above, > and incidentally forces you to only sign with the new key. > > Note that the answers to the question the document asks are different > than as stated (because of the one in/one out assumption): > "How long must a publisher wait after publishing a new key before it > signs the trust point DNSKEY RRSet with that key?" Answer is that it > may begin signing the RRSet immediately upon publication, resolvers will > not start tracing trust through that key until at least the hold down > time. The publisher may indeed delay signing as long as it wants as > long as there are other trust anchor keys available. > > "How long must a publisher wait after a publishing a new key before it > revokes an older trust anchor key?" Answer is that it depends on how > many trust anchor keys are assumed to be in most resolver's set. If > only one, then you wait until you are "reasonably certain that a new key > has been installed as a trust anchor..." If its more than one, then it > depends on the trust point's policy of how many keys to keep more than > anything. > > The important part in this document is getting a handle on the > publication uptake time for most resolvers given a new key. The rest > of the guidance flows from that. > > My specific point is that this document should talk to the protocol, not > limit the discussion to current practices - especially since current > practices are really a proper subset of the allowed behavior. I do > understand what the root is doing right now, and you're both correct > that I wish they were using at least a two key trust anchor set as > steady state. But that still doesn't obviate my point about writing the > document to the protocol and not the practice. > > In the current document, I'd rewrite the math and discussion to deal > with how I framed the question (e.g. its about how long it takes to > populate enough resolvers). If there is then a desire to talk about > the current root update process, then do that as an appendix or an > example and I think doing the analysis against the current root key > update process is a good idea. > > Later, Mike > > > > > On 5/25/2017 1:15 PM, Paul Hoffman wrote: > > Most people reading an RFC about the DNS probably expect it to be > > about the public DNS we know. That public DNS currently has one KSK, > > and there are no plans to change that (although there might be in the > > future). Given that, and given Mike's comments on the doc, I propose > > the following. > > > > Change the Abstract from: > > This document describes the math behind the minimum time-length that > > a DNS zone publisher must wait before using a new DNSKEY to sign > > records when supporting the RFC5011 rollover strategies. > > To: > > This document describes the math behind the minimum time-length that > > a DNS zone publisher must wait before using a new DNSKEY to sign > > records when supporting the RFC5011 rollover strategies in zones > > that have a single key signing key. > > > > Just before Section 1.1, add a paragraph: > > > > This document describes only the case where a zone has only a single > > key signing key (KSK). It does not apply to zones that have multiple > > KSKs. The current public DNS has a single KSK covering the root zone, > > and this document focuses mostly on that KSK in its discussion. > > > > --Paul Hoffman > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu May 25 20:27:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5712009C for ; Thu, 25 May 2017 20:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 7kxprn0RLtax for ; Thu, 25 May 2017 20:27:14 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1D0126579 for ; Thu, 25 May 2017 20:27:14 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id u75so190495559qka.3 for ; Thu, 25 May 2017 20:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QAbBYVQzm/R4Rcxp3p4ANZvxkNv9k05TogXuOwoP1lY=; b=BWc9DWkul2lPfdRHWIkgRU3AqIHUgu+yPAar1cMq12j7FX1l0tYrBP7qLJRnlqljF4 Fkzas3hPkXPVFblDKL6eWh1L09kaJzGbPtTI3hEQXmYONVxO+qygGRbuP/bbAlA9yCd9 T2lCmIJ9NpnkMhXwi7GtUvn/PcyAD/D2r5mZOGd/DX2HM4Qp5VYZrilIUfR7Uv75RNSB miAzh0lp3gdQFm5cyVyyJEdCNvebowfzW1xXWyoNBMdLdZ++dx9vfLv1shMNyoqeqWgF a8epUKq8GfWE6kqnNAfxyfjM9L9ILBpxWXfxngMXVLwQ9s+3GM5RSGCnqHPS3tWuaSGk YprQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QAbBYVQzm/R4Rcxp3p4ANZvxkNv9k05TogXuOwoP1lY=; b=sVhBisBQ3XstjvKT15Uw6lU5hCBX/6XDab7RICCMKd2RYBKH1I4Tz+nwO1rfFCAgQD 2HG1IEks5FDNhVwfukl5sqsYK1i1kMVU0HoXrXacC9GU6DlPcU2c4ICGiCwBAjjtnypb tRA6ykBZNs5SS4TDNNSIw6Q9aK1KPO88pj20IVHDez3WfApU6FdSTtrabysv5UnHxa6T hIC7yuKVF1lqc0CQO6j9209tC1ZiadqtRmLZ04iuOerI3e59OZbuEf+f3f4bjrl5qtN7 SpgAQFmMi8aDxQLCmNk49B3NiB5h5vtYGaLF7BC5bgk9ymXgcyMMiWEMjKx8ZR1HooQe a0Ig== X-Gm-Message-State: AODbwcCUYheQXCZs0wvBareqtPVy2xwk5n5Uw87ZzIY3BcIjl6bQADTj W05n8sOy0CCzefTU X-Received: by 10.55.126.7 with SMTP id z7mr41494881qkc.121.1495769233793; Thu, 25 May 2017 20:27:13 -0700 (PDT) Received: from ?IPv6:2601:152:4400:a2e0::1077? ([2601:152:4400:a2e0::1077]) by smtp.gmail.com with ESMTPSA id r22sm6055459qke.25.2017.05.25.20.27.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 20:27:12 -0700 (PDT) To: Mark Andrews Cc: dnsop@ietf.org References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> <20170526015222.C1FE979B8C4F@rock.dv.isc.org> From: Michael StJohns Message-ID: <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com> Date: Thu, 25 May 2017 23:27:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170526015222.C1FE979B8C4F@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 03:27:17 -0000 I appreciate your comments, but they are pretty much inapplicable to the document. I'd suggest if this approach is important to you that you draft an ID and gather comments on that document. If you want to recommend changes to 5011 - same comment. What we're discussing now is guidance for the publisher that's trying to understand the implications of following 5011 timing considerations and how those relate to the publishing schedule. Mike On 5/25/2017 9:52 PM, Mark Andrews wrote: > These questions are why I don't like RFC5011. There is lots of > missing metadata about DNSKEYs that exists in CERTs. We could > supply this metadata in TBD records at the apex of the zone which > are like extended DS records (I will call these records VU records). > > Things like "valid until" where validators go insecure if they no > longer have any stored trust anchors with a "valid until" in the > future. Where zone operators commit to signing with the DNSKEY > until after the "valid until" time has passed. > > e.g. > . VU > > where these records get updated periodically if you want to extend > the life of the matching DNSKEY record. > > A KSK key rollover would involve publishing a new VU record along > with the new DNSKEY record. > > . VU > . VU > > If a validator is off line during the KSK rollover then it would > continue to have just > > . VU > > and if it is restarted after it would start in insecure > mode. > > Similarly if it just misses a updates of the VU records to extend > the DNSKEY's lifetime it would start up insecurely. > > . VU > > to > > . VU > > Mark > > In message <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com>, Michael StJohns writes: >> Hi Paul - >> >> I appreciate that both you and Wes have new skills related to mind >> reading about my intents, but you're probably reading the wrong mind. >> >> I have stated the question a publisher needed to answer fairly >> succinctly in the past: >> >> "How long must a publisher wait until it is reasonably certain that a >> new key has been installed as a trust anchor in all but a slim minority >> of live DNS 5011 resolvers?" >> >> That question is the correct one to answer because it covers all the rest: >> >> "How long should a publisher wait after publishing a new key before it >> signs the trust point DNSKEY RRSet with ONLY that key?" Same answer as >> to the question above because you have to wait to stop signing with all >> the other trust anchors until the trust anchor uptake rate for the new >> key at the resolvers is sufficient (for some value of sufficient). >> "How long should a publisher wait after publishing a new key before it >> revokes ALL of the old trust anchor keys?" Same answer to the above, >> and incidentally forces you to only sign with the new key. >> >> Note that the answers to the question the document asks are different >> than as stated (because of the one in/one out assumption): >> "How long must a publisher wait after publishing a new key before it >> signs the trust point DNSKEY RRSet with that key?" Answer is that it >> may begin signing the RRSet immediately upon publication, resolvers will >> not start tracing trust through that key until at least the hold down >> time. The publisher may indeed delay signing as long as it wants as >> long as there are other trust anchor keys available. >> >> "How long must a publisher wait after a publishing a new key before it >> revokes an older trust anchor key?" Answer is that it depends on how >> many trust anchor keys are assumed to be in most resolver's set. If >> only one, then you wait until you are "reasonably certain that a new key >> has been installed as a trust anchor..." If its more than one, then it >> depends on the trust point's policy of how many keys to keep more than >> anything. >> >> The important part in this document is getting a handle on the >> publication uptake time for most resolvers given a new key. The rest >> of the guidance flows from that. >> >> My specific point is that this document should talk to the protocol, not >> limit the discussion to current practices - especially since current >> practices are really a proper subset of the allowed behavior. I do >> understand what the root is doing right now, and you're both correct >> that I wish they were using at least a two key trust anchor set as >> steady state. But that still doesn't obviate my point about writing the >> document to the protocol and not the practice. >> >> In the current document, I'd rewrite the math and discussion to deal >> with how I framed the question (e.g. its about how long it takes to >> populate enough resolvers). If there is then a desire to talk about >> the current root update process, then do that as an appendix or an >> example and I think doing the analysis against the current root key >> update process is a good idea. >> >> Later, Mike >> >> >> >> >> On 5/25/2017 1:15 PM, Paul Hoffman wrote: >>> Most people reading an RFC about the DNS probably expect it to be >>> about the public DNS we know. That public DNS currently has one KSK, >>> and there are no plans to change that (although there might be in the >>> future). Given that, and given Mike's comments on the doc, I propose >>> the following. >>> >>> Change the Abstract from: >>> This document describes the math behind the minimum time-length that >>> a DNS zone publisher must wait before using a new DNSKEY to sign >>> records when supporting the RFC5011 rollover strategies. >>> To: >>> This document describes the math behind the minimum time-length that >>> a DNS zone publisher must wait before using a new DNSKEY to sign >>> records when supporting the RFC5011 rollover strategies in zones >>> that have a single key signing key. >>> >>> Just before Section 1.1, add a paragraph: >>> >>> This document describes only the case where a zone has only a single >>> key signing key (KSK). It does not apply to zones that have multiple >>> KSKs. The current public DNS has a single KSK covering the root zone, >>> and this document focuses mostly on that KSK in its discussion. >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri May 26 02:40:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B6312717E for ; Fri, 26 May 2017 02:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 MkrQIJ_kU99X for ; Fri, 26 May 2017 02:39:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 31A5F12711E for ; Fri, 26 May 2017 02:39:57 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4F5A434930F for ; Fri, 26 May 2017 09:39:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 25F4E160054 for ; Fri, 26 May 2017 09:39:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0C99B160048 for ; Fri, 26 May 2017 09:39:53 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7dXPuNahcFZt for ; Fri, 26 May 2017 09:39:52 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 95C99160047 for ; Fri, 26 May 2017 09:39:52 +0000 (UTC) To: dnsop From: Ray Bellis Message-ID: <60fb8c2f-e4e4-7e6b-9c3a-f21f48eff75b@isc.org> Date: Fri, 26 May 2017 10:39:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 09:39:58 -0000 Call For Presentations The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we can accommodate those talks during the Members Only session on the morning of September 29th. A timeslot will also be available for lightning talks (5-10 minutes) on Saturday September 30th, for which submissions will be accepted during Friday 29th. Workshop Milestones: 26 May 2017, Call for Presentations posted and open for submissions 28 July 2017, Deadline for submission 11 August 2017, Draft Programme published 01 September 2017, Final Program published 15 September 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/27/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Ray Bellis, for the OARC Programme Committee OARC depends on sponorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From nobody Fri May 26 05:23:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D54129498 for ; Fri, 26 May 2017 05:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 5VgG06baCzF7 for ; Fri, 26 May 2017 05:23:19 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740B4129489 for ; Fri, 26 May 2017 05:23:19 -0700 (PDT) Received: from [2001:b98:204:102:fffa::1b] (port=65408) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dEEGy-000683-It; Fri, 26 May 2017 13:23:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sara Dickinson In-Reply-To: <20170525120048.1477cea5@p50.localdomain> Date: Fri, 26 May 2017 13:23:10 +0100 Cc: IETF DNSOP WG Content-Transfer-Encoding: quoted-printable Message-Id: <37C15FB5-452F-4DA0-A63B-5ABDF5F8AD19@sinodun.com> References: <20170525120048.1477cea5@p50.localdomain> To: jtk@aharp.iorc.depaul.edu X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 12:23:21 -0000 > On 25 May 2017, at 18:00, John Kristoff wrote: >=20 >=20 >> Section 2: I think it might be useful to include a section in section >> 2 describing the fact that the lack of, or very limited >> implementation of TCP also fed the perception that it was a security >> risk. >=20 > The references >=20 > Cheswick, W. and S. Bellovin book I sadly don=E2=80=99t have a copy of that book to hand so I can=E2=80=99t = comment on the content there=E2=80=A6.=20 > > in section 2.4 I think may largely sums up the general concern. > Maybe the section 2.4 is not correctly titled or incompletely detailed > to highlight your point. Any specific text or additional references = are > welcome of course. How about: =E2=80=9CThere are many in the DNS community who configure DNS over = TCP services and expect DNS over TCP transactions to occur without interference. However there has also been a long = held belief by some operators, particularly for security-related reasons, that DNS over TCP services should be purposely limited or not = provided at all [CHES94], [DJBDNS]. =20 A popular meme has also held the imagination of some that DNS over = TCP is only ever used for zone transfers and is generally unnecessary otherwise, with filtering all DNS over TCP traffic even described as a best practice.=20 =20 The position on restricting DNS over TCP had some justification given = that historic implementations of DNS nameservers provided very little in the way of TCP connection management (for example see = Section 6.1.2 of [RFC7766]=20 for more details). However modern standards and implementations are = moving to align with the more sophisticated TCP management techniques employed by, for example, = HTTP(S) servers and load balancers.=20 >=20 >> And since it is stated as TCP related development should RFC2136 be >> there (even though it is discussed earlier)? >=20 > Probably should be there. Need I worry about section 6's length at > all? It could take up a significant portion of the document given the > way this section is going. Note, this section was added based on some > earlier feedback that having this sort of list might be helpful. If it gets too long then perhaps I could be moved to an Appendix? I = think it is very useful for reference but as you say it should not = necessarily dominate the document.=20 Sara.=20= From nobody Fri May 26 15:23:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447B8129AC1 for ; Fri, 26 May 2017 15:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RRTq5oe9ljSL for ; Fri, 26 May 2017 15:23:10 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C3812940C for ; Fri, 26 May 2017 15:23:10 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id f102so17121616ioi.2 for ; Fri, 26 May 2017 15:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gBf7UjsCIIaAX27P4KIyQuFQ7ioAgo2ZkxxKainoqoQ=; b=g5EBIxFdBo2c7AGXndhfGP+nfeSZti9dejThMDgS1zqi3NQcQDrZwNQMh2G89GaX/z Es+iTWXNIotxhLF44Ub+OTgQvOpkW3Ozf8OXVg7ochdnrhXWrymhHTy3JjgJ7DxsLkQ2 eGyDAVUefRGIeGpJzFbqq2ECd9Fqci6aQn8bYdVR8CeTi49mG9HTFZBK/1mHXS/A6cl5 VaTj4pGe3kUbc+jVmNdxIVacbrXLZhUGdkGJ0ia04o5D2mCOWK2PgWiJKp+WgLl1eI5x cQu5/OvgOE6A79pEvZagA6vNfLQ6CpDv+2BE6Ytb2TXWbiApPDHgtoNU5+24ggU7zWkF O9jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gBf7UjsCIIaAX27P4KIyQuFQ7ioAgo2ZkxxKainoqoQ=; b=dgIldBqdwILmCJzb6hOlo6oDGOyC8K2WWmcG9lvZ9Qo2QiDBNggxrsG7H13prVyBrK 72mxvO3e4PhBwIk41hAiAjVTjhjJsLyOQReOViJzm1c/cN84SMMHFZppKOrSg8sh4yrQ OULg/fMNPDGkxryYOjBVhIg6LKXQKucpBKDfKZbSxycVCt4ppict8VaLJJKVheTlXqHU r0hbfGLQiaybaygaFxhOGtT6tfYi/whI+TBIbbxGHpIVTcEj3JKSwmz1OA6DS+HZDndt Nr0IOWbIIECxpM9DqHpkT6bgy7ii1jFIEPOl+RxRa8hUGjSQBB1TenRvOhy3QhtgTMHQ TfOg== X-Gm-Message-State: AODbwcBlAPLFZwFn9d/pPZ7yRum8uBdWGpbkwvNkWDqOyhAWV/OczjaX 0cvExelNKmljkFveoUtvbjfYGnVAEQ== X-Received: by 10.107.51.14 with SMTP id z14mr4062658ioz.84.1495837389798; Fri, 26 May 2017 15:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.195 with HTTP; Fri, 26 May 2017 15:23:08 -0700 (PDT) In-Reply-To: References: From: tjw ietf Date: Fri, 26 May 2017 18:23:08 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a113a8bc842c339055074c8e7" Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 22:23:12 -0000 --001a113a8bc842c339055074c8e7 Content-Type: text/plain; charset="UTF-8" All The Call for Adoption ended last night, and there was strong consensus to adopt this document. We did hear the concerns about DNSSEC and we do not take them lightly. The chairs are confident that the authors can work out these issues. The authors can resubmit their document with the format Thanks tim On Thu, May 11, 2017 at 6:55 AM, tjw ietf wrote: > I'm caught up with my day job, and the discussion on this has died down, > but it looks like the work is moving along smoothly, it's time to kick off > a Call for Adoption on this document. (well, maybe late). > > This starts a Call for Adoption for: draft-hunt-dnsop-aname > > The draft is available here: https://datatracker. > ietf.org/doc/draft-hunt-dnsop-aname/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: Midnight 25 May 2017 > > Thanks, > tim wicinski > DNSOP co-chair > --001a113a8bc842c339055074c8e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All

The Call for Adoption ended last ni= ght, and there was strong consensus to adopt this document.=C2=A0 We did he= ar the concerns about DNSSEC and we do not take them lightly.=C2=A0 The cha= irs are confident that the authors can work out these issues.
The authors can resubmit their document with the format

Thanks
tim


On Thu, May 11, 2017 at 6:5= 5 AM, tjw ietf <tjw.ietf@gmail.com> wrote:
I'm caught up with my day=C2=A0job,=C2=A0and the discussion on this = has died down, but it looks like the work is moving along smoothly, it'= s time to kick off a Call for Adoption on this document. (well, maybe late)= .=C2=A0

This starts a Call for Adoption for:=C2=A0draft-hunt-dnsop-aname<= /div>


Please review this draft to see if you think it = is suitable for adoption by DNSOP, and comments to the list, clearly statin= g your view.

Please also indicate if you are willing to contribut= e text, review, etc.

This call for adoption ends: Midnight 25 May= 2017

Thanks,
tim wicinski
DNSOP co-chair

--001a113a8bc842c339055074c8e7-- From nobody Fri May 26 16:50:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93389129B04 for ; Fri, 26 May 2017 16:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Etb8PLuCVMPE for ; Fri, 26 May 2017 16:50:53 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0981C128DF2 for ; Fri, 26 May 2017 16:50:52 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id c15so4612756ith.0 for ; Fri, 26 May 2017 16:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WYQ4qAeKC9Dn5jecDYhADCBC/gZu+z0xlXF2IIj5kJA=; b=S3eFBXQiSTSSnVwhOkygHn1gfPNR5Pw6IOJOMzG6O7ybGzFZLNWYls5kPa6EYxITAN BSOLgabdKMcI+hPr0bzvAampKfYNggU1/p5AT/MPjkXVOgR+5O7TpoawmDxdWaINjxlH PxgMoTZn5BrXHjTyQFhBpXij5deOjML1CwbIPEcr1mwq7PTFlW0yYtXXZAwVtUM6Dfgo 0WCFOpJLNY1WhGHnp0OIqL+lGIeE8KjyalaauO/KQacj41/pBuIgt0yhtNOV38PTFuMj Rkv8va02IlW79zIQIc0JKVnqjQncbGWgng4VypNgGMR/liBin0JVVqoQlM4nkgUbLRsq 9Esg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=WYQ4qAeKC9Dn5jecDYhADCBC/gZu+z0xlXF2IIj5kJA=; b=Ap8ugfFiEQvbQKD6/x372KapyIujVQCptNh1hZbzx3QsC0UuDfwOD7EOPr0ht448Np GyMv/lSa58MpQVXHlJa6huaulaWOJd/fTbvTKcQp5j5dDRPOwL/LC1J7afGZ3oERuWlM waMzmYN0v3PyP8fwuKfp8gSL3xpPfJsJ13xOttrf2qAGM6QXhJ0sljRvwT5XI6BlEsn2 kabdmsvgNY3t/W//iKeHyRLx8M8BwT30kiq6vhAQoVxR0n+0QrIOe9cVCZikefuBiFbI QXkSC3WNqfWS4r8A39wu/NCyGHElz7tmH8hxh+zllSQdIAEfKOHx4xVWPxLxA7EcgUCs 5BWg== X-Gm-Message-State: AODbwcB6sW+EnjXacS0hjtBHrbMo3gVgkksSVde5BWy+mQ8W8dVaekYX odYbrsjhz/KgLPEZQ3CgMJCzKJcrkINc X-Received: by 10.36.152.2 with SMTP id n2mr5360279itd.41.1495842651800; Fri, 26 May 2017 16:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.195 with HTTP; Fri, 26 May 2017 16:50:51 -0700 (PDT) In-Reply-To: References: From: tjw ietf Date: Fri, 26 May 2017 19:50:51 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="94eb2c05a688e6ac3805507601d8" Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 23:50:55 -0000 --94eb2c05a688e6ac3805507601d8 Content-Type: text/plain; charset="UTF-8" All The Call for Adoption ended last night, and there was consensus to adopt this document much like their was in Chicago, We will hold those volunteers to their promise to review, and we'll have the authors upload new versions of the draft. the chairs On Thu, May 11, 2017 at 6:57 AM, tjw ietf wrote: > There was a lot of consensus during our last meeting in Chicago that this > should move forward, so it's time that we do so. > > This starts a Call for Adoption for: draft-kristoff-dnsop-dns- > tcp-requirements > > The draft is available here: https://datatracker. > ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: Midnight 25 May 2017 > > Thanks, > tim wicinski > DNSOP co-chair > --94eb2c05a688e6ac3805507601d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All<= div style=3D"font-size:12.800000190734863px">
The Call for Adoption ended last night, and there= was consensus to adopt this document much like their was in Chicago, We wi= ll hold those volunteers to their promise to review, and we'll have the= authors upload new versions of the draft.

= the chairs

On Thu, May 11, 2017 at 6:57 AM, tjw ietf <tjw.ietf@gmail.com>= ; wrote:
There was a lot of consen= sus during our last meeting in Chicago that this should move forward, so it= 's time that we do so.=C2=A0

This starts a Call for Adoption = for:=C2=A0draft= -kristoff-dnsop-dns-tcp-requirements

<= span style=3D"font-family:monospace;font-size:14px">The draft is available = here:=C2=A0https://datatracker.ietf.org/doc/draft-kristoff-<= wbr>dnsop-dns-tcp-requirements/

Please review this draft to see if y= ou think it is suitable for adoption by DNSOP, and comments to the list, cl= early stating your view.

Please also indicate if you are willing = to contribute text, review, etc.

This call for adoption ends: Mid= night 25 May 2017

Thanks,
tim wicinski
DNSOP co-chair

--94eb2c05a688e6ac3805507601d8-- From nobody Sat May 27 14:36:06 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0DC1200F1; Sat, 27 May 2017 14:36:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149592096439.3966.11385984990945858242@ietfa.amsl.com> Date: Sat, 27 May 2017 14:36:04 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 21:36:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Address-specific DNS Name Redirection (ANAME) Authors : Evan Hunt Peter van Dijk Anthony Eden Filename : draft-ietf-dnsop-aname-00.txt Pages : 10 Date : 2017-05-27 Abstract: This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only redirects type A and AAAA queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to redirect queries for apex domain names in a standards compliant manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-aname-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 13:23:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EB0124D37 for ; Mon, 29 May 2017 13:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 dCEW61t_jP7T for ; Mon, 29 May 2017 13:23:13 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 5791E1205D3 for ; Mon, 29 May 2017 13:23:13 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E794B31D2B; Mon, 29 May 2017 22:23:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 51635190AB6; Mon, 29 May 2017 22:20:47 +0200 (CEST) Date: Mon, 29 May 2017 22:20:47 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170529202047.GB25128@sources.org> References: <148853300022.10133.1786841727275160096.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148853300022.10133.1786841727275160096.idtracker@ietfa.amsl.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.7 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:23:16 -0000 On Fri, Mar 03, 2017 at 01:23:20AM -0800, internet-drafts@ietf.org wrote a message of 46 lines which said: > Title : A Common Operational Problem in DNS Servers - Failure To Respond. > Author : M. Andrews > Filename : draft-ietf-dnsop-no-response-issue-08.txt I've read it and, to summarize, I like the idea (documenting all the bad things that can happen when you don't reply, or don't reply correctly) but I dislike the document in its current form, and I regret that several objections raised seem to have been forgotten. May be because one or two emails on this list is not WG consensus? If so, let me add my opinion, even if it means I'll repeat things already said. First problem, is the draft about "no response", as its title suggest, or also about wrong responses? It is not clear and would require some editing. Since there have been several discussions on the list about "is it legitimate for a server not to reply?", I suggest a section on that. Second problem, section 3 is confusing: it mixes description of the problem, and possible remediations. 3.2.6, for instance, is very unclear: does it mean DNSSEC is mandatory? What is this (lowercase) "should"? This problem was already reported in and Third, section 8 seems to be something quite different, a series of "standard" tests to run against name servers, something which was tried several times in the IETF, or RIPE, or other places, and always failed (see for instance draft-wallstrom-dnsop-dns-delegation-requirements). Fourth, section 9 goes into politics and suggest widely unrealistic remedies, such as depublishing a domain. (This serious problem was already reported in and .) Fifth, the draft does not mention some important documents. For instance, the draft talks a lot about unknown RR types but do not mention RFC 3597. When it does mention RFCs, it does not always do it correctly. For instance, section 7 claims that RFC 1034 says that a name server must not load a zone with unsupported types, without being specific on which section of RFC 1034 says so (I was not able to find it). The draft needs a lot of changes. My preferate way would be to trim it down to just a description of what happens when you don't reply (the evil consequences). Mostly section 2 and a part of section 3, with may be some of section 8 as an appendix. From nobody Tue May 30 08:23:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716B21293DA; Tue, 30 May 2017 08:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.821 X-Spam-Level: X-Spam-Status: No, score=-11.821 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LF5W3T-ovqwk; Tue, 30 May 2017 08:23:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE998128BB6; Tue, 30 May 2017 08:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7715; q=dns/txt; s=iport; t=1496157784; x=1497367384; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=0TbS+OBTxPT8Fh35vSLke2I2NKcoTH3ChVfRkkV9x9s=; b=Hn2IJlUhJqiTfdUqOxvjsAab8gnIUu3YRAKSYDmBtDhuFeAVnqFNGcSv sFoZiSjj7rOQXoMLZuV0Nt4xUXjsRPXlzGS/BUuOFU5pY1EQNlS5geLt5 jNJi9Os0pUj8gb2Zk4cT75Ohfd6iftgYzeCkijyruKdP8vmEW6fk2LsQX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAwBojS1Z/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDeBDYNyiwuQVZBihTiCDy6FdgKDERYBAgEBAQEBAQFrKIUZBAIjVhB?= =?us-ascii?q?NAgJXEwgBAReKDxCtA4ImK4sgAQEBAQEFAQEBAQEBARwFhmGBYCsLhxaDToJgB?= =?us-ascii?q?ZAphlCHKocgjAiLC4ZsjBqINCYBMIEKMCEIGxVGhwQ+NgGJUgEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,418,1491264000"; d="scan'208,217";a="653204827" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2017 15:22:59 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4UFMxkl011294; Tue, 30 May 2017 15:22:59 GMT References: <03bebcc5-ba95-9bbe-be07-6efb2034f9d6@cisco.com> From: Benoit Claise To: draft-ietf-dnsop-sutld-ps.all@ietf.org Cc: "dnsop@ietf.org" X-Forwarded-Message-Id: <03bebcc5-ba95-9bbe-be07-6efb2034f9d6@cisco.com> Message-ID: <38aae5ba-80d5-1f5c-0263-459de3ed7bda@cisco.com> Date: Tue, 30 May 2017 17:22:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <03bebcc5-ba95-9bbe-be07-6efb2034f9d6@cisco.com> Content-Type: multipart/alternative; boundary="------------F237C2B3133E9D71C8F45FB4" Content-Language: en-US Archived-At: Subject: [DNSOP] AD review: draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:23:06 -0000 This is a multi-part message in MIME format. --------------F237C2B3133E9D71C8F45FB4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Here is my AD review. - This section presents a list of problems that have been identified with respect to the assignment of Special-Use Domain Names. Solutions to these problems, including their costs or tradeoffs, are out of scope for this document. There is a broad diversity of opinion about this set of problems. Not every participant agrees that each of the problems enumerated in this document is actually a problem. This document takes no position on the relative validity of the various problems that have been enumerated. Its focused purposes are to enumerate those problems, provide the reader with context for thinking about them and provide a context for future discussion of solutions. So you want to write something such as ... regardless of whether the problems are valid ones AND regardless of the ownership (IETF, IANA, ICANN, or ...) And it seems that you didn't try to categorize the problems per ownership (this is an IETF or ICANN problem, as an example). I guess that this is the way you approached this document, right? You should document this. - gTLD Generic Top-Level Domain, as defined in in section 2 of RFC 7719 [RFC7719] gTLD is not strictly defined in RFC7719, only TLD - correct the .home section in 4.2.7, which is solved with Errata ID: 4677 _MINOR_ - [SDO-ICANN-DAG] Internet Assigned Numbers Authority, "Special-Use Domain Names registry", October 2015, full-04jun12-en.pdf > Don't you have a more up to date reference (2012)? First page of this document is: "Currently the namespace consists of 22 gTLDs and over 250 ccTLDs operating on various models." - o There are several Domain Name TLDs that are in use without due process for a variety of purposes [SDO-ICANN-COLL ]. The status of these names need to be clarified and recorded to avoid future disputes about their use. I don't understand the sentence "There are several Domain Name TLDs that are in use without due process for a variety of purposes", with a reference that speaks about "Name Collision in the DNS". _EDITORIAL:_ - "in in". Two occurences in TLD Top-Level Domain, as defined in in section 2 of RFC 7719 [RFC7719] gTLD Generic Top-Level Domain, as defined in in section 2 of RFC 7719 [RFC7719] - OLD: Special-Use Domain Name A Domain Name listed in the Special-Use Domain Names registry. NEW: Special-Use Domain Name A Domain Name listed in the Special-Use Domain Names registry [SDO-IANA-SUDR]. - OLD: The history ofRFC 6762 is documented in substantial detail in Appendix H NEW: The history ofRFC 6762 is documented in substantial detail in Appendix H of RFC 6762 - Expand SSAC on the first occurrence. Regards, Benoit --------------F237C2B3133E9D71C8F45FB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Dear authors,

Here is my AD review.


- 
   This section presents a list of problems that have been identified
   with respect to the assignment of Special-Use Domain Names.
   Solutions to these problems, including their costs or tradeoffs, are
   out of scope for this document. 

   There is a broad diversity of opinion about this set of problems.
   Not every participant agrees that each of the problems enumerated in
   this document is actually a problem.  This document takes no position
   on the relative validity of the various problems that have been
   enumerated.  Its focused purposes are to enumerate those problems,
   provide the reader with context for thinking about them and provide a
   context for future discussion of solutions.

So you want to write something such as  ... regardless of whether the problems are valid ones AND regardless of the ownership (IETF, IANA, ICANN, or ...) 
And it seems that you didn't try to categorize the problems per ownership (this is an IETF or ICANN problem, as an example).
I guess that this is the way you approached this document, right? You should document this.

- 
gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
7719 [RFC7719]

gTLD is not strictly defined in RFC7719, only TLD

- correct the .home section in 4.2.7, which is solved with Errata ID: 4677 


MINOR
- 

   [SDO-ICANN-DAG]
              Internet Assigned Numbers Authority, "Special-Use Domain
              Names registry", October 2015,
              <https://newgtlds.icann.org/en/applicants/agb/guidebook-
              full-04jun12-en.pdf>

Don't you have a more up to date reference (2012)?
First page of this document is: "Currently the namespace consists of 22 gTLDs and over 250 ccTLDs operating on various models."

-
   o  There are several Domain Name TLDs that are in use without due
      process for a variety of purposes [SDO-ICANN-COLL].  The status of
      these names need to be clarified and recorded to avoid future
      disputes about their use.

I don't understand the sentence "There are several Domain Name TLDs that are in use without due
      process for a variety of purposes", with a reference that speaks about "Name Collision in the DNS".


EDITORIAL:
- "in in". Two occurences in
TLD Top-Level Domain, as defined in in section 2 of RFC 7719
[RFC7719]
gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
7719 [RFC7719]

- OLD:
   Special-Use Domain Name  A Domain Name listed in the Special-Use
      Domain Names registry.
NEW:
   Special-Use Domain Name  A Domain Name listed in the Special-Use
      Domain Names registry [SDO-IANA-SUDR].

- OLD:
   The history of RFC 6762 is documented in substantial detail in
   Appendix H

NEW: 
   The history of RFC 6762 is documented in substantial detail in
   Appendix H of RFC 6762

- Expand SSAC on the first occurrence.
 
Regards, Benoit
--------------F237C2B3133E9D71C8F45FB4-- From nobody Wed May 31 12:44:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6B7128B44 for ; Wed, 31 May 2017 12:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 9nZqzeJyb5Jb for ; Wed, 31 May 2017 12:44:50 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B11128ACA for ; Wed, 31 May 2017 12:44:50 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 May 2017 12:44:48 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 31 May 2017 12:44:47 -0700 From: Edward Lewis To: Michael StJohns CC: "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt Thread-Index: AQHS1MftY4O5fSLaF0OP5Dkuz6lW3qIEArj2gAG+IQCAACNYAP//98VtgACPvoCACKm9AA== Date: Wed, 31 May 2017 19:44:46 +0000 Message-ID: References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> <20170526015222.C1FE979B8C4F@rock.dv.isc.org> <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com> In-Reply-To: <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3579090286_1704327394" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:44:52 -0000 --B_3579090286_1704327394 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Coming late to this thread, I have a question. How many operational instances of "Automated Updates" [RFC 5011] are there? Besides the root zone KSK, I don't know of any. I do some monitoring of DNSSEC practices, years ago I noticed one TLD appearing to follow RFC 5011's semantics. But in recent looks that TLD seems to have abandoned the practice (I've never made contact to confirm). In a scan of second-level names a month ago, I found only traces of revoked keys (KSK and ZSK!). I ask because of the issues raised in the thread regarding the number of keys assumed in the operation. Automated Updates apparently (to me) was defined with more than one active secure entry point in mind, but in practice, the only operating example I've witnessed of Automated Updates relies on a single active secure entry point. I've asked around (tool developers) and, so far, no other examples have popped up. I'm sure there are some out there. --B_3579090286_1704327394 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUuxge2InfzWwVLwIK vFQuEpgXusUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NTMxMTk0NDQ2WjANBgkqhkiG9w0BAQEFAASCAQAWyQ+RCh6PXDSdwN8ab3Z3NP40YwMD0HP5 Uxt0HtOT3OH/yMmthDl0Wa/rB798I8ovt0VZ4ei36/BUuS5G3mZnbFFHqotZz2S+bEgyPn0X nR+ljpp3lvdIaeLxIv/excD7IOb8TKHffIRbf9WeLJdBEJUs9pD2hW9IpogyfntV2fg/TnQk x5E6nrPxsGD3Z9f0vll63TmDC6ho+phPVMN0jlFffADdgKrFFFojFKZwXNi3UAEVTTnuFSnm N2hPkdZMYEuQquIqzQTuS/s5qlfsQO9ZqYd4IeFDa2daacgtC1ta1MCRnuBi479s5gu6NK63 laDq3CwECV32wtRTYtEw --B_3579090286_1704327394-- From nobody Wed May 31 13:54:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E6D129BA2 for ; Wed, 31 May 2017 13:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 SWq8l1nVgTBa for ; Wed, 31 May 2017 13:54:17 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3E5124B0A for ; Wed, 31 May 2017 13:54:17 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 May 2017 13:54:15 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 31 May 2017 13:54:14 -0700 From: Edward Lewis To: "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt Thread-Index: AQHS1MftY4O5fSLaF0OP5Dkuz6lW3qIEArj2gAG+IQCAACNYAP//98VtgACPvoCACKm9AIAAE2gA Date: Wed, 31 May 2017 20:54:14 +0000 Message-ID: <988BC4E0-4695-4E84-9D1A-1C05CFFF94B4@icann.org> References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> <20170526015222.C1FE979B8C4F@rock.dv.isc.org> <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3579094454_811668187" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 20:54:19 -0000 --B_3579094454_811668187 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Answering my own question...relooking at my data, I see two TLD operators (running a total of 4 zones) revoking KSK's on a regular basis. On 5/31/17, 15:44, "Edward Lewis" wrote: Coming late to this thread, I have a question. How many operational instances of "Automated Updates" [RFC 5011] are there? Besides the root zone KSK, I don't know of any. I do some monitoring of DNSSEC practices, years ago I noticed one TLD appearing to follow RFC 5011's semantics. But in recent looks that TLD seems to have abandoned the practice (I've never made contact to confirm). In a scan of second-level names a month ago, I found only traces of revoked keys (KSK and ZSK!). I ask because of the issues raised in the thread regarding the number of keys assumed in the operation. Automated Updates apparently (to me) was defined with more than one active secure entry point in mind, but in practice, the only operating example I've witnessed of Automated Updates relies on a single active secure entry point. I've asked around (tool developers) and, so far, no other examples have popped up. I'm sure there are some out there. --B_3579094454_811668187 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUkumkLpcruTMzoJ2U CrjYUfvi0hQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NTMxMjA1NDE0WjANBgkqhkiG9w0BAQEFAASCAQCi0QMNL/c+8BrPZfGDoP6CGgYr+IRcG9k7 ppLjQYrGIIeP0Mk0dv3eUDy08kZOBSJG+3pCr5svJn501JZIVp7Dcav230SxqcTHwCjJ3xfW KzrX7/7ApSQbPiJSXizF88VrE1gPTlFjD64FmZXbX66G9CN0RGO3hL4nyZBl/1f/MjA2hJkm 2kL9mVDGWkLcuatCnzidkXRCn5m095NBXYdSbdyRtuSOIdjsNfpVha/d0CPpSQJpcTcxQatN 5AAxl5xZs7CUTpEsTTqh6uYg0n4eQOZqZltc4lacBLeMP0fqEYh9Ox9L8TlWA+NyNU61ylQs CZHOz+iH77LFoLi/Bxh/ --B_3579094454_811668187--