From nobody Sun Jan 1 10:20: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 36D10129455 for ; Sun, 1 Jan 2017 10:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1] 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 CnQwC1amyGmC for ; Sun, 1 Jan 2017 10:20:23 -0800 (PST) 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 9DEBD129448 for ; Sun, 1 Jan 2017 10:20:23 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ts7mM4wrjz3Wp for ; Sun, 1 Jan 2017 19:20:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483294819; bh=qVmH2kI1V7hMJebp9QNVVEU59+vvFti1s9iGwnsONx8=; h=Date:From:To:Subject:In-Reply-To:References; b=txHN7Z16xJJQ5FJ/l3/Mmu/Q6BsHn8C+MsuPEfJzH6nwBNzouI2oKtmebBtii67V/ jBjhkgPgN7RQcsdQzHM06BsHHTdzSnGXuOy31o+1hCCNxoWJKo4xH2XV1E7nyqwsuT UcwUS3Ycb7/pQlv3G8Ab3PRgNBE7OjVu2HHubmrg= 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 Ax2hIDCKVeb8 for ; Sun, 1 Jan 2017 19:20:17 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 1 Jan 2017 19:20:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A3810CA34A4; Sun, 1 Jan 2017 13:20:14 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A3810CA34A4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CCDF4942C63 for ; Sun, 1 Jan 2017 13:20:14 -0500 (EST) Date: Sun, 1 Jan 2017 13:20:14 -0500 (EST) From: Paul Wouters To: dnsop In-Reply-To: <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com> Message-ID: References: <20161229040637.GA26031@odin.ulthar.us> <20161229054559.31443.qmail@ary.lan> <20161231202731.GX13486@mournblade.imrryr.org> <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 18:20:26 -0000 On Sat, 31 Dec 2016, Ted Lemon wrote: > There is no _way_ to make it easier for said outside forces to pressure providers.   They have the force > of law on their side.   What we do makes no difference in that arena.   The arena in which it _does_ > make a difference is protecting people from losing their homes because they got suckered by some malware > that got into their personal records on their computer. > > IOW, the argument you are presenting has nothing to do with the choice that faces us.   If you want to > make the case for rpz being a bad thing, the argument you should be making would have to show why > protecting people in this way is the wrong solution to the problem, and why some other solution to the > problem (e.g., a blacklist in the browser) is less bad. > > Can’t we have that conversation, instead of these repeated assertions about things over which we have no > control? Some of us tried that and were told "that's not how RPZ works, we are not changing how RPZ works". The only thing I asked for is tracability and accountability, but not witholding DNSSEC information but by passing it along in a different section so that: - RPZ still works as it does now for existing users/providers - In the future RPZ filtering cannot be used as an out-of-the-box involuntary censorship tool. - Accountability can be added by adding a different key of last mile trust anchor. I'm interested in hearing technical reasons why this change cannot be done, and lacking those, I would hope the WG does not adopt this document if the authors are unwilling to make the changes to facilitate this.. Paul From nobody Sun Jan 1 14:43: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 CD135129408 for ; Sun, 1 Jan 2017 14:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 czPuSKlKNj3q for ; Sun, 1 Jan 2017 14:43:24 -0800 (PST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 00B571270B4 for ; Sun, 1 Jan 2017 14:43:23 -0800 (PST) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v01Mh9de005063 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Sun, 1 Jan 2017 22:43:09 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v01Mh84e005062 for dnsop@ietf.org; Sun, 1 Jan 2017 22:43:08 GMT Date: Sun, 1 Jan 2017 22:43:08 GMT From: Vernon Schryver Message-Id: <201701012243.v01Mh84e005062@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 22:43:36 -0000 > From: Paul Wouters > Some of us tried that and were told "that's not how RPZ works, we are > not changing how RPZ works". As I've repeatedly written, the purpose of the current draft is to describe the current RPZ protocol. The current draft and the protocol it describes are not intended to and cannot prevent the specification of other protocols, include protocols that might be called "RPZ." > The only thing I asked for is tracability and accountability As much tracability and accountability as can be hoped for is already present with the RPZ SOA in the additional section. > but not > witholding DNSSEC information but by passing it along in a different > section so that: > > - RPZ still works as it does now for existing users/providers > > - In the future RPZ filtering cannot be used as an out-of-the-box > involuntary censorship tool. > > - Accountability can be added by adding a different key of last > mile trust anchor. > > I'm interested in hearing technical reasons why this change cannot be > done, ... Paul Wouters has not made his idea clear to me (but let's keep talk about it public at least as far as I'm concerned). My best guesses about it conclude that putting RRs that as far as DNS clients could tell are irrelevant to the answer section into the authority section would make some clients unhappy. (Since it's not my idea, never mind that I suspect that fewer DNS clients might break if apparently irrelevant RRs were added to the additional section instead of the authority section.) On the other hand, Paul Woulters' ostensible goal is presumably that the organizations responsible for any rewriting to be identifiable during the investigations of problems and then held accountable. They are - men hidden in the middle using mechanisms other than RPZ, but it would be silly to expect them to step forward to be traced or held accountable. - the people running the recursive resolver with RPZ that sent the rewritten response, but the IP address of the recursive resolver already identifies them - the people that provided the policy zone containg the rule that used to modify the response, but the SOA already in the additional section points to them and also identifies the version of the rule. But these guesses of mine about the idea are irrelevant. Someone should write a technical proposal for the idea and submit it as an I-D or here as words that could be added to the current RPZ draft. That someone is not me; I told Paul Wouters in response to his private mail on Dec 22: ] Please write whatever Internet Drafts that are needed, but please ] understand that I have no current interest in a new kind of RPZ. ] ... ] No, your proposals for new rtypes and shifting A and AAAA RRsets from ] the answer section to authority section might be good and reasonable ] in another context, but they are irrelevant to a description of RPZ ] as it currently exists. Vernon Schryver vjs@rhyolite.com From nobody Mon Jan 2 09:48:32 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 8320B128B38; Mon, 2 Jan 2017 09:48:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148337930553.21885.17516942356657336528.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 09:48:25 -0800 Archived-At: Cc: Tim Wicinski , draft-ietf-dnsop-edns-key-tag@ietf.org, joelja@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org Subject: [DNSOP] Last Call: (Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)) to Proposed Standard X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 17:48:25 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. This document describes two independent methods for validating resolvers to publish their referenced keys: an EDNS option and a different DNS query. The reason there are two methods instead of one is some people see significant problems with each method. Having two methods is clearly worse than having just one, but it is probably better for the Internet than having no way to gain the information from the resolvers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jan 3 06:29: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 A6F191299B7 for ; Tue, 3 Jan 2017 06:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 c48JdSWI8e2f for ; Tue, 3 Jan 2017 06:29:12 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) by ietfa.amsl.com (Postfix) with ESMTP id 63DEA1294C1 for ; Tue, 3 Jan 2017 06:29:12 -0800 (PST) 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]:51859) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cOQ5N-000MZF-0u (Exim 4.86_36-e07b163) (return-path ); Tue, 03 Jan 2017 14:29:09 +0000 Date: Tue, 3 Jan 2017 14:29:08 +0000 From: Tony Finch To: joel jaeggli In-Reply-To: Message-ID: References: <201612291815.uBTIFdW4015802@calcite.rhyolite.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: Vernon Schryver , dnsop , william manning Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 14:29:13 -0000 joel jaeggli wrote: > On 12/29/16 1:51 PM, william manning wrote: > > if this work does proceed, i'd like to insist that it carry a > > disclaimer that it is designed specifically for closed networks and is > > not to be used in the Internet. > > this sounds like an aplicability statement to be included in the > introduction. I don't understand what "not to be used in the Internet" means for RPZ. Part of the point of standardizing it is interoperability between multiple RPZ resolver implementations and multiple RPZ data providers. The resolver operator gets the RPZ data via IXFR across the Internet. Is this bad? Or maybe "not to be used in the Internet" is something to do with who uses resolvers with RPZ blocks. Open resolvers are horrible abuse magnets and should not be available for use by the whole Internet unless their operators have impressive anti-DDoS skills. But that isn't an RPZ-specific problem. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Southwest Shannon: Southeasterly 5 to 7. Moderate or rough. Fair. Good. From nobody Tue Jan 3 09:18: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 AB2D9129A63 for ; Tue, 3 Jan 2017 09:18:38 -0800 (PST) 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 I5_pCd-Mvf6q for ; Tue, 3 Jan 2017 09:18:36 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 64430129A5E for ; Tue, 3 Jan 2017 09:18:36 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id h133so198310292ioe.3 for ; Tue, 03 Jan 2017 09:18:36 -0800 (PST) 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=HVBvsV1WoxchL8sCwx7CexC0hGU2H9N4yvrtYwiOD7o=; b=q+qhMREHP4KtCjoYo3bxAosPbE5Ajcirin3NcEWiWHBLJoPjoQ/WXXoi30F2OR1aV/ wgfOHZwwWMYJMB3mN+3w/5QrNvctjT0TFB3WosBldHcrzyluu7j0xQjSG/puxhuOSX/x GIr1uaeMRUWyl4rsO4guPa4pWievhxBBaHhUM3l9m3LSIo50npwxaAyn1yxojaVVWGR0 /FyOgjFsK5cvmDWw/kQXyyiin6D49d6w+jaVHvm3VLMRhQN4Is9zhKqeZt8Go1+mQmsI 4m4MSbmo9TdEZJiV5ff7hFfCFTbT8UbT/2j5inQG5GbJ11AcFXIJgpcKCx+w6Mxg/4dJ OJhg== 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=HVBvsV1WoxchL8sCwx7CexC0hGU2H9N4yvrtYwiOD7o=; b=nU6vXtK6OT/xzqq6KKZ64ygVkzZW+6kfE3Wv8PU+rIATBf+/Ul1napq/BdaImzRe5K PpjgXn29EEtUpwZ+2DT9jXJLPVLWf+TP8engw18GphIMbrSI8LhkRc57Fp8f00ACGekL m56Q6/yaEBIA0mbF0hGY+KAYiwutXCcu3PQj0Ch1LhYm/PBgFqKK5Z39zAuOmz/B2h58 K1BGc40p97ec/TAmoC7ELsrk7Ibz8jYjH3v86ELgwrqbzH50lfEOLHZ0uZCdNQac63xa hGw1twymGKn28JudkbS8Y1Tp4wgu7o8kOp5aLrZyy8el5a0dv2JpWcKOkkabzomtZroc ujaA== X-Gm-Message-State: AIkVDXJVovlxkhIUo7aTb91XWhi2WJ1sddAiYcjTCqIym1Rox7fYk9LEUxGU4MoRydRBrzrc3QeEZE++JELBgA== X-Received: by 10.107.9.198 with SMTP id 67mr1178116ioj.0.1483463915692; Tue, 03 Jan 2017 09:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.159.137 with HTTP; Tue, 3 Jan 2017 09:18:34 -0800 (PST) In-Reply-To: References: <201612291815.uBTIFdW4015802@calcite.rhyolite.com> From: william manning Date: Tue, 3 Jan 2017 09:18:34 -0800 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=001a113ec2c4bb8afe054533db2b Archived-At: Cc: Vernon Schryver , dnsop Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:18:38 -0000 --001a113ec2c4bb8afe054533db2b Content-Type: text/plain; charset=UTF-8 ok. here is a draft applicability statement. This draft is documents a process and method for intercepting DNS queries and fabricating responses to redirect the querier into a walled garden or enclave that is NOT part of the open Internet. Adoption and acceptance of this draft is an acknowledgement that the IETF, the IAB and ISOC reject the principles espoused at https://open-stand.org/about-us/principles/, in particular article 3. Collective Empowerment insofar as the evolution of the DNS is concerned. /Wm On Thu, Dec 29, 2016 at 6:30 PM, joel jaeggli wrote: > On 12/29/16 1:51 PM, william manning wrote: > > "lets standardize this 'cause everyone does it" sounds like the medical > > community should have standardized on whiskey & leaches & coat hangers > > because thats what everyone did. if this work does proceed, i'd like to > > insist that it carry a disclaimer that it is designed specifically for > > closed networks and is not to be used in the Internet. > > this sounds like an aplicability statement to be included in the > introduction. > > > Indeed, thedraft is very clear this is for enclaves and not for open > > Internet use. > > > > > > /Wm > > > > On Thu, Dec 29, 2016 at 10:15 AM, Vernon Schryver > > wrote: > > > > > From: Richard Clayton > > > > > > > Everyone involved understands that there isn't at present a turnkey > > > application that the other 5% (and indeed all the in-house > corporate > > > systems) could deploy.... > > > > I do not understand that. > > If the command `nslookup -q=txt -class=CHAOS version.bind` to a UNIX > > shell or Windows command prompt on your desktop says anything about > > BIND, then chances are good that you are already using one of the > > turnkey applications that in-house corporate systems and others have > > already deployed and could configure. Even if there is no sign of > > BIND9 from that `nslookup` command, the odds are good that the > recursive > > server you use has an RPZ taint or will have within months. > > > > > > > So although deploying RPZ does a reasonable job of papering over > the > > > cracks in our response to cybercrime I think that on balance it's > too > > > dangerous a tool for the IETF to wish to bless in any way -- it's > poor > > > social hygiene to standardise these types of tools. > > > > While I understand how a reasonable person can hold that position, > > I think the papered cracks are not only less bad, but the best that > > can be hoped for in the real world. > > > > > > > I also note from reading the draft that this blessing will freeze > in > > > some rather ugly design (with the authors arguing that the > installed > > > base cannot adjust to something cleaner). > > > > That is not the intended meaning of the draft. Instead it tried to > > acknowledge the extreme difficulty of changing an installed base. > > Words that convey that intended meaning would be appreciated. > > > > > > Vernon Schryver vjs@rhyolite.com > > > > _______________________________________________ > > 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 > > > > > --001a113ec2c4bb8afe054533db2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ok. =C2=A0 here is a draft applicability statement.
This draft is documents a process and method for intercepting = DNS queries and fabricating responses to redirect the querier into a walled= garden or enclave that is NOT part of the open Internet. Adoption and acce= ptance of this draft is an acknowledgement that the IETF, the IAB and ISOC = reject the principles espoused at=C2=A0https://open-stand.org/about-us/principles/, in par= ticular article 3.=C2=A0 Collective Empowerment insofar as the evolution of= the DNS is concerned.

/Wm


On Thu, Dec 29= , 2016 at 6:30 PM, joel jaeggli <joelja@bogus.com> wrote:
=
On 12/29/16 1:51 PM, willia= m manning wrote:
> "lets standardize this 'cause everyone does it"=C2=A0 so= unds like the medical
> community should have standardized on whiskey & leaches & coat= hangers
> because thats what everyone did.=C2=A0 if this work does proceed, i= 9;d like to
> insist that it carry a disclaimer that it is designed specifically for=
> closed networks and is not to be used in the Internet.

this sounds like an aplicability statement to be included in the
introduction.

> Indeed, thedraft is very clear this is for enclaves and not for open > Internet use.
>
>
> /Wm
>
> On Thu, Dec 29, 2016 at 10:15 AM, Vernon Schryver <vjs@rhyolite.com
> <mailto:vjs@rhyolite.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0> From: Richard Clayton <richard@highwayman.com
>=C2=A0 =C2=A0 =C2=A0<mailto:richard@highwayman.com>>
>
>=C2=A0 =C2=A0 =C2=A0> Everyone involved understands that there isn&#= 39;t at present a turnkey
>=C2=A0 =C2=A0 =C2=A0> application that the other 5% (and indeed all = the in-house corporate
>=C2=A0 =C2=A0 =C2=A0> systems) could deploy....
>
>=C2=A0 =C2=A0 =C2=A0I do not understand that.
>=C2=A0 =C2=A0 =C2=A0If the command `nslookup -q=3Dtxt -class=3DCHAOS ve= rsion.bind` to a UNIX
>=C2=A0 =C2=A0 =C2=A0shell or Windows command prompt on your desktop say= s anything about
>=C2=A0 =C2=A0 =C2=A0BIND, then chances are good that you are already us= ing one of the
>=C2=A0 =C2=A0 =C2=A0turnkey applications that in-house corporate system= s and others have
>=C2=A0 =C2=A0 =C2=A0already deployed and could configure.=C2=A0 Even if= there is no sign of
>=C2=A0 =C2=A0 =C2=A0BIND9 from that `nslookup` command, the odds are go= od that the recursive
>=C2=A0 =C2=A0 =C2=A0server you use has an RPZ taint or will have within= months.
>
>
>=C2=A0 =C2=A0 =C2=A0> So although deploying RPZ does a reasonable jo= b of papering over the
>=C2=A0 =C2=A0 =C2=A0> cracks in our response to cybercrime I think t= hat on balance it's too
>=C2=A0 =C2=A0 =C2=A0> dangerous a tool for the IETF to wish to bless= in any way -- it's poor
>=C2=A0 =C2=A0 =C2=A0> social hygiene to standardise these types of t= ools.
>
>=C2=A0 =C2=A0 =C2=A0While I understand how a reasonable person can hold= that position,
>=C2=A0 =C2=A0 =C2=A0I think the papered cracks are not only less bad, b= ut the best that
>=C2=A0 =C2=A0 =C2=A0can be hoped for in the real world.
>
>
>=C2=A0 =C2=A0 =C2=A0> I also note from reading the draft that this b= lessing will freeze in
>=C2=A0 =C2=A0 =C2=A0> some rather ugly design (with the authors argu= ing that the installed
>=C2=A0 =C2=A0 =C2=A0> base cannot adjust to something cleaner).
>
>=C2=A0 =C2=A0 =C2=A0That is not the intended meaning of the draft.=C2= =A0 Instead it tried to
>=C2=A0 =C2=A0 =C2=A0acknowledge the extreme difficulty of changing an i= nstalled base.
>=C2=A0 =C2=A0 =C2=A0Words that convey that intended meaning would be ap= preciated.
>
>
>=C2=A0 =C2=A0 =C2=A0Vernon Schryver=C2=A0 =C2=A0 vjs@rhyolite.com <mailto:vjs@rhyolite.com>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0DNSOP mailing list
>=C2=A0 =C2=A0 =C2=A0DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/dnsop
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/dnsop>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=
>



--001a113ec2c4bb8afe054533db2b-- From nobody Tue Jan 3 22:17: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 8B297129C3E for ; Tue, 3 Jan 2017 22:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-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 M1kxZ8T7Ezfm for ; Tue, 3 Jan 2017 22:17:44 -0800 (PST) Received: from smtp133.dfw.emailsrvr.com (smtp133.dfw.emailsrvr.com [67.192.241.133]) (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 67729129668 for ; Tue, 3 Jan 2017 22:17:44 -0800 (PST) Received: from smtp13.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id D40C12027B; Wed, 4 Jan 2017 01:17:43 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp13.relay.dfw1a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 06F0D203FD; Wed, 4 Jan 2017 01:17:42 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from sin-mpgjx.singapore.corp.akamai.com ([UNAVAILABLE]. [23.62.225.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 04 Jan 2017 01:17:43 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Barry Raveendran Greene In-Reply-To: <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com> Date: Wed, 4 Jan 2017 14:17:39 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <07899541-1075-48C0-A4C2-588E012D020B@senki.org> References: <20161229040637.GA26031@odin.ulthar.us> <20161229054559.31443.qmail@ary.lan> <20161231202731.GX13486@mournblade.imrryr.org> <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnsop Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 06:17:45 -0000 > On Jan 1, 2017, at 6:00 AM, Ted Lemon wrote: >=20 > There is no _way_ to make it easier for said outside forces to = pressure providers. They have the force of law on their side. What = we do makes no difference in that arena. The arena in which it _does_ = make a difference is protecting people from losing their homes because = they got suckered by some malware that got into their personal records = on their computer. >=20 > IOW, the argument you are presenting has nothing to do with the choice = that faces us. If you want to make the case for rpz being a bad thing, = the argument you should be making would have to show why protecting = people in this way is the wrong solution to the problem, and why some = other solution to the problem (e.g., a blacklist in the browser) is less = bad. >=20 > Can=E2=80=99t we have that conversation, instead of these repeated = assertions about things over which we have no control? +1 From nobody Tue Jan 3 22:27: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 62774129B92 for ; Tue, 3 Jan 2017 22:27:42 -0800 (PST) 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=virtualized-org.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 E5IXHz52SjkX for ; Tue, 3 Jan 2017 22:27:41 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 F11BB129483 for ; Tue, 3 Jan 2017 22:27:40 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id i5so158848930pgh.2 for ; Tue, 03 Jan 2017 22:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=tpWtCpIWQbbLuUmEj5+/M41giVUPrFxYZSDQ4bgWxX0=; b=twcMef0fxtRsyYQhOnOyWdz0/TdDId5kiLOQikcAdAoKokEUx/FTFvZjZZFbBXYDmF /6uaPE7IlSKcsfqvHA8iCIxXa2Xh3onwCIRVGoYKrWGP1UIgCzv0Hq6ukdtbWL+//BxF i0zLjLdFW0UPUGGL4Q1HB2Xw0optMKa83ejKqTfBj6+seYvFxKOj0lQ6+0dQALfyxVvi plGPYoU7BR8AJCyHECEr1iz8vipMc5owpqvRFumnOyqV05EEmzpwC1PH3xqput+R50Aj UIKVyG2DR1tEWBrAF+2WTY1AHW3TX4Uj2YjsBWJ0uCDcNSeGaRsQaYWqHG5PfZzcEcvg msJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=tpWtCpIWQbbLuUmEj5+/M41giVUPrFxYZSDQ4bgWxX0=; b=d1bs+RA/K1Dkvugi1eT1cjUQBZtZHHafDKIdN81PUXjmNsaSW6K0j/8rrNge8KT7FL 00Mx7ljkEwxMkjy5C/0F0rlJfoASrhzqTZ844PkTwM7Ygdxmt8Y5sC78aM/9qW8qloEu g9BbukhyD6MtL6o1L2Bbza/+umeADQPfX6y2kf/2F/uZs7NQQ7ojG/R3GIsveNS+0g0E mb8gBUc6MsE+K3+FBdC8hAaLYXlTR7nq4D412X7o3Ba3gSdwMG8PC8MM27yh15/iVh6O lJ5YxYq17WQrNMPzN9VKLuhUYK+EytnqV9DDMOlzgZIR7i7givb9uU2n1vyiYnBpR/5k qNYA== X-Gm-Message-State: AIkVDXJYxQ1jOktlHO0qAcaYjuiuojrU8BDRE04AniAJWjsYE53KzVCdo+7LKZVUxs8iJg== X-Received: by 10.98.131.67 with SMTP id h64mr60442290pfe.86.1483511260124; Tue, 03 Jan 2017 22:27:40 -0800 (PST) Received: from [192.168.7.24] (c-24-6-172-77.hsd1.ca.comcast.net. [24.6.172.77]) by smtp.gmail.com with ESMTPSA id t21sm144030340pfa.1.2017.01.03.22.27.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 22:27:39 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EEB92179-AEE0-4D8A-949B-C1428BEBA922"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: David Conrad In-Reply-To: <20161221055007.4BFD212951C@ietfa.amsl.com> Date: Tue, 3 Jan 2017 22:27:37 -0800 Message-Id: <60F9D7F6-5005-484D-94DA-3534BDA040B1@virtualized.org> References: <20161221000237.24158.qmail@ary.lan> <20161221055007.4BFD212951C@ietfa.amsl.com> To: ac X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 06:27:42 -0000 --Apple-Mail=_EEB92179-AEE0-4D8A-949B-C1428BEBA922 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andre, On Dec 20, 2016, at 9:49 PM, ac wrote: > I once made a very cool tool, it improved the life of many people as = it > allowed anyone to take over any pc running a certain operating system > with the sole and great purpose of helping more users. It too was > published, improved, altered and distributed widely >=20 > RPZ is like that. No, it's not. There is a rather striking difference between a tool I choose to deploy = on my network that helps protects my users from external threats and a = tool that allows an external entity to intrude on my users. If you do = not understand this, there is a bigger problem to address. > RPZ will be legitimized by this draft, it will be used and living = human > beings may actually die because of server software. RPZ is legitimized by its use, not by the documentation describing that = use. Proverbially sticking your head in the sand does not remove the = carnivores that are eyeing the rest of your body. > And, this is my final word on this, I apologize if anyone feels that I > have wasted their time or offended them in any way. This was never my > intention. It would appear your intention is to school the ignorant masses in the = errors of their ways. Personally, I'm always a bit nervous when someone = decides they know what's best for me or the folks I might provide = services for. Regards, -drc (speaking only for myself) --Apple-Mail=_EEB92179-AEE0-4D8A-949B-C1428BEBA922 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYbJXZAAoJENV6ebf0/4rXDlYH/3muFWxMLr0eWlTvH15mNT9+ hZ1sstWyRK2xUN2yzhUpmVlgPGqgFITMGnDuLTj4n1hKbV5zJcGi0tlMzsECI1yx gqJq+79W1SL1j9bYnT8k7nsXVqZ1Y/AxGeUo1O+TZQpFXsJfvTZx7UAukfAjBhIt nCsa1X9iQjxhMsEa+3EKKHUNftkbMAvVjop84HsQYUChapV+1xJYdzz9u+aitLJV gr91oxyD+A2F9tmAJnF+xOt6mRaCFmLNL4Wq+4yJQtYzeKZ6bhfBedk4cR5E+/CO 5ayWf4lmOjLld/cq/Jbf5BMdSfGTa1HUbB12dq95LfquEQ418JK3CY8AFOtUgXU= =iTRV -----END PGP SIGNATURE----- --Apple-Mail=_EEB92179-AEE0-4D8A-949B-C1428BEBA922-- From nobody Wed Jan 4 09:13:12 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 B940A1299EF for ; Wed, 4 Jan 2017 09:13:10 -0800 (PST) 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] 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 GFsjdncKsp5m for ; Wed, 4 Jan 2017 09:13:09 -0800 (PST) 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 589971299F1 for ; Wed, 4 Jan 2017 09:13:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 286F031D57; Wed, 4 Jan 2017 18:13:07 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 5A74B1906AA; Wed, 4 Jan 2017 18:11:12 +0100 (CET) Date: Wed, 4 Jan 2017 18:11:12 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170104171112.GA1967@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:13:11 -0000 On Fri, Nov 25, 2016 at 07:50:48PM -0500, tjw ietf wrote a message of 114 lines which said: > This starts a Working Group Last Call for > draft-ietf-dnsop-refuse-any Since we'll apparently have one more iteration of the draft, one small detail. The draft says: > The HINFO RRTYPE is believed to be rarely used in the DNS at the > time of writing, based on observations made both at recursive > servers and authority servers. If you have access to a passive DNS database, you can check by yourself. Indeed, the vast majority of HINFO comes from Cloudflare domains. In .fr (3 million domains), DNSDB found only 54 non-Cloudflare HINFO. My favorites are (a former employer): iiel.iie.cnam.fr. IN HINFO "VS3100" "VMS-6.2" wotan.iie.cnam.fr. IN HINFO "AlphaServer-1000" "OSF" I strongly doubt there is really a VaxStation 3100 still in operation :-) From nobody Wed Jan 4 09:33: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 CD05512969A for ; Wed, 4 Jan 2017 09:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 oXbP5Yxj_JSa for ; Wed, 4 Jan 2017 09:33:08 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115E612969D for ; Wed, 4 Jan 2017 09:33:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id F318B2C405A for ; Wed, 4 Jan 2017 09:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4AGX43o3kKDi; Wed, 4 Jan 2017 09:33:04 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8A3DE2C4029; Wed, 4 Jan 2017 09:33:04 -0800 (PST) From: Nicholas Weaver Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Wed, 4 Jan 2017 09:33:04 -0800 To: dnsop X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Nicholas Weaver Subject: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:33:10 -0000 Any system which prevents zone enumeration requires online signing, = https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html But NSEC5 is almost certainly not going to be adopted, simply because of = the partial deployment problem. NSEC3 lies work today, but people worry that NSEC3 might have server = compromise compromise the ZSK. So why not simply add a new DNSKEY record flag: NSEC3-only. This flag = means that the key in question can only be used to sign an NSEC* record = when presenting NXDOMAIN. This way, you can deploy this solution today using white lies, and as = resolvers are updated, this reduces the potential negative consequence = of a key compromise to =E2=80=9Cattacker can only fake an NXDOMAIN=E2=80=9D= , allowing everything else to still use offline signatures. Combine with caching of the white lies to resist DOS attacks and you = have a workable solution that prevents zone enumeration that is = deployable today and has improved security (key can only fake NXDOMAIN) = tomorrow. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc From nobody Wed Jan 4 10:24: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 56E931296BF for ; Wed, 4 Jan 2017 10:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OvreXftTZb6A for ; Wed, 4 Jan 2017 10:24:23 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFD4129A10 for ; Wed, 4 Jan 2017 10:24:23 -0800 (PST) Received: from jurassic (unknown [115.118.146.77]) (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 6867D2FA00D5; Wed, 4 Jan 2017 18:24:20 +0000 (GMT) Date: Wed, 4 Jan 2017 23:54:16 +0530 From: Mukund Sivaraman To: Nicholas Weaver Message-ID: <20170104182415.GA29444@jurassic> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:24:24 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Nicholas On Wed, Jan 04, 2017 at 09:33:04AM -0800, Nicholas Weaver wrote: > This way, you can deploy this solution today using white lies, and as > resolvers are updated, this reduces the potential negative consequence > of a key compromise to =E2=80=9Cattacker can only fake an NXDOMAIN=E2=80= =9D, allowing > everything else to still use offline signatures. >=20 > Combine with caching of the white lies to resist DOS attacks and you > have a workable solution that prevents zone enumeration that is > deployable today and has improved security (key can only fake > NXDOMAIN) tomorrow. Assume an attacker is able to spoof answers, which is where DNSSEC validation helps. If a ZSK is leaked, it becomes a problem only when an attacker is able to spoof answers (i.e., perform the attack). What you're saying is that with a special NSEC3-only DNSKEY compromise, "attacker can only fake an NXDOMAIN". If an attacker can fake NXDOMAINs and get the resolver to accept them, that's as bad. The attacker can deny all answers in the zone by presenting valid negative answers. This is why we have proof of non-existence that needs to be securely validated. A special NSEC3-only-DNSKEY's compromise isn't a better situation than a ZSK compromise. Mukund --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYbT3PAAoJEB9EXrAiC5LsDewP/0mITb5QVvDj16L/0opSziMJ ksxX0OWcWlxxOMvnnt/FRSl/28UDMY0rzacI7XD5uIU3eaaRQ3BjcRkGRFA9drTH LFYDW+MabmJJgmYKJ7AzDekyhE3jcJcquy5I3REzuHSLwcU5Q5uKEOANdm/q3OAP x5MtKRBOUWOut9zs0Bv9+HMqSUfSM8jIBCr/QvnabkXfTEpEI3atgHvj50Z6BlS4 cB6UHkKkzxnumf51BUclpD4yR5xg1D61Da1eBFGHsdCa5jTSy/+NEMs96S8lvEQC XDKzmiIavRKI6hLByqxjWNlvVf4LTdn0KEwXthKzr9vdIA9ySWGYW20GARuZUP23 8PxGnAjJ8Bx17QP+9Y+WYK/PJwEJwPhkihpj5wGd9Xtoam1ptO6fMPu62Oes7wEc R9Ac1nZucqQhuz6gQksL3ScYKYRNiuq74bUk64r2XiyxGkCKse4ZXO3wdHflPIfN tfIQb16Mph1pn3CNFWPfo03steKJEnQ+F5L1pHefQvVAweM65bu4aCcyMDZqoUER 76OkB7ILqEEdA1dsBXQjnRchECNNU87GA7ovOZwuDuxTE+05NTNySButfJrtzLQ7 taJfDnEKS8Pz7jQV8MUOnp9QG1C4Rfvhmw6y0toWQ4XYuwkcjfSpLYPNsn7BJcYB cvK57jIS0ncwlj3lBdkX =LBox -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From nobody Wed Jan 4 10:28:15 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 EEEA21296C1 for ; Wed, 4 Jan 2017 10:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 sb7hVt7jrFjD for ; Wed, 4 Jan 2017 10:28:12 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61521126D74 for ; Wed, 4 Jan 2017 10:28:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 527E82C405C; Wed, 4 Jan 2017 10:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KpOJzqzPNAPA; Wed, 4 Jan 2017 10:28:11 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DF7E72C4059; Wed, 4 Jan 2017 10:28:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Nicholas Weaver In-Reply-To: <20170104182415.GA29444@jurassic> Date: Wed, 4 Jan 2017 10:28:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170104182415.GA29444@jurassic> To: Mukund Sivaraman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop , Nicholas Weaver Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:28:14 -0000 > On Jan 4, 2017, at 10:24 AM, Mukund Sivaraman wrote: >=20 > Hi Nicholas >=20 > On Wed, Jan 04, 2017 at 09:33:04AM -0800, Nicholas Weaver wrote: >> This way, you can deploy this solution today using white lies, and as >> resolvers are updated, this reduces the potential negative = consequence >> of a key compromise to =E2=80=9Cattacker can only fake an = NXDOMAIN=E2=80=9D, allowing >> everything else to still use offline signatures. >>=20 >> Combine with caching of the white lies to resist DOS attacks and you >> have a workable solution that prevents zone enumeration that is >> deployable today and has improved security (key can only fake >> NXDOMAIN) tomorrow. >=20 > Assume an attacker is able to spoof answers, which is where DNSSEC > validation helps. If a ZSK is leaked, it becomes a problem only when = an > attacker is able to spoof answers (i.e., perform the attack). >=20 > What you're saying is that with a special NSEC3-only DNSKEY = compromise, > "attacker can only fake an NXDOMAIN". If an attacker can fake = NXDOMAINs > and get the resolver to accept them, that's as bad. The attacker can > deny all answers in the zone by presenting valid negative answers. = This > is why we have proof of non-existence that needs to be securely > validated. A special NSEC3-only-DNSKEY's compromise isn't a better > situation than a ZSK compromise. An attacker in that position can just put in garbage, and you get = SERVFAIL instead of NXDOMAIN, regardless of whether the attacker has = compromised the key or not. This is partially why the provable denial is somewhat silly as I can = have the same effect as a denial of service using other mechanisms that = the cryptography doesn=E2=80=99t stop. So having a key that can only be used for provable denial compromised by = an attacker is, yeah, not great, but not some horrid catastrophe.=20 -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc From nobody Wed Jan 4 10:36: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 8C113129A1F for ; Wed, 4 Jan 2017 10:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aBgXlDihg2wK for ; Wed, 4 Jan 2017 10:35:57 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9D75C129A1D for ; Wed, 4 Jan 2017 10:35:57 -0800 (PST) Received: from jurassic (unknown [115.118.146.77]) (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 E286F2FA00D5; Wed, 4 Jan 2017 18:35:55 +0000 (GMT) Date: Thu, 5 Jan 2017 00:05:52 +0530 From: Mukund Sivaraman To: Nicholas Weaver Message-ID: <20170104183552.GA29672@jurassic> References: <20170104182415.GA29444@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:35:58 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Nicholas On Wed, Jan 04, 2017 at 10:28:11AM -0800, Nicholas Weaver wrote: >=20 > > On Jan 4, 2017, at 10:24 AM, Mukund Sivaraman wrote: > >=20 > > Hi Nicholas > >=20 > > On Wed, Jan 04, 2017 at 09:33:04AM -0800, Nicholas Weaver wrote: > >> This way, you can deploy this solution today using white lies, and as > >> resolvers are updated, this reduces the potential negative consequence > >> of a key compromise to =E2=80=9Cattacker can only fake an NXDOMAIN=E2= =80=9D, allowing > >> everything else to still use offline signatures. > >>=20 > >> Combine with caching of the white lies to resist DOS attacks and you > >> have a workable solution that prevents zone enumeration that is > >> deployable today and has improved security (key can only fake > >> NXDOMAIN) tomorrow. > >=20 > > Assume an attacker is able to spoof answers, which is where DNSSEC > > validation helps. If a ZSK is leaked, it becomes a problem only when an > > attacker is able to spoof answers (i.e., perform the attack). > >=20 > > What you're saying is that with a special NSEC3-only DNSKEY compromise, > > "attacker can only fake an NXDOMAIN". If an attacker can fake NXDOMAINs > > and get the resolver to accept them, that's as bad. The attacker can > > deny all answers in the zone by presenting valid negative answers. This > > is why we have proof of non-existence that needs to be securely > > validated. A special NSEC3-only-DNSKEY's compromise isn't a better > > situation than a ZSK compromise. >=20 > An attacker in that position can just put in garbage, and you get > SERVFAIL instead of NXDOMAIN, regardless of whether the attacker has > compromised the key or not. >=20 > This is partially why the provable denial is somewhat silly as I can > have the same effect as a denial of service using other mechanisms > that the cryptography doesn=E2=80=99t stop. An on-path attacker capable of filtering packets is a different scenario. In this case, nothing can help, not even a secure DNSKEY. When there's no connectivity, there's no communication. Off-path attacks are now rarer with source-port randomization and the introduction of cookies (but we regularly see evidence of attempts to poison caches). DNSSEC allows end-to-end validation, where responses do get through and could be fudged on the way. > So having a key that can only be used for provable denial compromised > by an attacker is, yeah, not great, but not some horrid catastrophe. Mukund --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYbUCHAAoJEB9EXrAiC5Ls8XYP/00pqPw+Tkc4S7eBpshqX2sw 0gR/vbPjrHwHjhgBGmOjeo0TkypLpneNKNjGyd2C07VCgz/x2oLA097yDJOc4IcE VnCYnhFMvvVz2ejCyAozyJrS4RL9oQA021mLQDj0g4e9aVSViHjmV1WVWYuysCvf lLAOogZq93VOAGCKeV7ee+6FjgM+eMPt7q2PgkYZnDOaBkMhY8XRdOfgj7odaBDx G0ldF2RTue2yd0nvuxMYd2hjSYKuwlRIJ6Vw7+eqZL9WiS7lVRuf/8lbU6yjgYAi jo8EL9sTiQnTm0jTkkGrzAhrKsTlhw7fZkhjRO8Q/DTULIPv54zvAdaxXCVT/OZ3 8jndUZYEiz7gFVHgPdc+2dbzGWpZabZKfsbI3mJM8BglUFuuQLsMrx+Z2G7S0yPf epw0x/bVCwDGmE9JRqN2aj7TIXdN/sHrDRwAf5QHcdfpD8YmuND6UrYSmqF1z5SK 1P5ezSkd4paI1Cj/xS4tFGHHKofZ6ppIEmEdocpGtV7NvqvwFqP3wjN0SVCcHOyC GUA9zbynFWMB555DMG/Vyso/ZNzStNSGMsAq1y7Yo+f0dxSU//saRCvLPp/ZO7OM +Vt4MJYUXi6YXRP1jRzX7+D1G2c6Auofq7Nxe8jUp2eg/U7uBUTQGp2GWHVjTUEw 3rkxV02x6rQI4yyutDp0 =ovs6 -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From nobody Wed Jan 4 10:45: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 57260129A19 for ; Wed, 4 Jan 2017 10:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aM5SFjcpmbMU for ; Wed, 4 Jan 2017 10:45:57 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7EB1296A5 for ; Wed, 4 Jan 2017 10:45:57 -0800 (PST) Received: from jurassic (unknown [115.118.146.77]) (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 730212FA00D5; Wed, 4 Jan 2017 18:45:55 +0000 (GMT) Date: Thu, 5 Jan 2017 00:15:52 +0530 From: Mukund Sivaraman To: Nicholas Weaver Message-ID: <20170104184552.GA31138@jurassic> References: <20170104182415.GA29444@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:45:58 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 04, 2017 at 10:28:11AM -0800, Nicholas Weaver wrote: > An attacker in that position can just put in garbage, and you get > SERVFAIL instead of NXDOMAIN, regardless of whether the attacker has > compromised the key or not. A SERVFAIL is an erroneous condtion. An NXDOMAIN is not - it is business as usual. SERVFAILs are sometimes cached very temporarily to reduce load on upstream servers, but they are not answers. NXDOMAINs are cached as *answers* from the remote auth server. On-path disruption is impossible to defeat. An on-path attacker who wants to poison answers without raising suspicions (logged validation failures) will want validation to succeed. Mukund --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYbULfAAoJEB9EXrAiC5Lsg4YQAJFrybwUVQyhinSRUdy7JPLH r4DLY9i46uNquvhAx2rWsqJOGSiQqhZlO+b2j4ms/wA41I8MZBatufRSi11Sw9fU MyB8Q/DvFbGmTEUfY/y8mUwufKo8ERsx4VOG8wsT4h7r8Hick5MYKal3KT93GMl8 fA6cvnKsiAWEX+DsyxbVZ6n8UDbydswZhHM8FSDdTXl4e7Q6UJPokJdHuLBzlxtl O3bkANBSqIT2dVsFAd37A6Sdv0nyU2oyy3+R5S0trwmRPSG4WzWgwXQ2rs62BTxF 9WsiNcIw2tx50ITjz97vI+mizyqfVIkK9OBhzJUS1RMTqBcIRQQqyRUkfyvA5/EP bCxyaeGVAYR2Kyyll8/5XJ052KuD9AVKrxCoXvs9k07iUZIZJwPvdMyQ5b+qi/g8 8lBKLId5g30oDle9jV5DwLBAI+iO0RsBF9uZ68Lvjagy9q5PvhipeRkNDywPFrG8 B2xosfBuktE+cTnSmkbABHSU6xtuUJ9pH7IX1anBaz3WVhyIhcQSy5V6WwjpbZGq hb2cOVn7f/MiqvfGYpILLxvrg13WAgUP2aDwSfSwRmcheXwVadqYN+11oE2nFaKA k663XrazClP7K6dLyVBrpXf3bDW1DR0N9b+tFju3kCT7in6xciiOKOKdWx0hSaQw Pi03Y8PrKY2X7xcLAEcD =7Jh7 -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From nobody Thu Jan 5 05:13:26 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 18ECB129450 for ; Thu, 5 Jan 2017 05:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 7BhVvpyjIMTd for ; Thu, 5 Jan 2017 05:13:23 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DBC129437 for ; Thu, 5 Jan 2017 05:13:22 -0800 (PST) Received: from [192.168.8.180] (wall-a.vs.uni-due.de [134.91.78.130]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id v05DDJ3n029258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 14:13:20 +0100 To: Mukund Sivaraman References: <20170104182415.GA29444@jurassic> From: =?UTF-8?Q?Matth=c3=a4us_Wander?= Organization: =?UTF-8?Q?Universit=c3=a4t_Duisburg-Essen?= Message-ID: <7decac93-6437-40a5-3c71-f33e18cbb43c@uni-due.de> Date: Thu, 5 Jan 2017 14:13:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170104182415.GA29444@jurassic> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020400010405060306060302" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:13:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020400010405060306060302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable * Mukund Sivaraman [2017-01-04 19:24]: > Assume an attacker is able to spoof answers, which is where DNSSEC > validation helps. If a ZSK is leaked, it becomes a problem only when an= > attacker is able to spoof answers (i.e., perform the attack). >=20 > What you're saying is that with a special NSEC3-only DNSKEY compromise,= > "attacker can only fake an NXDOMAIN". If an attacker can fake NXDOMAINs= > and get the resolver to accept them, that's as bad. The attacker can > deny all answers in the zone by presenting valid negative answers. This= > is why we have proof of non-existence that needs to be securely > validated. A special NSEC3-only-DNSKEY's compromise isn't a better > situation than a ZSK compromise. You're right if you're only considering denial of service. If you take phishing or email hijacking into account, an NSEC3-only compromise is a better situation than a ZSK compromise (or at least a different attack class, whether or not better). With DANE, however, it's not just denial of service anymore: NXDOMAIN spoofing cancels the protection provided by DANE. So we have the cost of a protocol change vs. the benefit of protecting from bogus records (but not from DoS or DANE downgrade)... Regards, Matt --------------ms020400010405060306060302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EKowggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBa4wggSWoAMCAQICBxekJLcH4EswDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MjcxNDU0MzFaFw0xOTA3MDkyMzU5MDBa MIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0 ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkq hkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAq5XrJk5ojJCsz7hyCQ1KcaY4gpDy9fH6KQvQrnuJ9cUQcT50 hLLCP9lwG+JB1qyZpT43dtvNT9h5iEJGo/pjzsNMRpM2Gp/6ykW/IL8G+L/3CYQu0yIqD00O zX73zIOYaDWFu5nMpABGNHhZTvNHSxzSyzFEJvFUcTw0vbA5R4CFGnZjNWDZICdzwdH9A6ke 1oi6MoIC3b8SGQ5Ap3BaZIW67311NJEFVHI/JDDRuReRIDVGv9ZE6anzlPt4wIpGDD5T4X1u Dbym0qZvKeQW0RyUJbXttKU3lhRgGrb+kYztdHlh6D/PJUvaojph/pJP3Kqj9rcz6OGhOtgY houDiQIDAQABo4ICCjCCAgYwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYw EQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBRmZryWm0hN6N28IqemW9WoQZ+V7jAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAoBgNVHREEITAfgR1jYWFkbWluQHVuaS1k dWlzYnVyZy1lc3Nlbi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5k Zm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsG AQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1At U2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw Mi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEAJjyWphFD/Nq+YmFq+yvRvPu2yCPO/LAXfUUMyWFc/EgfvSuUuNnz K49FHY8eFo0i60wVvKs52yfRsdOhAZjga5gnOlx5lx97Ovifn0O8WUsPukaGTWjF6J2KEE6N 62tg6K1zU6MHktel6FaLCmW6XmCWA9PbYkURzYylYPgQyx4fT7H57I9IXQQhZNu8F8OKosM3 MWFsE1QhLgqV3VC8zKxVBWgS5Bblw2t4Gp7tCWpCC6NAibSzvihD5TpD3ZTcecC329+CSVkY 34OlS6LtuFXXxJCETi4XzyZeLnxE0FGNvnb02QEZURNR6S4lmcRxB685FClXNU96enn9Lu3K JTCCBhswggUDoAMCAQICBxmU245GdXUwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYTAkRF MSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4xNTAzBgNVBAsTLFplbnRy dW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5kaWVuc3RlMSwwKgYDVQQDEyNVbml2 ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEsMCoGCSqGSIb3DQEJARYdY2FhZG1p bkB1bmktZHVpc2J1cmctZXNzZW4uZGUwHhcNMTUwNjA4MDkxODU0WhcNMTgwNjA3MDkxODU0 WjBqMQswCQYDVQQGEwJERTEkMCIGA1UECgwbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MRowGAYDVQQLDBFWZXJ0ZWlsdGUgU3lzdGVtZTEZMBcGA1UEAwwQTWF0dGhhZXVzIFdhbmRl cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKuZL9zfm3+ltyC1RoY6p4gwKVcW tz5gJ5rYGBN/15R4V8gsbxr7fA6Depc9K5FQm2bFWHxPWCo8clQ7jwWxTp8S3sCzyqbGNZbC e4PhaGOYOBVoGKT2rU1es168AHtgYXrEXw/3ias4ZknAwCQdo419uuvfvZR7EZJ56tc6u42V IstJ8DeT1DO6DIXw7hGvUFiq6QlCdhI/Mz0xv9SSsx2jEqqSikr7745qGXRvQv6D9wM9APTE /AIT260MuMjFktvIyfUjHrCO7GtLbvz6saW/Tnf0qRN/tAd8MSgpDv861NC1b0eYpHeT5ouQ 2awgssXSSV1d/C1UI1ZS2CuZZ4UCAwEAAaOCAmcwggJjMEAGA1UdIAQ5MDcwEQYPKwYBBAGB rSGCLAEBBAMDMBEGDysGAQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQC MAAwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4E FgQUsuTmt3sT/g9SedrlhdVg7DRYQuAwHwYDVR0jBBgwFoAUZma8lptITejdvCKnplvVqEGf le4wJgYDVR0RBB8wHYEbbWF0dGhhZXVzLndhbmRlckB1bmktZHVlLmRlMIGXBgNVHR8EgY8w gYwwRKBCoECGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWR1aXNidXJnLWVzc2VuLWNh L3B1Yi9jcmwvY2FjcmwuY3JsMESgQqBAhj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1k dWlzYnVyZy1lc3Nlbi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB5QYIKwYBBQUHAQEEgdgwgdUw MwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBO BggrBgEFBQcwAoZCaHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktZHVpc2J1cmctZXNzZW4t Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0ME4GCCsGAQUFBzAChkJodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nlbi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJ KoZIhvcNAQELBQADggEBAGmHuL7MZ71iI9bFasDBqkFE1ngRPUEbh1rDRAw3xYIv2ZJ6ReV2 taXKXQn9g0uhPsHJ6HZTgE/AjN07EynrPR8Lk9Hyg2tIvAxTTlGMLxTCp+baJfNAp92adwWp cdsRiCTgOCmoNwONPwCcnnf79bVT3Ncpm4A3E+qWjpp0JKE8zr1VzyKlUKBAZlY9c80myOyX i+o3fdDIFhS7XawPM6TlGiC+ZWwCkB3m2ZatKDqjtmC8xhMivoo1muWVNS+RzTphxJQKiTaR h9pfPqDt7LA/Hry2YXH7305UnUwLJoFGCaLBLDXgOEthz5OUvjIx2QMeOzv3LOnrQ6UOqU3j 0WQxggSnMIIEowIBATCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFl dCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0g dW5kIE1lZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3Nl biBDQSAtRzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5k ZQIHGZTbjkZ1dTANBglghkgBZQMEAgEFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwMTA1MTMxMzEyWjAvBgkqhkiG9w0BCQQxIgQgwefU93HP 1/B7JUuyELiQ7X6cgDZ2mjEwC6kGUO6+wa8wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQsw CQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuMTUwMwYD VQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoG A1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkqhkiG9w0B CQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlAgcZlNuORnV1MIHlBgsqhkiG9w0B CRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlz YnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1l ZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAt RzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZQIHGZTb jkZ1dTANBgkqhkiG9w0BAQEFAASCAQAmNSJMvnJBVA8Imt5q5D9KN6Z6VVHJxR88NSj2mZxD gPEUXStuU38YBF4L+ys9M+1UwfghVXFEEDO+uLV6rl48qDIy5CzuH8bcXIV/g5w69DvxRg6t jWRbL1cJiyxV74BN6N3u/qhoF7mTMKi0ETCfCghhXU9q/2G+4S7x0IgxYgW+S6+4/rnAA9lu EMiotvbGJDS5LlQe9uJO7JZhACEdeNJeO5wep1j7LcOSwm11c8todz1V4Uw1R7mfh2jGcppo nXpRQ+lgAVxAkU/ByEBrPYVbrRqeY1EJlCD04/lC+giEm3uETL+4Cc31tCu5nk77sAL+Bz98 +D1nI7n1bUgXAAAAAAAA --------------ms020400010405060306060302-- From nobody Thu Jan 5 09:05:58 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 DB43812959D for ; Thu, 5 Jan 2017 09:05:56 -0800 (PST) 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] 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 J9vxeMYi2ExA for ; Thu, 5 Jan 2017 09:05:55 -0800 (PST) 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 3EF5212959C for ; Thu, 5 Jan 2017 09:05:55 -0800 (PST) Received: from [10.32.60.118] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v05H5507048595 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jan 2017 10:05:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.118] From: "Paul Hoffman" To: "Nicholas Weaver" Date: Thu, 05 Jan 2017 09:05:52 -0800 Message-ID: <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 17:05:57 -0000 On 4 Jan 2017, at 9:33, Nicholas Weaver wrote: > Any system which prevents zone enumeration requires online signing, > https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html That statement isn't really supported by the text on the page. Depending on the zone, using pre-signed NSEC3 prevents varying amounts of enumeration, depending on what's in the attacker's dictionary and what's in the zone. > But NSEC5 is almost certainly not going to be adopted, simply because > of the partial deployment problem. Yes. > NSEC3 lies work today, but people worry that NSEC3 might have server > compromise compromise the ZSK. NSEC3 lies can also be created with pre-computing, but at a cost of greatly increasing the size of the zone. > So why not simply add a new DNSKEY record flag: NSEC3-only. This flag > means that the key in question can only be used to sign an NSEC* > record when presenting NXDOMAIN. This could be done if there are enough people who care about zone enumeration against the current NSEC3 capabilities. Are there such people? Have we heard what their problem statements are and what they have tried with pre-computed NSEC3 lies? --Paul Hoffman From nobody Thu Jan 5 11:27: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 7611C129630 for ; Thu, 5 Jan 2017 11:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 3-KA1hXE6cv6 for ; Thu, 5 Jan 2017 11:27:30 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FEB12961F for ; Thu, 5 Jan 2017 11:27:30 -0800 (PST) Received: from [192.168.8.180] (wall-a.vs.uni-duisburg-essen.de [134.91.78.130]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id v05JRR5B011516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 20:27:27 +0100 To: Paul Hoffman References: <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org> From: =?UTF-8?Q?Matth=c3=a4us_Wander?= Organization: =?UTF-8?Q?Universit=c3=a4t_Duisburg-Essen?= Message-ID: Date: Thu, 5 Jan 2017 20:27:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030206030203070103070901" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:27:32 -0000 This is a cryptographically signed message in MIME format. --------------ms030206030203070103070901 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable * Paul Hoffman [2017-01-05 18:05]: >> NSEC3 lies work today, but people worry that NSEC3 might have server >> compromise compromise the ZSK. >=20 > NSEC3 lies can also be created with pre-computing, but at a cost of > greatly increasing the size of the zone. NSEC/NSEC3 lies prevent enumeration effectively when they're minimally covering because it's infeasible to ever collect such a chain. A pre-computed chain does not provide the same benefit. It increases the enumeration cost in terms of network queries (CPU time is of less importance here because the collection process is network-bound except for the very last few NSEC3 records). Enumeration remains feasible with pre-computed chains unless you re-salt and re-sign the zone in an interval, which is shorter than the duration needed to send one query for each NSEC3 record in a zone. Regards, Matt --------------ms030206030203070103070901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EKowggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBa4wggSWoAMCAQICBxekJLcH4EswDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MjcxNDU0MzFaFw0xOTA3MDkyMzU5MDBa MIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0 ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkq hkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAq5XrJk5ojJCsz7hyCQ1KcaY4gpDy9fH6KQvQrnuJ9cUQcT50 hLLCP9lwG+JB1qyZpT43dtvNT9h5iEJGo/pjzsNMRpM2Gp/6ykW/IL8G+L/3CYQu0yIqD00O zX73zIOYaDWFu5nMpABGNHhZTvNHSxzSyzFEJvFUcTw0vbA5R4CFGnZjNWDZICdzwdH9A6ke 1oi6MoIC3b8SGQ5Ap3BaZIW67311NJEFVHI/JDDRuReRIDVGv9ZE6anzlPt4wIpGDD5T4X1u Dbym0qZvKeQW0RyUJbXttKU3lhRgGrb+kYztdHlh6D/PJUvaojph/pJP3Kqj9rcz6OGhOtgY houDiQIDAQABo4ICCjCCAgYwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYw EQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBRmZryWm0hN6N28IqemW9WoQZ+V7jAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAoBgNVHREEITAfgR1jYWFkbWluQHVuaS1k dWlzYnVyZy1lc3Nlbi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5k Zm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsG AQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1At U2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw Mi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEAJjyWphFD/Nq+YmFq+yvRvPu2yCPO/LAXfUUMyWFc/EgfvSuUuNnz K49FHY8eFo0i60wVvKs52yfRsdOhAZjga5gnOlx5lx97Ovifn0O8WUsPukaGTWjF6J2KEE6N 62tg6K1zU6MHktel6FaLCmW6XmCWA9PbYkURzYylYPgQyx4fT7H57I9IXQQhZNu8F8OKosM3 MWFsE1QhLgqV3VC8zKxVBWgS5Bblw2t4Gp7tCWpCC6NAibSzvihD5TpD3ZTcecC329+CSVkY 34OlS6LtuFXXxJCETi4XzyZeLnxE0FGNvnb02QEZURNR6S4lmcRxB685FClXNU96enn9Lu3K JTCCBhswggUDoAMCAQICBxmU245GdXUwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYTAkRF MSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4xNTAzBgNVBAsTLFplbnRy dW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5kaWVuc3RlMSwwKgYDVQQDEyNVbml2 ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEsMCoGCSqGSIb3DQEJARYdY2FhZG1p bkB1bmktZHVpc2J1cmctZXNzZW4uZGUwHhcNMTUwNjA4MDkxODU0WhcNMTgwNjA3MDkxODU0 WjBqMQswCQYDVQQGEwJERTEkMCIGA1UECgwbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MRowGAYDVQQLDBFWZXJ0ZWlsdGUgU3lzdGVtZTEZMBcGA1UEAwwQTWF0dGhhZXVzIFdhbmRl cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKuZL9zfm3+ltyC1RoY6p4gwKVcW tz5gJ5rYGBN/15R4V8gsbxr7fA6Depc9K5FQm2bFWHxPWCo8clQ7jwWxTp8S3sCzyqbGNZbC e4PhaGOYOBVoGKT2rU1es168AHtgYXrEXw/3ias4ZknAwCQdo419uuvfvZR7EZJ56tc6u42V IstJ8DeT1DO6DIXw7hGvUFiq6QlCdhI/Mz0xv9SSsx2jEqqSikr7745qGXRvQv6D9wM9APTE /AIT260MuMjFktvIyfUjHrCO7GtLbvz6saW/Tnf0qRN/tAd8MSgpDv861NC1b0eYpHeT5ouQ 2awgssXSSV1d/C1UI1ZS2CuZZ4UCAwEAAaOCAmcwggJjMEAGA1UdIAQ5MDcwEQYPKwYBBAGB rSGCLAEBBAMDMBEGDysGAQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQC MAAwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4E FgQUsuTmt3sT/g9SedrlhdVg7DRYQuAwHwYDVR0jBBgwFoAUZma8lptITejdvCKnplvVqEGf le4wJgYDVR0RBB8wHYEbbWF0dGhhZXVzLndhbmRlckB1bmktZHVlLmRlMIGXBgNVHR8EgY8w gYwwRKBCoECGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWR1aXNidXJnLWVzc2VuLWNh L3B1Yi9jcmwvY2FjcmwuY3JsMESgQqBAhj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1k dWlzYnVyZy1lc3Nlbi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB5QYIKwYBBQUHAQEEgdgwgdUw MwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBO BggrBgEFBQcwAoZCaHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktZHVpc2J1cmctZXNzZW4t Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0ME4GCCsGAQUFBzAChkJodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nlbi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJ KoZIhvcNAQELBQADggEBAGmHuL7MZ71iI9bFasDBqkFE1ngRPUEbh1rDRAw3xYIv2ZJ6ReV2 taXKXQn9g0uhPsHJ6HZTgE/AjN07EynrPR8Lk9Hyg2tIvAxTTlGMLxTCp+baJfNAp92adwWp cdsRiCTgOCmoNwONPwCcnnf79bVT3Ncpm4A3E+qWjpp0JKE8zr1VzyKlUKBAZlY9c80myOyX i+o3fdDIFhS7XawPM6TlGiC+ZWwCkB3m2ZatKDqjtmC8xhMivoo1muWVNS+RzTphxJQKiTaR h9pfPqDt7LA/Hry2YXH7305UnUwLJoFGCaLBLDXgOEthz5OUvjIx2QMeOzv3LOnrQ6UOqU3j 0WQxggSnMIIEowIBATCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFl dCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0g dW5kIE1lZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3Nl biBDQSAtRzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5k ZQIHGZTbjkZ1dTANBglghkgBZQMEAgEFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwMTA1MTkyNzE5WjAvBgkqhkiG9w0BCQQxIgQgxsAKFLZL X773jgvUQXZGcUlNck4WbTyoW9+GgO5ttQkwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQsw CQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuMTUwMwYD VQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoG A1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkqhkiG9w0B CQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlAgcZlNuORnV1MIHlBgsqhkiG9w0B CRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlz YnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1l ZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAt RzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZQIHGZTb jkZ1dTANBgkqhkiG9w0BAQEFAASCAQBEY/goPVi+9rgF9FL6+FREae1BBHcWEu1+atw95OUB KwTxe3xDLqmBZBQvKXdwtQ/NNY/fkZ+o7QtqoFUH951Xwl2R5bW+SNZSMYnJ4XtrDc/7XKjV ZG63RTxIqglHpY7wbntajtEIyLbSpNH4iLORZyJxorH3s7Sag5aA4qBhNSygKn5LaVQULqHv SmcCUvfR9fBlZsfA+2XEL4l4tiGEqrEpKw62ZdTTTvgrnRz7xCRuo3OuubyMmcs/a7KFZIuN QEJiUHI3NCsbHdophLR4sbUTEZoiMfNx0T+Cws7Ud0+hDl8e1YXedvgcm6p5WMt5fCUO9dTP QRjR3LDIkcChAAAAAAAA --------------ms030206030203070103070901-- From nobody Thu Jan 5 11:44: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 AC200129643 for ; Thu, 5 Jan 2017 11:44:04 -0800 (PST) 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] 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_O74idypejf for ; Thu, 5 Jan 2017 11:44:03 -0800 (PST) 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 9B2C2129404 for ; Thu, 5 Jan 2017 11:44:03 -0800 (PST) Received: from [10.32.60.118] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v05JhET5052739 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jan 2017 12:43:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.118] From: "Paul Hoffman" To: "=?utf-8?q?Matth=C3=A4us?= Wander" Date: Thu, 05 Jan 2017 11:44:01 -0800 Message-ID: In-Reply-To: References: <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:44:04 -0000 On 5 Jan 2017, at 11:27, Matthäus Wander wrote: > * Paul Hoffman [2017-01-05 18:05]: >>> NSEC3 lies work today, but people worry that NSEC3 might have server >>> compromise compromise the ZSK. >> >> NSEC3 lies can also be created with pre-computing, but at a cost of >> greatly increasing the size of the zone. > > NSEC/NSEC3 lies prevent enumeration effectively when they're minimally > covering because it's infeasible to ever collect such a chain. Sure. > A pre-computed chain does not provide the same benefit. It increases > the > enumeration cost in terms of network queries (CPU time is of less > importance here because the collection process is network-bound except > for the very last few NSEC3 records). Enumeration remains feasible > with > pre-computed chains unless you re-salt and re-sign the zone in an > interval, which is shorter than the duration needed to send one query > for each NSEC3 record in a zone. Doesn't that last sentence assume that the attacker has a complete dictionary of possible values in the zone? --Paul Hoffman From nobody Thu Jan 5 12:41: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 9A6131200A0 for ; Thu, 5 Jan 2017 12:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 9tp-qm4ZdKBi for ; Thu, 5 Jan 2017 12:41:11 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C877B1293F9 for ; Thu, 5 Jan 2017 12:41:10 -0800 (PST) Received: from [192.168.178.22] (x4e304a67.dyn.telefonica.de [78.48.74.103]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id v05Kf8uH016774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 21:41:08 +0100 To: Paul Hoffman References: <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org> From: =?UTF-8?Q?Matth=c3=a4us_Wander?= Message-ID: <89926cbc-1eba-1592-4fea-584382807a45@uni-due.de> Date: Thu, 5 Jan 2017 21:41:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050301010508020108080208" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 20:41:12 -0000 This is a cryptographically signed message in MIME format. --------------ms050301010508020108080208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Hoffman wrote on 2017-01-05 20:44: >> A pre-computed chain does not provide the same benefit. It increases t= he >> enumeration cost in terms of network queries (CPU time is of less >> importance here because the collection process is network-bound except= >> for the very last few NSEC3 records). Enumeration remains feasible wit= h >> pre-computed chains unless you re-salt and re-sign the zone in an >> interval, which is shorter than the duration needed to send one query >> for each NSEC3 record in a zone. >=20 > Doesn't that last sentence assume that the attacker has a complete > dictionary of possible values in the zone? To collect an NSEC3 record it suffices to find a random non-existing name, whose hash value cuts the NSEC3 record. This does not require a lot of hashing attempts and a dictionary is not required. By keeping track of which NSEC3 records you have already seen, you only need to send network queries for hash ranges not yet discovered. This gives you the whole NSEC3 chain, though not the cleartext names yet. The cost for recovering cleartext names depends on the iteration count and the number of candidate names you try (i.e. size of dictionary), but not (or maybe little) on the size of the chain. Regards, Matt --------------ms050301010508020108080208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EKowggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBa4wggSWoAMCAQICBxekJLcH4EswDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MjcxNDU0MzFaFw0xOTA3MDkyMzU5MDBa MIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0 ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkq hkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAq5XrJk5ojJCsz7hyCQ1KcaY4gpDy9fH6KQvQrnuJ9cUQcT50 hLLCP9lwG+JB1qyZpT43dtvNT9h5iEJGo/pjzsNMRpM2Gp/6ykW/IL8G+L/3CYQu0yIqD00O zX73zIOYaDWFu5nMpABGNHhZTvNHSxzSyzFEJvFUcTw0vbA5R4CFGnZjNWDZICdzwdH9A6ke 1oi6MoIC3b8SGQ5Ap3BaZIW67311NJEFVHI/JDDRuReRIDVGv9ZE6anzlPt4wIpGDD5T4X1u Dbym0qZvKeQW0RyUJbXttKU3lhRgGrb+kYztdHlh6D/PJUvaojph/pJP3Kqj9rcz6OGhOtgY houDiQIDAQABo4ICCjCCAgYwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYw EQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBRmZryWm0hN6N28IqemW9WoQZ+V7jAfBgNV HSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAoBgNVHREEITAfgR1jYWFkbWluQHVuaS1k dWlzYnVyZy1lc3Nlbi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5k Zm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsG AQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1At U2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw Mi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEAJjyWphFD/Nq+YmFq+yvRvPu2yCPO/LAXfUUMyWFc/EgfvSuUuNnz K49FHY8eFo0i60wVvKs52yfRsdOhAZjga5gnOlx5lx97Ovifn0O8WUsPukaGTWjF6J2KEE6N 62tg6K1zU6MHktel6FaLCmW6XmCWA9PbYkURzYylYPgQyx4fT7H57I9IXQQhZNu8F8OKosM3 MWFsE1QhLgqV3VC8zKxVBWgS5Bblw2t4Gp7tCWpCC6NAibSzvihD5TpD3ZTcecC329+CSVkY 34OlS6LtuFXXxJCETi4XzyZeLnxE0FGNvnb02QEZURNR6S4lmcRxB685FClXNU96enn9Lu3K JTCCBhswggUDoAMCAQICBxmU245GdXUwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNVBAYTAkRF MSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4xNTAzBgNVBAsTLFplbnRy dW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5kaWVuc3RlMSwwKgYDVQQDEyNVbml2 ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEsMCoGCSqGSIb3DQEJARYdY2FhZG1p bkB1bmktZHVpc2J1cmctZXNzZW4uZGUwHhcNMTUwNjA4MDkxODU0WhcNMTgwNjA3MDkxODU0 WjBqMQswCQYDVQQGEwJERTEkMCIGA1UECgwbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2Vu MRowGAYDVQQLDBFWZXJ0ZWlsdGUgU3lzdGVtZTEZMBcGA1UEAwwQTWF0dGhhZXVzIFdhbmRl cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKuZL9zfm3+ltyC1RoY6p4gwKVcW tz5gJ5rYGBN/15R4V8gsbxr7fA6Depc9K5FQm2bFWHxPWCo8clQ7jwWxTp8S3sCzyqbGNZbC e4PhaGOYOBVoGKT2rU1es168AHtgYXrEXw/3ias4ZknAwCQdo419uuvfvZR7EZJ56tc6u42V IstJ8DeT1DO6DIXw7hGvUFiq6QlCdhI/Mz0xv9SSsx2jEqqSikr7745qGXRvQv6D9wM9APTE /AIT260MuMjFktvIyfUjHrCO7GtLbvz6saW/Tnf0qRN/tAd8MSgpDv861NC1b0eYpHeT5ouQ 2awgssXSSV1d/C1UI1ZS2CuZZ4UCAwEAAaOCAmcwggJjMEAGA1UdIAQ5MDcwEQYPKwYBBAGB rSGCLAEBBAMDMBEGDysGAQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQC MAAwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4E FgQUsuTmt3sT/g9SedrlhdVg7DRYQuAwHwYDVR0jBBgwFoAUZma8lptITejdvCKnplvVqEGf le4wJgYDVR0RBB8wHYEbbWF0dGhhZXVzLndhbmRlckB1bmktZHVlLmRlMIGXBgNVHR8EgY8w gYwwRKBCoECGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWR1aXNidXJnLWVzc2VuLWNh L3B1Yi9jcmwvY2FjcmwuY3JsMESgQqBAhj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1k dWlzYnVyZy1lc3Nlbi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB5QYIKwYBBQUHAQEEgdgwgdUw MwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBO BggrBgEFBQcwAoZCaHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktZHVpc2J1cmctZXNzZW4t Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0ME4GCCsGAQUFBzAChkJodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nlbi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJ KoZIhvcNAQELBQADggEBAGmHuL7MZ71iI9bFasDBqkFE1ngRPUEbh1rDRAw3xYIv2ZJ6ReV2 taXKXQn9g0uhPsHJ6HZTgE/AjN07EynrPR8Lk9Hyg2tIvAxTTlGMLxTCp+baJfNAp92adwWp cdsRiCTgOCmoNwONPwCcnnf79bVT3Ncpm4A3E+qWjpp0JKE8zr1VzyKlUKBAZlY9c80myOyX i+o3fdDIFhS7XawPM6TlGiC+ZWwCkB3m2ZatKDqjtmC8xhMivoo1muWVNS+RzTphxJQKiTaR h9pfPqDt7LA/Hry2YXH7305UnUwLJoFGCaLBLDXgOEthz5OUvjIx2QMeOzv3LOnrQ6UOqU3j 0WQxggSnMIIEowIBATCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFl dCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0g dW5kIE1lZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3Nl biBDQSAtRzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5k ZQIHGZTbjkZ1dTANBglghkgBZQMEAgEFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTcwMTA1MjA0MTA2WjAvBgkqhkiG9w0BCQQxIgQgneDaEzqh lr4dply6hYABS3BN0XRaAtr1FZ03ffqNKZgwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQsw CQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuMTUwMwYD VQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoG A1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJnLUVzc2VuIENBIC1HMDExLDAqBgkqhkiG9w0B CQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVzc2VuLmRlAgcZlNuORnV1MIHlBgsqhkiG9w0B CRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlz YnVyZy1Fc3NlbjE1MDMGA1UECxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1l ZGllbmRpZW5zdGUxLDAqBgNVBAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAt RzAxMSwwKgYJKoZIhvcNAQkBFh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZQIHGZTb jkZ1dTANBgkqhkiG9w0BAQEFAASCAQA+zBnWvXZHYdPkGMcE8cBx+OdnArBrwQC8KiEKvD4S Yr8vkO4oKpp0dE0Zeah5vf4d62vMXxbuF/ExTMMyCwMNk8ZxiZTIvkaU1fcEOvgAiE5fo2cU +k2M67KKTneNapkjxOkC9AREz7Sde2w9Moa015gRaoLVwIwA7csEuST7UlEmSs1cp4AzsTgz fJE0HOif6BSX/YkGc8w884J00TFk2KSTRAar6yn5rqL1khFdv321PnbRHZupfgz7S/nJuC1u 2jZa4VbHzPTX4mEYuJp6F9Gxy/kDYsxWI1lr1cOffV9aUA8/hus172PAGMy9OB5cFJk6FVcy e5ZUEkjmSMdnAAAAAAAA --------------ms050301010508020108080208-- From nobody Thu Jan 5 13: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 3B9081295B9 for ; Thu, 5 Jan 2017 13:28:40 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 ixtiEBwAnn-V for ; Thu, 5 Jan 2017 13:28:38 -0800 (PST) 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 860E512944A for ; Thu, 5 Jan 2017 13:28:38 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s140so33669619qke.0 for ; Thu, 05 Jan 2017 13:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Bf7S/XliDZiiQ97TI65zS0KfU1vBvMlIRSqSZnRIBI4=; b=RJTQWR4tzvjmBoJX2g1ieG7+XbLrE0xZfmAyrt1Ji6ujqzNfor+nyNrQtqwQlblEZJ UrJ79Jby8R9nKvQbbyZhkyRyiSJSgk+uDvuZbL9ciiliKsfvwEj5XwxAqu7HxFgbJevx o85YnCA3x/wSBqMJ/kbr69ZA6JhsdD8A2Es0HMDHGo62TqzFOe1PtofNRcHnlTDjjAy/ fIvnXkhg+B+wNSS4G6ObD3nIdatCgffuSElJmNsI0+UnaBpw4JrdbCDllU4FLzvzCV97 KPEOFQdlRGAOP7nUo6Odl3KD+Pou6LlEtcOn39QiGtuFHqr19GUfVCB9szAkLOihOB48 IRDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Bf7S/XliDZiiQ97TI65zS0KfU1vBvMlIRSqSZnRIBI4=; b=gVUwh0L/DOv7zf9jWTRr1vwVy7vx864tX2YrmIcFocjFjk2/fylStgzPEtyGrWbCMB Ugpi/caMxxLn+MXlo9kakYIn3HKabgWs62IVEm2O1CP9tHeJom3tTdQmLaHfqcE69PnK ukPjCUZ/HnHFxmgYs/gHkrs2Qa8wTlQJl3bK2uYBqLIIFCB5riJzYXHrWW4MlSpN5dJR 8AYIMEnw4k1p835Kg9KfLS9loLUeuLPjNtdMs0oUCY09s5j9qmWzoBwJGEhihHfgoRni AWIuHEzUDT/IXjBx4kJdZfe5ChvkGm/8SmY140ez7Q7kdiy39Lc+KGloSKbMwfV1b4EF WzUg== X-Gm-Message-State: AIkVDXJyUT182v89kJphZjwecnLIKl+yKOuub/7OYd88QD/DMDqjnma4C1JSzMKmVK3kZQ== X-Received: by 10.55.200.76 with SMTP id c73mr71348780qkj.291.1483651717420; Thu, 05 Jan 2017 13:28:37 -0800 (PST) Received: from twicinski-ltm1.internal.salesforce.com ([204.14.236.150]) by smtp.googlemail.com with ESMTPSA id f59sm2076368qtb.7.2017.01.05.13.28.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 13:28:36 -0800 (PST) To: dnsop From: Tim Wicinski Message-ID: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> Date: Thu, 5 Jan 2017 16:28:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 21:28:40 -0000 All Since we're having so much fun on adopting work, let's have another one. We discussed this work in Seoul, and there was a solid hum on adopting this work. This starts a Call for Adoption for: draft-wouters-sury-dnsop-algorithm-update The draft is available here: https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-algorithm-update/ 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: 19 January 2017 Thanks, tim wicinski DNSOP co-chair From nobody Thu Jan 5 15:53: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 453ED12940B for ; Thu, 5 Jan 2017 15:53:04 -0800 (PST) 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_00=-1.9, 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 (1024-bit key) header.d=cloudflare.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 Pt5PNYGTWwK2 for ; Thu, 5 Jan 2017 15:53:02 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 3EE561293D6 for ; Thu, 5 Jan 2017 15:53:02 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id k184so7406187wme.1 for ; Thu, 05 Jan 2017 15:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ExDpDBaPgYqwVQzhCwaYuy+In48yTwKpD8eqLekw0JU=; b=TqVSY/URdeCZtBq3HNTaHDEn5dQffgtco6ETf/ivpH5zZdmavr5eRHjnAFFxFnofRI bQn3NNZyxAwxAKbGjEIWkp4vplTB5cT4aYisgF5C7jBIHufvEDDD8e0gUSsfxyJot59y Ss5C8SAakKKw7maFF8a2jr75GgV7MkYWBSYxE= 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=ExDpDBaPgYqwVQzhCwaYuy+In48yTwKpD8eqLekw0JU=; b=HizQLl5L0qaG6ENr44Sz2NGK+IOSZUN4ySSue8bQvLiEhBFz/d2wOFUehF6UUlzPIk 1TUlcvNYH68+vOgnjrwpxRkX8b4Ik2uFVFtopUEZ72EF3LR9rVkKM/ivqIkWdLkxop+j z9RzRXidCadwrZkb9qDVyOjI/YIrl1mfWbuk91+essi0YKNsDUTA3xI/Xez2x1Vofrmc 4ymm/vPF9xphmAD2AhFWJbeujsZXn9fpCxT3Dl3Brq8e/dUMY3ONndFda4/ebgSjTy5x sapVrbFZOi78RNvBLvj5LBqir16RgJZ7pgxsF2ZsRu0D+npz7rf0OvGHlgpq0gL+wd1l ouxg== X-Gm-Message-State: AIkVDXJDsgxg5mGoLwrgAmqspLCRQJp8P1asUKeHgu7gr5ZK0zdZj+LVgmc5jjUnzbXFSgMMJuAZkRuAjtXkU701 X-Received: by 10.28.48.145 with SMTP id w139mr373578wmw.113.1483660380736; Thu, 05 Jan 2017 15:53:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.11.13 with HTTP; Thu, 5 Jan 2017 15:53:00 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Thu, 5 Jan 2017 18:53:00 -0500 Message-ID: To: Nicholas Weaver Content-Type: multipart/alternative; boundary=001a11423f32f6251e054561990e Archived-At: Cc: dnsop Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:53:04 -0000 --001a11423f32f6251e054561990e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 4, 2017 at 12:33 PM, Nicholas Weaver wrote: > Any system which prevents zone enumeration requires online signing, > https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html > > But NSEC5 is almost certainly not going to be adopted, simply because of > the partial deployment problem. > > NSEC3 lies work today, but people worry that NSEC3 might have server > compromise compromise the ZSK. > > > > So why not simply add a new DNSKEY record flag: NSEC3-only. This flag > means that the key in question can only be used to sign an NSEC* record > when presenting NXDOMAIN. > I used to think that was a good idea, but .... given that this will add keys to the DNSKEY set I think it is not worth it with RSA the DNSKEY sets are too large in most cases. With ECC keys on the other hand this might be reasonable. What is the problem you are solving by having a NSEC-only key ? is it key management, sharing keys with DNS operators, or something else. At Cloudflare we sign a all DNSEC answers on the fly with the exception of DNSKEY/CDS/CDNSKEY which we have to do centrally. This is working and we do not worry too much about ZSK compromise, as we can roll them when we need. We just use Minimally covering NSEC records (no need to do NSEC3), we are looking into adoption that on the fly when under random prefix DDoS attacks, to resolvers that we know support agressive NSEC processing. > This way, you can deploy this solution today using white lies, and as > resolvers are updated, this reduces the potential negative consequence of= a > key compromise to =E2=80=9Cattacker can only fake an NXDOMAIN=E2=80=9D, a= llowing everything > else to still use offline signatures. > > Why is key compromise in DNS more worrying than in HTTPS ? HTTP servers have keys online all the time. > Combine with caching of the white lies to resist DOS attacks and you have > a workable solution that prevents zone enumeration that is deployable tod= ay > and has improved security (key can only fake NXDOMAIN) tomorrow. > > The problem with a FLAG is that it will require a) validator/resolver support b) have a workable key management I think we can do this w/o the flag Regards, Olafur --001a11423f32f6251e054561990e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 4, 2017 at 12:33 PM, Nicholas Weaver <= nweaver@icsi= .berkeley.edu> wrote:
Any s= ystem which prevents zone enumeration requires online signing, https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html
But NSEC5 is almost certainly not going to be adopted, simply because of th= e partial deployment problem.

NSEC3 lies work today, but people worry that NSEC3 might have server compro= mise compromise the ZSK.



So why not simply add a new DNSKEY record flag: NSEC3-only.=C2=A0 This flag= means that the key in question can only be used to sign an NSEC* record wh= en presenting NXDOMAIN.

I used to think= that was a good idea, but .... given that this will add keys to the DNSKEY= set I think it is not worth it with RSA the DNSKEY sets are too large in m= ost cases.=C2=A0
With ECC keys on the other hand this might be reasonabl= e.=C2=A0

What is the problem you are solving by ha= ving a NSEC-only key ?=C2=A0
is it key management, =C2=A0sharing = keys with DNS operators, or something else.=C2=A0

=
At Cloudflare we sign a all DNSEC answers on the fly with the exception= of DNSKEY/CDS/CDNSKEY which we have to do centrally.=C2=A0
This = is working and we do not worry too much about ZSK compromise, as we can rol= l them when we need.=C2=A0
=C2=A0We just use Minimally covering N= SEC records (no need to do NSEC3), =C2=A0
we are looking into= adoption that on the fly when under random prefix DDoS attacks, to resolve= rs that we know support agressive NSEC processing.=C2=A0


This way, you can deploy this solution today using white lies, and as resol= vers are updated, this reduces the potential negative consequence of a key = compromise to =E2=80=9Cattacker can only fake an NXDOMAIN=E2=80=9D, allowin= g everything else to still use offline signatures.


Why is key compromise in DNS more worr= ying than in HTTPS ?=C2=A0
HTTP servers have keys online all the = time.=C2=A0
=C2=A0
Combine with caching of the white lies to resist DOS attacks and you have a= workable solution that prevents zone enumeration that is deployable today = and has improved security (key can only fake NXDOMAIN) tomorrow.


The problem with a FLAG is that it will require=C2=A0
a) validator/resolver support =C2=A0
b) have a workable k= ey management=C2=A0

I think we can do this w/o the= flag=C2=A0

Regards,=C2=A0
Olafur
<= div>
--001a11423f32f6251e054561990e-- From nobody Thu Jan 5 17:49:16 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 43DE8129A39 for ; Thu, 5 Jan 2017 17:49:16 -0800 (PST) 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=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 Jb4_PrzqeojG for ; Thu, 5 Jan 2017 17:49:15 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 9E5BB129A35 for ; Thu, 5 Jan 2017 17:49:10 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id k15so297286979qtg.3 for ; Thu, 05 Jan 2017 17:49:10 -0800 (PST) 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=Q6uQRDfeY/IZtsnG0N/L3MqC2mQQf8euTkies/B+Eko=; b=YhkSn7qAT+VXT6QbnRtqzRmucMRoAnNOPvp8LwP+YAkPBz0wkXY5YncZIe8Dv2/Xht JZi/aCMCJMQ9KeChPX+aUFy+XM8yNyzIT5xYedSxslsE5EAECBjnVml/dKhCPHNw0zli PAy99zwhaexnvTyHesSJDzKX4N73vhm+wX4JwYOoF092grbs1ZdgLqSdPwsbIufnkwc5 kTow6VSVfnEAnobt5QjqCSvjItp56WPdBYFZCibc4KPG329/1yrt4hBY2xwtgccHLoPZ JM2usbDGp5IWRicYR/QqnGmjru3F5iSsguodRj+GwtdFyZtriF/mdw5esLFW2oZXbPdA q0qQ== 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=Q6uQRDfeY/IZtsnG0N/L3MqC2mQQf8euTkies/B+Eko=; b=XmwuTxr5sIhhQq82YwAT5DosS8xq9C5sPGYJgAugIEeUW+Cv0M6xqWz7dkFHc6Zo5u UJohBkA78CpaXrUzymBZfMKPED+fM8TOelZbfra7GEGvAVr8eau4hXZ3w7o+aFdNaPsx r6lmiNA+MbcuWfTL//BIgBfepjJEXPGLqD6VwwreXRCaX35IokLIksIjwecwG72QT5s3 wJcy8jg6vLocQd9xoadu+/qWqFE/JmfTpqWI7Tw5TC+/S+TkIJwjVX+WC6WXFJq0t+g6 090zi2KgXxxq5q7fw5k1F5GUNWFY9F7+J/NXgqzqBDYOsd4i4I4BUpoHu2lyD6IBXazH BGeg== X-Gm-Message-State: AIkVDXK59CRiBOkiLRoGSVgBNaoiPeo1MKDhvlsvQCcvfydCdBoyy3ll2kUQfUO49dp7jCY1f39KoItWzueWyc2d X-Received: by 10.237.62.68 with SMTP id m4mr8393863qtf.171.1483667349646; Thu, 05 Jan 2017 17:49:09 -0800 (PST) MIME-Version: 1.0 References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> In-Reply-To: <20161127111037.GA10721@jurassic> From: Warren Kumari Date: Fri, 06 Jan 2017 01:48:59 +0000 Message-ID: To: Mukund Sivaraman Content-Type: multipart/alternative; boundary=001a11428f88574ffa054563391d Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 01:49:16 -0000 --001a11428f88574ffa054563391d Content-Type: text/plain; charset=UTF-8 On Sun, Nov 27, 2016 at 6:10 AM Mukund Sivaraman wrote: > Hi Warren > > On Mon, Nov 14, 2016 at 02:05:31PM +0900, Warren Kumari wrote: > > Hi all, > > > > I have just submitted "Stretching DNS TTLs" > > (draft-wkumari-dnsop-ttl-stretching-00). > > > > The very high level overview is: > > If you are doing something like HAMMER / pre-fetch, and cannot reach > > the authoritative server when trying to refresh a record, you may > > continue to use a record past the TTL. > > This is working on the theory that stale bread is better than no bread. > > This is a strawman doc / idea, I'm expecting much discussion on if the > > above is true. > > Apparently, there are a couple of approaches that implementations have > taken: > > (1) In a proprietary patch for BIND: > - named as resolver first checks cache for a non-stale/unexpired answer > > - If no answer is found, named performs resolution, and it has to send > one or more fetches (query to an authoritative server) > > - If the fetch takes more than a threshold time (but not as long as the > timeout duration), named then serves any stale answer in the > cache. But named keeps the fetch going until it times out. If the > fetch eventually succeeds, the cache is updated. > > - A stale cache entry is not used beyond a particular maximum time. > Dear all, I'd like to apologize for not having responded (onlist) until now - this was not me ignoring you, rather we were getting our ducks in a row... David Lawrence and I have been chatting since Seoul - he is the author of the above patch; I'm planning on abandoning draft-wkumari-dnsop-ttl-stretching and he and I will (soon) be releasing a joint document which describes the behavior in his patch. This will be describing running code, and so will / should be closer to ready for publication. > (2) In a feature implemented for Unbound: > > - Unbound first checks cache > > - If a stale answer is found, its TTL is set to 0, and the cache entry > is served > > - If a stale answer is found, Unbound starts something similar to > prefetch/HAMMER. > > > NOTE: I believe that there may be (non-Google) IP associated with > > this. A lawyer will be filing the IPR disclosure later today (time > > zone differences, etc). > > The two approaches are somewhat different, and so at least one of them > may not be covered by this patent. > Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was acquired by Akamai in March 2015. I believe that David will discuss the IPR with his employer. W > > Mukund > --001a11428f88574ffa054563391d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Nov 27, 2016 at 6:10 AM Mukund Sivaraman <muks@isc.org> wrote:
Hi = Warren

On Mon, Nov 14, 2016 at 02:05:31PM +0900, Warren Kumari wrote:
> Hi all,
>
> I have just submitted "Stretching DNS TTLs"
> (draft-wkumari-dnsop-ttl-stretching-00).
>
> The very high level overview is:
> If you are doing something like HAMMER / pre-fetch, and cannot reach > the authoritative server when trying to refresh a record, you may
> continue to use a record past the TTL.
> This is working on the theory that stale bread is better than no bread= .
> This is a strawman doc / idea, I'm expecting much discussion on if= the
> above is true.

Apparently, there are a couple of approaches that implementations have
taken:

(1) In a proprietary patch for BIND:=C2=A0
- named as resolver first checks cache for a non-stale/unexpired answer

- If no answer is found, named performs resolution, and it has to send
=C2=A0 one or more fetches (query to an authoritative server)

- If the fetch takes more than a threshold time (but not as long as the
=C2=A0 timeout duration), named then serves any stale answer in the
=C2=A0 cache. But named keeps the fetch going until it times out. If the =C2=A0 fetch eventually succeeds, the cache is updated.

- A stale cache entry is not used beyond a particular maximum time.

Dear all,
<= br>
I'd like to apologize for not having responded (onlist) u= ntil now - this was not me ignoring you, rather we were getting our ducks i= n a row...

David Lawrence and I have been chatting= since Seoul - he is the author of the above patch; I'm planning on aba= ndoning draft-wkumari-dnsop-ttl-stretching and he and I will (soon) be rele= asing a joint document which describes the behavior in his patch. This will= be describing running code, and so will / should be closer to ready for pu= blication.


(2) In a feature implemented for Unbound:

- Unbound first checks cache

- If a stale answer is found, its TTL is set to 0, and the cache entry
=C2=A0 is served

- If a stale answer is found, Unbound starts something similar to
=C2=A0 prefetch/HAMMER.

> NOTE: I believe that there may be (non-Google) IP associated with
> this. A lawyer will be filing the IPR disclosure later today (time
> zone differences, etc).

The two approaches are somewhat different, and so at least one of them
may not be covered by this patent.

Yup. The IPR disclose was about IPR belonging to Xerocole. = Xerocole was acquired by Akamai in March 2015. I believe that David will di= scuss the IPR with his employer.

=C2=A0W
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund
--001a11428f88574ffa054563391d-- From nobody Fri Jan 6 05:42:15 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 085D61294FB for ; Fri, 6 Jan 2017 05:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 tyx1CtAHQgIB for ; Fri, 6 Jan 2017 05:42:11 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF25129525 for ; Fri, 6 Jan 2017 05:42:11 -0800 (PST) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 6 Jan 2017 08:42:17 -0500 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Fri, 6 Jan 2017 08:42:08 -0500 Received: from [129.6.140.7] (7-140.antd.nist.gov [129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v06DfrL4019938 for ; Fri, 6 Jan 2017 08:41:53 -0500 From: "Rose, Scott" To: dnsop Date: Fri, 6 Jan 2017 08:41:54 -0500 Message-ID: In-Reply-To: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 13:42:14 -0000 I have read the previous version, and support this draft becoming a WG document. I will read and review the doc. Scott On 5 Jan 2017, at 16:28, Tim Wicinski wrote: > All > > Since we're having so much fun on adopting work, let's have another > one. We discussed this work in Seoul, and there was a solid hum on > adopting this work. > > This starts a Call for Adoption for: > draft-wouters-sury-dnsop-algorithm-update > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-algorithm-update/ > > 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: 19 January 2017 > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ================================== Scott Rose, NIST scottr@nist.gov ph: +1-301-975-8439 Google Voice: +1-571-249-3671 From nobody Fri Jan 6 06:49: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 00F781294EB for ; Fri, 6 Jan 2017 06:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 93DATscR8YYt for ; Fri, 6 Jan 2017 06:49:02 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (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 C517D12945F for ; Fri, 6 Jan 2017 06:49:02 -0800 (PST) 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.ams1.isc.org (Postfix) with ESMTPS id 1A8621FCC82 for ; Fri, 6 Jan 2017 14:48:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AB539160079 for ; Fri, 6 Jan 2017 14:48:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9EBCD160077 for ; Fri, 6 Jan 2017 14:48:52 +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 F02_aLtohRTl for ; Fri, 6 Jan 2017 14:48:52 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 26E7416004F for ; Fri, 6 Jan 2017 14:48:52 +0000 (UTC) References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> To: dnsop From: Ray Bellis X-Forwarded-Message-Id: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 6 Jan 2017 14:49:26 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:49:04 -0000 Spurred on by Warren's announcement of a Docker image that uses NGINX to proxy TLS connections into DNS servers that don't natively support TLS, I've just written up this short draft describing an EDNS0 option that allows smart proxies to tell the backend server what the original client IP address was. The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf Ray -------- Forwarded Message -------- Subject: New Version Notification for draft-bellis-dnsop-xpf-00.txt Date: Fri, 06 Jan 2017 06:18:40 -0800 From: internet-drafts@ietf.org To: Ray Bellis A new version of I-D, draft-bellis-dnsop-xpf-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsop-xpf Revision: 00 Title: EDNS X-Proxied-For Document date: 2017-01-06 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-00.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-00 Abstract: It is becoming more commonplace to install front end proxy devices in front of DNS servers to provide (for example) load balancing or to perform transport layer conversions. This document defines an option within the EDNS(0) Extension Mechanism for DNS that allows a DNS server to receive the original client source IP address when supplied by trusted proxies. From nobody Fri Jan 6 07:28:30 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 05467129567 for ; Fri, 6 Jan 2017 07:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 oqH-KGzTueqN for ; Fri, 6 Jan 2017 07:28:24 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 6584B129566 for ; Fri, 6 Jan 2017 07:28:24 -0800 (PST) Received: from [172.19.128.50] (vpn-10-mht.dyndns.com [216.146.45.33]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 96DCA87C3 for ; Fri, 6 Jan 2017 16:28:21 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: dnsop@ietf.org References: <20170104171112.GA1967@sources.org> From: Matthijs Mekking Message-ID: <818f1d43-87c1-1c1c-9125-bf9dbe7022c3@pletterpet.nl> Date: Fri, 6 Jan 2017 16:28:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170104171112.GA1967@sources.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:28:26 -0000 On 04-01-17 18:11, Stephane Bortzmeyer wrote: > On Fri, Nov 25, 2016 at 07:50:48PM -0500, > tjw ietf wrote > a message of 114 lines which said: > >> This starts a Working Group Last Call for >> draft-ietf-dnsop-refuse-any > > Since we'll apparently have one more iteration of the draft, one small > detail. The draft says: I'll add some more feedback for the next iteration, that came up during a discussion with some colleagues, to make the document more clearer: 1. In section 7, "Updates to RFC 1035" the draft says "ANY does not mean ALL" and that it is consistent with RFC 1035, while in fact 1035 does say that QTYPE=* means a request for all records. It would be good to clarify the statement in section 7 that even if RFC 1035 says that the ANY query is a request for *all* records, it is not reliable that this also means you get all records. In other words, the response behavior is consistent with 1035. 2. "Conventional ANY response" is used but not defined. A line or two that defines Conventional ANY response to be "a response that includes all the available records at the QNAME" or something like that would be a good addition. 3. Insisting that the HINFO OS field SHOULD be empty seems a little too strong; perhaps it's better to say "The OS field of the HINFO RDATA SHOULD be short to minimize the size of the response. It MAY be empty or MAY include a summarized description of local policy." Perhaps even the keywords can be lowercased? Furthermore I would be interested in the problems that Cloudflare encountered when implementing the HINFO response. All I could find in this thread was "probably a validator will requery with QTYPE=HINFO". Is that statement based on observations or assumptions? Best regards, Matthijs From nobody Fri Jan 6 09:25:58 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 C5382129D2B for ; Fri, 6 Jan 2017 09:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0J-T2Hhz3Z8b for ; Fri, 6 Jan 2017 09:25:55 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 858AD129D28 for ; Fri, 6 Jan 2017 09:25:55 -0800 (PST) Received: from jurassic (unknown [115.118.213.78]) (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 CA7E32FA0225; Fri, 6 Jan 2017 17:25:51 +0000 (GMT) Date: Fri, 6 Jan 2017 22:55:45 +0530 From: Mukund Sivaraman To: Warren Kumari Message-ID: <20170106172545.GA2684@jurassic> References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:25:57 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 06, 2017 at 01:48:59AM +0000, Warren Kumari wrote: > > (2) In a feature implemented for Unbound: > > > > - Unbound first checks cache > > > > - If a stale answer is found, its TTL is set to 0, and the cache entry > > is served > > > > - If a stale answer is found, Unbound starts something similar to > > prefetch/HAMMER. > > > > > NOTE: I believe that there may be (non-Google) IP associated with > > > this. A lawyer will be filing the IPR disclosure later today (time > > > zone differences, etc). > > > > The two approaches are somewhat different, and so at least one of them > > may not be covered by this patent. > > >=20 > Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was > acquired by Akamai in March 2015. I believe that David will discuss the I= PR > with his employer. Please explore if this patent can be circumvented without affecting the goal of the draft, so that it does not apply. It would be better than licensing it under some legal terms. Consequently, if the patented method is strictly adopted, please include an explanation of why it could not be circumvented. Mukund --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYb9MYAAoJEB9EXrAiC5Ls0IIP/RX101CyLBAzX8D/LOzVbX0S iqQIbU+uY7JJfGZ9EOU53+1p9vU2JgXBk8G312e+xhyNSyHd5VskHEAvkhuCvR4/ 5JRLIwHlwR7GLZd0VirdA1gm5MyDQwnQj5clF/mQ3wg/5XMFfuyS1sWT3tzbqb1d OxYiyY0w61xfRqmaMCEZUeEJBs2QQQ6g9ZbrD53+c45Vm5gOehWs4rVW8ovOKcvw FQU7F8aXYxBF2fU4THRxdKLRrAFVilZ0VMVIZoZ4Z4SSuXdnNc/1sTOK19pwAvi6 v1cYEDKc22SL7Tt73MDTsMGTiWDMqtizsh9Urn+f+bIOzvuNWpL+3wEN+oSWZ7yi 3JpC035uQYq+JA609QYBxeKgKgoB9U4t1VH9it6pI1ycK1YlPJy0kb0fd159R99b tPzi8yB5IaNuMwMdvCYg2TgJCkGDwQ7N/gHPbCsiWMCbkz3xtjixRmFblZmjz3qr bW0rhoUUAOhrMP9294+Nl12spTPtGJynCYgHauRgrfcSbiF/ZHGlhOZvXXtDm25O d1SSXDtwS97yNdAchfU1A9b8lkdI5U7zppd2fqP0BVYIkfNBzFLp+/SAXdVkLYII M7FTad8mK5Q2nuz/o98VBl1cv6Ee81QeGhavPyuZMNQ1S3HNjB7yZU0+ZXG5ouAJ CZ1pkVupcZOshP398PdJ =Mknq -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From nobody Fri Jan 6 09:28:26 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 B6320129D2B for ; Fri, 6 Jan 2017 09:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 dRETaSmb15g7 for ; Fri, 6 Jan 2017 09:28:23 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F25129D1D for ; Fri, 6 Jan 2017 09:28:23 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 731F512C110E; Fri, 6 Jan 2017 12:28:22 -0500 (EST) Date: Fri, 6 Jan 2017 12:28:22 -0500 From: Robert Edmonds To: Ray Bellis Message-ID: <20170106172822.cr3zbf22efhm2wga@mycre.ws> References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:28:25 -0000 Ray Bellis wrote: > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. > > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf Hi, Ray: The values used by the "IP Version" field should be specified: IP Version: The IP protocol version number used by the client. Since the field is 4 bits long I would guess this field happens to be the same as the version field in the IP header [0], maybe with the restriction that the field can only take on the values 4 and 6? [0] http://www.iana.org/assignments/version-numbers/version-numbers.xhtml -- Robert Edmonds From nobody Fri Jan 6 09:37: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 725EB129D28 for ; Fri, 6 Jan 2017 09:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 KCWiFCZrnHxK for ; Fri, 6 Jan 2017 09:37:51 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (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 23EA9129D1D for ; Fri, 6 Jan 2017 09:37:51 -0800 (PST) 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.ams1.isc.org (Postfix) with ESMTPS id 343691FCC90; Fri, 6 Jan 2017 17:37:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DF9AB16004F; Fri, 6 Jan 2017 17:37:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C9EA4160077; Fri, 6 Jan 2017 17:37:45 +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 g2LSUrSmeTbD; Fri, 6 Jan 2017 17:37:45 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 43C2816004F; Fri, 6 Jan 2017 17:37:45 +0000 (UTC) To: Robert Edmonds References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <20170106172822.cr3zbf22efhm2wga@mycre.ws> From: Ray Bellis Message-ID: <78ac6d5c-712a-8ef6-e0e0-dc1341645b9a@isc.org> Date: Fri, 6 Jan 2017 17:38:18 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170106172822.cr3zbf22efhm2wga@mycre.ws> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:37:52 -0000 On 06/01/2017 17:28, Robert Edmonds wrote: > Hi, Ray: > > The values used by the "IP Version" field should be specified: > > IP Version: The IP protocol version number used by the client. > > Since the field is 4 bits long I would guess this field happens to be > the same as the version field in the IP header [0], maybe with the > restriction that the field can only take on the values 4 and 6? > > [0] http://www.iana.org/assignments/version-numbers/version-numbers.xhtml Robert, Yes, that seems like a reasonable suggestion, although it would be a shame to have to rev the doc if another IP version should even happen to be introduced in the future... I'd rather leave the question of permitted values open, perhaps with guidance about what to do if the value is not recognised by the server (REFUSED, perhaps?) Ray From nobody Fri Jan 6 09:47: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 40560129591 for ; Fri, 6 Jan 2017 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 55IByQ3_riWI for ; Fri, 6 Jan 2017 09:47:43 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 C7E8A12958C for ; Fri, 6 Jan 2017 09:47:43 -0800 (PST) Received: from mbp-4.local ([IPv6:2620:11a:c081:20:dda:4b57:34ab:34f]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v06Hlgpk004768 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 6 Jan 2017 17:47:42 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:dda:4b57:34ab:34f] claimed to be mbp-4.local To: Mukund Sivaraman , Warren Kumari References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> <20170106172545.GA2684@jurassic> From: joel jaeggli Message-ID: Date: Fri, 6 Jan 2017 09:47:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <20170106172545.GA2684@jurassic> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="scuUt9Or43LLaEQtcgDb661onNeMsW7ow" Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:47:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --scuUt9Or43LLaEQtcgDb661onNeMsW7ow Content-Type: multipart/mixed; boundary="KLpdqCPfX5FkPjFL1ukM9F3hlo05jQCA2"; protected-headers="v1" From: joel jaeggli To: Mukund Sivaraman , Warren Kumari Cc: dnsop Message-ID: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> <20170106172545.GA2684@jurassic> In-Reply-To: <20170106172545.GA2684@jurassic> --KLpdqCPfX5FkPjFL1ukM9F3hlo05jQCA2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 1/6/17 9:25 AM, Mukund Sivaraman wrote: > On Fri, Jan 06, 2017 at 01:48:59AM +0000, Warren Kumari wrote: >>> (2) In a feature implemented for Unbound: >>> >>> - Unbound first checks cache >>> >>> - If a stale answer is found, its TTL is set to 0, and the cache entr= y >>> is served >>> >>> - If a stale answer is found, Unbound starts something similar to >>> prefetch/HAMMER. >>> >>>> NOTE: I believe that there may be (non-Google) IP associated with >>>> this. A lawyer will be filing the IPR disclosure later today (time >>>> zone differences, etc). >>> The two approaches are somewhat different, and so at least one of the= m >>> may not be covered by this patent. >>> >> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole wa= s >> acquired by Akamai in March 2015. I believe that David will discuss th= e IPR >> with his employer. > Please explore if this patent can be circumvented without affecting the= > goal of the draft, so that it does not apply. It would be better than > licensing it under some legal terms. IMHO this can be better expressed as a preference for unencumbered technology. the working group should not as far as I am concerned get buried in how precisely to achieve that. > Consequently, if the patented method is strictly adopted, please includ= e > an explanation of why it could not be circumvented. > > Mukund > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --KLpdqCPfX5FkPjFL1ukM9F3hlo05jQCA2-- --scuUt9Or43LLaEQtcgDb661onNeMsW7ow Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlhv2D4ACgkQ8AA1q7Z/VrKZZQCeI04QwRjxqCsgR1SuOFEaR+wy Z6oAniUG/snWW+14y+tvOT00xAqqJMi8 =/40E -----END PGP SIGNATURE----- --scuUt9Or43LLaEQtcgDb661onNeMsW7ow-- From nobody Fri Jan 6 10:01: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 86DA1129496 for ; Fri, 6 Jan 2017 10:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 SM03GRaV-CfQ for ; Fri, 6 Jan 2017 10:01:11 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8277B128824 for ; Fri, 6 Jan 2017 10:01:11 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id C5BF412C0DC4; Fri, 6 Jan 2017 13:01:10 -0500 (EST) Date: Fri, 6 Jan 2017 13:01:10 -0500 From: Robert Edmonds To: Ray Bellis Message-ID: <20170106180110.fb2yw7kdmqa3kjkm@mycre.ws> References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <20170106172822.cr3zbf22efhm2wga@mycre.ws> <78ac6d5c-712a-8ef6-e0e0-dc1341645b9a@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78ac6d5c-712a-8ef6-e0e0-dc1341645b9a@isc.org> Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:01:12 -0000 Ray Bellis wrote: > Yes, that seems like a reasonable suggestion, although it would be a > shame to have to rev the doc if another IP version should even happen to > be introduced in the future... It can be rev'd in the same document that introduces a DNS address RR for that address family :-) -- Robert Edmonds From nobody Fri Jan 6 10:03:41 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 A27CE1295C9 for ; Fri, 6 Jan 2017 10:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pitbc-T0smw3 for ; Fri, 6 Jan 2017 10:03:37 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A501295AD for ; Fri, 6 Jan 2017 10:03:37 -0800 (PST) Received: from [46.227.151.81] (port=52034 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cPYrV-0001VF-1n (Exim 4.72) for dnsop@ietf.org (return-path ); Fri, 06 Jan 2017 18:03:33 +0000 To: dnsop@ietf.org References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <20170106172822.cr3zbf22efhm2wga@mycre.ws> <78ac6d5c-712a-8ef6-e0e0-dc1341645b9a@isc.org> <20170106180110.fb2yw7kdmqa3kjkm@mycre.ws> From: Ray Bellis Message-ID: <45faf165-f93a-18a5-65fa-d663743fbc94@bellis.me.uk> Date: Fri, 6 Jan 2017 18:04:10 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170106180110.fb2yw7kdmqa3kjkm@mycre.ws> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:03:38 -0000 On 06/01/2017 18:01, Robert Edmonds wrote: > It can be rev'd in the same document that introduces a DNS address RR > for that address family :-) Fair enough! I'll rely on you to remind me when the time comes ;-) Ray From nobody Fri Jan 6 10:25: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 77257129D74 for ; Fri, 6 Jan 2017 10:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3M8XGTuwWBic for ; Fri, 6 Jan 2017 10:25:49 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 927DD129D73 for ; Fri, 6 Jan 2017 10:25:49 -0800 (PST) Received: from jurassic (unknown [115.118.213.78]) (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 4E3B92FA0225; Fri, 6 Jan 2017 18:25:47 +0000 (GMT) Date: Fri, 6 Jan 2017 23:55:42 +0530 From: Mukund Sivaraman To: joel jaeggli Message-ID: <20170106182542.GA10310@jurassic> References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> <20170106172545.GA2684@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:25:50 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 06, 2017 at 09:47:41AM -0800, joel jaeggli wrote: > On 1/6/17 9:25 AM, Mukund Sivaraman wrote: > > On Fri, Jan 06, 2017 at 01:48:59AM +0000, Warren Kumari wrote: > >>> (2) In a feature implemented for Unbound: > >>> > >>> - Unbound first checks cache > >>> > >>> - If a stale answer is found, its TTL is set to 0, and the cache entry > >>> is served > >>> > >>> - If a stale answer is found, Unbound starts something similar to > >>> prefetch/HAMMER. > >>> > >>>> NOTE: I believe that there may be (non-Google) IP associated with > >>>> this. A lawyer will be filing the IPR disclosure later today (time > >>>> zone differences, etc). > >>> The two approaches are somewhat different, and so at least one of them > >>> may not be covered by this patent. > >>> > >> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was > >> acquired by Akamai in March 2015. I believe that David will discuss th= e IPR > >> with his employer. > > Please explore if this patent can be circumvented without affecting the > > goal of the draft, so that it does not apply. It would be better than > > licensing it under some legal terms. > IMHO this can be better expressed as a preference for unencumbered > technology. >=20 > the working group should not as far as I am concerned get buried in how > precisely to achieve that. There's nothing wrong in exploring unencumbered technology. It isn't too much of a diversion to check if the patent can be avoided. IETF has had several drafts that avoid patented methods by documenting something else (compress vs. deflate/gzip, gif vs png, MPEG video vs vpx, MPEG audio vs vorbis, opus, etc.) that usually turned out to be better. One of the authors of this draft works at the company that owns the patent. As he is introducing this draft and implementations such as mine are concerned about the use of this patent, it would be good to attempt to discover if the patented method can be avoided. Mukund --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYb+ElAAoJEB9EXrAiC5LsTzYP/3igiIWKBn2xKvEyL+P6IREw zVM8Llf1m7eyxI8O5IN4BenmxR5fh9eodZ+Ool0hHcjhGsEhIIP77MRH8F3Rcxqb mxYe0dbAcBzdeUpPnFIGjDRRs7j5ZLAcbdGp5Um4MpV3hV0KZqQhtCfSvDjBwQBB nV0IWOibUoxlHLeNS+CtbVXXc687WR6eDs6AeKQE9E0a97YGo03vSVZSM4rxCcYF MMCCRBIiEWr0NUAG3zc3CN1qR3TIT18PahQxO23jcivdizIePvHTHZPIXVU6tq3y 7jH3D6pvFA5mTHW/8M3ny6fCnCEN+DRt91dgrTGI1yuOVBK3+8PiHQIc/V/IGGOl m1uAu1tHZJ4UKzWtfJEgvof4D25uLXC5kiTWPT4xrcwUDShd4StZMxwxGUCitisH ENW2JqI2teClUBeoIgeyBzmOwHmgkbr4dhKKboWioR+Zxfrno+uxFQ7MUfc50WfS DqyG0Gb7EU0Dd9FHSwHBOljjhUrPK0C+F0HMZu6LsMP1CU5sX9czIGMlmU/j1/5k S3jDO92ReZmiFt9TTK2QJIFzcbhOeDT0L6EJ55oc0uMExG69mpdQqgUMptOLE89L xlaujFHgP6sbrbF+L+c95l/DJFs0rs50dsSFpKzWaKWQpE8LD9qrU0/TIThnh/rb 20J3z2s3Og1+wBE7lNyD =GBVT -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From nobody Fri Jan 6 10:43: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 BA061129628 for ; Fri, 6 Jan 2017 10:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 0DQAJ__c_vX1 for ; Fri, 6 Jan 2017 10:43:34 -0800 (PST) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485F31295D8 for ; Fri, 6 Jan 2017 10:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2095; q=dns/txt; s=VRSN; t=1483728215; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9k5s6GogUzReZbsEqhEVl167wvfUoNRPzWT0LzoplTI=; b=hkqmPP7N6BNpcELuLhjUCcF6LMA5/ClaaIOnUHereq5zKQvMsWPVPsoh ocO8bshui/P7eGRfm+ai/dXd8uT4MVxwgJhfoHfuHOXa1KZwm39U7NwB6 2WVHx8SM3b/t+KebyfPTtK76s3SfrbzEuxEhP2P116Cwny0qZB5t0yuwn 58qNWE45WcNVg3F1wIKasQSAnaeQ0dA6tob2T1GW0dHOltGSyL7UlsUhw EyThrvwU1mFS66K3IpO5fupM6MXBHA/QimrpUU/3uWUIWuyyzYsB+RZWt YaOBu4XXJ+nGkzEQLbl3CXOH3ylpIALwg1/gQ4Np4rxY7KtdKF/mjR2H7 Q==; X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="1122631" IronPort-PHdr: =?us-ascii?q?9a23=3AFGvCLR87/Ki1E/9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?1uMcTK2v8tzYMVDF4r011RmSDNmdsasP0rOP+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFHiTanf79+MRq6oRjMusULnIBvNrs/xhzVr3VSZu?= =?us-ascii?q?9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnY?= =?us-ascii?q?UQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRRn1gy?= =?us-ascii?q?kFKjE56nnahMxugqxGvBKvqR9xw4DWb4GUKPVwcazScMgGRWpYW8ZdSzBNDp+i?= =?us-ascii?q?Y4YJEuEPPfxYr474p1YWoxexBRejBPj0yjBWgn/2xrU22PkvHwHbxgMgGcwBvH?= =?us-ascii?q?rJp9jyKagTX/66zLLTzTrda/NWwizw6JbWfRA7oPGMRrNwccXXyUU1CwzFiVCQ?= =?us-ascii?q?pJXjMjiI2OoNtG2b4PBhVeKpk2MnpABxoiSvxscxkYbFnJ4aylfB9Sh/3Y07Js?= =?us-ascii?q?W4RVZmbdK4CpdcqiOXOoVsTs8/Q2xltjw2xqMJtJO7ZCQG1YgrywTCZ/GFfYWE?= =?us-ascii?q?+A/vWeaPLTtii39ofq+0iQyo/ki60OL8U9G50FNNriVYjNbBrmsN1xnP6sifTf?= =?us-ascii?q?t941uh1S6P1w/N7uFEJlg5mrHBK54n37IwkpUSsUHZES/3nEX2i7KWdlk49uS2?= =?us-ascii?q?8ejnfKvppoWdN49viwH+PaIultajDuQ/NwgCR2mb+eKi273/5UD1XalGgucrnq?= =?us-ascii?q?Tbvp3WP9kXq663DgNPzIou5BayAy+j0NsCnHkHKFxFeAiAj4jsI1zBPf75Aumk?= =?us-ascii?q?g1S3jjhrw+vGM6b/AprTNHjDkazhfbdy605a0gY80ddf55dMBrEbPP3zQlPxtM?= =?us-ascii?q?DfDhIhLgO0xf3nCNJl1o4FWGKAHLOZMK3IvV+P/OIvLPGGZJUJtzblN/gl+/nu?= =?us-ascii?q?gGcjmVAHfaikxpoXaGukEfh8JEWZe3Xs0Z89FjIwtxt2ZuHujFyZGWpJbmeaXr?= =?us-ascii?q?k3oDYhB9T1I53EQ9Xnv7Gaxyq/BdkeSn1PDF3GWSPkaIifQPoIcwqML9VgiT0L?= =?us-ascii?q?U/6qTIp3hkLmjxPz17cydrmcwSYfr5+2jNU=3D?= X-IPAS-Result: =?us-ascii?q?A2GMAQCc5G9Y//WZrQpeGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?Bgw4BAQEBAX6BDAeNUJIhkxeCD4FGQyqFeAKCFBQBAQEBAQEBAQEBAQKBCIIzG?= =?us-ascii?q?AsEPQ0vAQEBAQEBAQEBAQEBAQEBGgINXQEBAQECATo9AgULAgEIDQseEDIlAgQ?= =?us-ascii?q?OBYhoFrJfih0BAQEBAQEBAwEBAQEBAQEBAQEBGAWGRoIBCIJXhDAWgzWCMQWbD?= =?us-ascii?q?wYBhlebSpJRH4F1FUQBhE2BR3OHWYENAQEB?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v06IhVqH020592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 13:43:31 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Fri, 6 Jan 2017 13:43:30 -0500 From: "Wessels, Duane" To: Ray Bellis Thread-Topic: [EXTERNAL] [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt Thread-Index: AQHSaCwMAy/AsMRjWEG8SvXHw3bAyqEsHSiA Date: Fri, 6 Jan 2017 18:43:30 +0000 Message-ID: <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <870A959A18183D478D32BE4B24958BA4@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:43:37 -0000 > On Jan 6, 2017, at 6:49 AM, Ray Bellis wrote: >=20 > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. >=20 > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf Hi Ray, The idea of "X-Forwarded-For" for DNS makes me nervous, but it is probably = inevitable.=20 It is of course quite similar to EDNS client subnet, except that there is n= o masking and the client cannot opt-out. Might be worth saying in your doc= ument why EDNS client subnet wouldn't work for this purpose. Since you use the term proxy throughout I wondered if proxy was defined in = our terminology document. Looks like it is not. terminology-bis-03 says: [RFC5625] does not give a specific definition for forwarding, but describes in detail what features a system that forwards need to support. Systems that forward are sometimes called "DNS proxies", but that term has not yet been defined (even in [RFC5625]). I think we should define proxy in the terminology doc, or use some other we= ll-defined terms in your XPF doc. Despite when you say "it is not intended for use on proxy / forwarder devic= es that sit on the client-side of a DNS request" and "only intended for use= on server-side proxy devices that are under the same administrative contro= l" I fully expect XPF will be implemented and used in all sorts of places. = For example, some clients will include the option in queries to authoritat= ive servers, which will go unnoticed for a while. Then it will be noticed= by servers and they'll take advantage of it somehow (logging, treating it = like ECS, etc). To hopefully prevent that I might propose something like: When a server receives the option from a non-whitelisted client, it MUST = return a FORMERR response. DW From nobody Fri Jan 6 11:00: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 21C2D129BB0 for ; Fri, 6 Jan 2017 11:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 qKtRlXKG4b-9 for ; Fri, 6 Jan 2017 11:00:40 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 9CA2E129BAE for ; Fri, 6 Jan 2017 11:00:40 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id 192so22294238itl.0 for ; Fri, 06 Jan 2017 11:00:40 -0800 (PST) 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=TUwUELqvkNOOM76v0ou+SQOX6zXUAfuemMJADiYbqKg=; b=NtDT4pQwMZf3iqfdoVlk1BtHGE1KyyxX52YkBmDrxg3iXSMjXjmR2JIF85e1fmF+iD q4ORIzbwZPcl3hyqcPPBXdbumeZDRLN5fCdIakHm7duxopOjal2pEkYDLHOCXuDJiIfU w/qVEHjL4liAn0bH5xQdYDPmfmWVxBYpB5ix1hdSLrfnEz73U/bJDxlI+g5z4aviJrcC VRlGCVmhSQcSngUfkWcfsEyj/S2MsDym1jJy1CTYuVEsKgOMKxrB/GhkBuVnsZ4bsMjs quQDZoYU7bBzYlflrtQQlp9qNK8lZppyf3epjB82akH4FqVuTtHwELaFEhe2GStDN/wv 7Pww== 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=TUwUELqvkNOOM76v0ou+SQOX6zXUAfuemMJADiYbqKg=; b=s/Xn87Y3fGiImOQcsAOOMvLC+qrD7bSmS91YVC474DPI+iD57SZ0PjVvxuKbBTOIuo wY7Krco1haaD8pqaDnAGzE5Gx3GwnHtG6KrwvkfHzut+1KLRT4Dj/LYhCGL9bMvHMQ68 JUtWWZjWDdEAgiyGUKe6jrLX9VNRN4u3mR9UemMKnDyYV+LRYr236OnGSEqy3/7Fdksa 7wzFiKLPSNpkplzYaoQ/6KHTn2T7Ar3Bgj3G1FPcshCUZHBDBfLVxxxF2EvHa+uKZN99 ynIwhTgX+8MZgx+VMXI6YfkUsoZRrJ2C0ql3u3EBH7FcdYhCB7IGB62Q37n3bBs0270t LsaA== X-Gm-Message-State: AIkVDXJ8enUNu8jx72PXVE97vJRlhNgfHHJs5xG41AgFmehUpRpP/T+pIc0HMa8mvkHOLZjYBQkdgMtCluql0Q== X-Received: by 10.36.58.198 with SMTP id m189mr54752itm.105.1483729239809; Fri, 06 Jan 2017 11:00:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.163.19 with HTTP; Fri, 6 Jan 2017 11:00:39 -0800 (PST) In-Reply-To: <20170106182542.GA10310@jurassic> References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> <20170106172545.GA2684@jurassic> <20170106182542.GA10310@jurassic> From: tjw ietf Date: Fri, 6 Jan 2017 14:00:39 -0500 Message-ID: To: Mukund Sivaraman Content-Type: multipart/alternative; boundary=001a11441658482d7a054571a24d Archived-At: Cc: joel jaeggli , dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:00:42 -0000 --001a11441658482d7a054571a24d Content-Type: text/plain; charset=UTF-8 Mukund, While I agree with you, Joel has the right guidance on this; but also knowing the authors fairly well, I feel they would not send us down a road that will box the work into a corner. On Fri, Jan 6, 2017 at 1:25 PM, Mukund Sivaraman wrote: > On Fri, Jan 06, 2017 at 09:47:41AM -0800, joel jaeggli wrote: > > On 1/6/17 9:25 AM, Mukund Sivaraman wrote: > > > On Fri, Jan 06, 2017 at 01:48:59AM +0000, Warren Kumari wrote: > > >>> (2) In a feature implemented for Unbound: > > >>> > > >>> - Unbound first checks cache > > >>> > > >>> - If a stale answer is found, its TTL is set to 0, and the cache > entry > > >>> is served > > >>> > > >>> - If a stale answer is found, Unbound starts something similar to > > >>> prefetch/HAMMER. > > >>> > > >>>> NOTE: I believe that there may be (non-Google) IP associated with > > >>>> this. A lawyer will be filing the IPR disclosure later today (time > > >>>> zone differences, etc). > > >>> The two approaches are somewhat different, and so at least one of > them > > >>> may not be covered by this patent. > > >>> > > >> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole > was > > >> acquired by Akamai in March 2015. I believe that David will discuss > the IPR > > >> with his employer. > > > Please explore if this patent can be circumvented without affecting the > > > goal of the draft, so that it does not apply. It would be better than > > > licensing it under some legal terms. > > IMHO this can be better expressed as a preference for unencumbered > > technology. > > > > the working group should not as far as I am concerned get buried in how > > precisely to achieve that. > > There's nothing wrong in exploring unencumbered technology. It isn't too > much of a diversion to check if the patent can be avoided. > > IETF has had several drafts that avoid patented methods by documenting > something else (compress vs. deflate/gzip, gif vs png, MPEG video vs > vpx, MPEG audio vs vorbis, opus, etc.) that usually turned out to be > better. > > One of the authors of this draft works at the company that owns the > patent. As he is introducing this draft and implementations such as mine > are concerned about the use of this patent, it would be good to attempt > to discover if the patented method can be avoided. > > Mukund > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a11441658482d7a054571a24d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mukund,

While I agree with you, Joel ha= s the right guidance on this; but also knowing the authors fairly well, =C2= =A0
I feel they would not send us down a road that will box the w= ork into a corner.=C2=A0

On Fri, Jan 6, 2017 at 1:25 PM, Mukund Sivaraman <muks@isc.o= rg> wrote:
On Fri, Jan 06, 2017 at 09:47:41AM -0800, joel jaeggli wrote:
> On 1/6/17 9:25 AM, Mukund Sivaraman wrote:
> > On Fri, Jan 06, 2017 at 01:48:59AM +0000, Warren Kumari wrote: > >>> (2) In a feature implemented for Unbound:
> >>>
> >>> - Unbound first checks cache
> >>>
> >>> - If a stale answer is found, its TTL is set to 0, and th= e cache entry
> >>>=C2=A0 =C2=A0is served
> >>>
> >>> - If a stale answer is found, Unbound starts something si= milar to
> >>>=C2=A0 =C2=A0prefetch/HAMMER.
> >>>
> >>>> NOTE: I believe that there may be (non-Google) IP ass= ociated with
> >>>> this. A lawyer will be filing the IPR disclosure late= r today (time
> >>>> zone differences, etc).
> >>> The two approaches are somewhat different, and so at leas= t one of them
> >>> may not be covered by this patent.
> >>>
> >> Yup. The IPR disclose was about IPR belonging to Xerocole. Xe= rocole was
> >> acquired by Akamai in March 2015. I believe that David will d= iscuss the IPR
> >> with his employer.
> > Please explore if this patent can be circumvented without affecti= ng the
> > goal of the draft, so that it does not apply. It would be better = than
> > licensing it under some legal terms.
> IMHO this can be better expressed as a preference for unencumbered
> technology.
>
> the working group should not as far as I am concerned get buried in ho= w
> precisely to achieve that.

There's nothing wrong in exploring unencumbered technology. It i= sn't too
much of a diversion to check if the patent can be avoided.

IETF has had several drafts that avoid patented methods by documenting
something else (compress vs. deflate/gzip, gif vs png, MPEG video vs
vpx, MPEG audio vs vorbis, opus, etc.) that usually turned out to be
better.

One of the authors of this draft works at the company that owns the
patent. As he is introducing this draft and implementations such as mine are concerned about the use of this patent, it would be good to attempt
to discover if the patented method can be avoided.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--001a11441658482d7a054571a24d-- From nobody Fri Jan 6 11:42: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 2AFC4129E09 for ; Fri, 6 Jan 2017 11:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b3OXorPkEzNk for ; Fri, 6 Jan 2017 11:42:05 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 07DB7129610 for ; Fri, 6 Jan 2017 11:42:04 -0800 (PST) Received: from jurassic (unknown [115.118.213.78]) (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 BC6BA2FA0225; Fri, 6 Jan 2017 19:42:02 +0000 (GMT) Date: Sat, 7 Jan 2017 01:11:59 +0530 From: Mukund Sivaraman To: tjw ietf Message-ID: <20170106194159.GA14578@jurassic> References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> <20170106172545.GA2684@jurassic> <20170106182542.GA10310@jurassic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Cc: joel jaeggli , dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:42:06 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tim On Fri, Jan 06, 2017 at 02:00:39PM -0500, tjw ietf wrote: > Mukund, >=20 > While I agree with you, Joel has the right guidance on this; but also > knowing the authors fairly well, > I feel they would not send us down a road that will box the work into a > corner. Yes, it was not in any way a statement about these particular authors. I know the two authors are trying to work together to document something which will be beneficial for DNS. Having spoken to DCL about this in Seoul (I told DCL that Warren wanted to make a draft for this and they should get in touch), I don't think he has any specific interest to incorporate a patented idea. Their interest is in having the details of TTL stretching worked out. However, when there is any person X introducing a specificiation which incorporates a patent he/she owns, it could appear self-serving. In this case, isn't it due process to question if any other approaches are possible? (I say this in general terms - not specifically about this author or his company.) TTL stretching is a simple problem (it isn't a complicated area such as a media codec). Exploring whether the method can be implemented without being encumbered by the known patent wouldn't take a lot of time or discussion. This isn't even a published draft yet, so we don't know what the authors may come up with. There have been some noises from the nethers that the patent could be avoided with minor modifications. I'm encouraging the authors again to do some exploring. :P Mukund --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYb/MGAAoJEB9EXrAiC5LsfJYP/0C71hFgQag1IB8hdQ/tnd7z tN3vJZldvncpTrtI7K1TqsyVI/npjHP+MrqGV/NX8FXXxYjqH3AEOJLRZjafSyIZ HCdbnz7Vx621/+IdJLO3qnRcsXrbHeFx3CoQTeB0w0OyD71hSw+WZ2o0wputP4SJ 1ycnZAqyFu1YrtlWL1tamuIbGU/FC0PBGAeO8vWub7oU52QPcrLf0x2Xmt9tN/Wp JeJr6JkdO8n/1PpB8E6m59QRwinylWutGs51O3jx7hVniIuHGA+4ZPD6wL6s59DF tQS6xIJsifXmf65/xtQezatonM3sw0bKrzaxDse2eS+2MYfElSQHWC6lN3B2Rar3 L0YzlVcBNxeckhuY18/u/4sR0TEEXRo2YaeqbgEnX5qfWq6T0UwkhrzLTEKYJQnI GUxZa4Se7Gps9xXJpud00dHq4OnYZAEOuUfkXHzQTb5H3tMYv608pNTBDCIkZcAt 6kxcxjPV/6UPpS/MmUnUocW+QmgvRmrIbV8nodHoPcM6banWjJMexdhHUhsBBNDM sL2dAamIGM0ZlDYDzIJtMKCkR5p5VkiebfrlV1g7BQtqtdllyQH8x8w8F1ETGKeJ pdhnrGNM7SNBvBWjDt4fLCM5gw7N4aYHEtq/J2DfTnQT6rDwt9vHsgY7Cj72bfu8 ZnKuOXt3jyzoKmp+Mz2K =UPyJ -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From nobody Fri Jan 6 11:58: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 9BB48129DFE for ; Fri, 6 Jan 2017 11:58:33 -0800 (PST) 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=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 Ivzc9SNRh98m for ; Fri, 6 Jan 2017 11:58:31 -0800 (PST) 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 60B21129651 for ; Fri, 6 Jan 2017 11:58:31 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n21so475329965qka.3 for ; Fri, 06 Jan 2017 11:58:31 -0800 (PST) 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=C5vnV6ctCqwn6p4S03qoAqlHUU4Lr3JMpuLw98s/SL8=; b=mDEaXqtItnOqJsgPeQt5SeVG+dDBJ+HciQ+emoKB3hMSeEHW1s78Q9uxticrmLjQVk hXzu27ssFawuaBpafy/hIZvoQ99THuqpedFs/VLDNM/akP/z3VCD+JUBXZkk4xPR0ASE H83I83a7CcrYP6b45foGf9zvtqr940WEcLz3t86e5+dHErSfOs3A78yUrlaHL+9ZzN/E TNkWJlUq7isMFUTifzim6gmlGtkUcjxO3MxmIH5s3vWCXJHYuCfslL/S17yB7P9DJymI zBujZUyaSq0HrdaHWr6BvGWz+5ta3JT5Z1hlTa7V2GUEMc+z6YtDTQU2gyXoK3Gz/ufT Z6Ng== 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=C5vnV6ctCqwn6p4S03qoAqlHUU4Lr3JMpuLw98s/SL8=; b=jBphGTet9pRFpuknNgoCuku7Wy168Vxh/I9ymXo/TKnDQRmGsJhk1ZUfUtbfx5Oh1g yIvXs9b0jA6MlyfbqoV7th5l9BZ6rFzbs8J386kQygEmKMUt5i9e7Pd5dfhokyEy+S1p S03R5wBVftj3pmi2KW71KiMT3Zsx9zPHevH3IhAuTdH38HChzJPQFks5GoczQUaAogEp J1jucZ3WkW2mbHos8W0a72y6k999tWpZJcDdtakzcvEKNBeBqgwBYqOwmdBL5PCSMjtH e8Us8dPpsfSWjntwpgraECgqTCiYefaGoOOUovptM8gya9r7Y19mVL+7D4//NmvsRnVp y8Uw== X-Gm-Message-State: AIkVDXL53B8VF0bOFwEyd+WfDCcGGHtk+gMblug3Scm7JDEfkpy8kkuJX5Q++I6veG+GjjHt02nJCKP6KIPWh2J7 X-Received: by 10.55.212.157 with SMTP id s29mr71563254qks.240.1483732710325; Fri, 06 Jan 2017 11:58:30 -0800 (PST) MIME-Version: 1.0 References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Fri, 06 Jan 2017 19:58:19 +0000 Message-ID: To: Ray Bellis , dnsop Content-Type: multipart/alternative; boundary=001a1149dbf42437700545727189 Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:58:33 -0000 --001a1149dbf42437700545727189 Content-Type: text/plain; charset=UTF-8 For folk wondering what Ray is referring to below, I posted this to the DPRIVE (dns-privacy@) list last night. I was originally going to CC dnsop@ but cross-posting leads to many "your message could not be delivered, you aren't subscribed" errors. The obvious, bestest solution would just be for everyone in dnsop to subscribe to dns-privacy@ -- we're a friendly bunch, and are always looking for more victims for reviews^w^w^w participants... :-) Original DPRIVE email: --------- Hi all, I have created a Docker container for easily deploying a DPRIVE RFC7858 (DNS over TLS) server. This is implemented by putting a TLS proxy (NGINX) in front of a recursive nameserver (BIND). It can be found here: https://github.com/wkumari/dprive-nginx-bind This repo contains the Dockerfile, some rudimentary documentation and supporting files, including NGINX and BIND configs, and some Google Container Engine configs for starting and running the container / service. Most of the credit goes to Sara / Sinodun for documenting how to run BIND behind NGINX as a TLS proxy. I just wrapped this up in a container. Please let me know what you think, open issues, send pull requests, etc. Thanks. W On Fri, Jan 6, 2017 at 9:49 AM Ray Bellis wrote: > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. > > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf > > Ray > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-bellis-dnsop-xpf-00.txt > Date: Fri, 06 Jan 2017 06:18:40 -0800 > From: internet-drafts@ietf.org > To: Ray Bellis > > > A new version of I-D, draft-bellis-dnsop-xpf-00.txt > has been successfully submitted by Ray Bellis and posted to the > IETF repository. > > Name: draft-bellis-dnsop-xpf > Revision: 00 > Title: EDNS X-Proxied-For > Document date: 2017-01-06 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-00.txt > Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ > Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-00 > > > Abstract: > It is becoming more commonplace to install front end proxy devices in > front of DNS servers to provide (for example) load balancing or to > perform transport layer conversions. > > This document defines an option within the EDNS(0) Extension > Mechanism for DNS that allows a DNS server to receive the original > client source IP address when supplied by trusted proxies. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a1149dbf42437700545727189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For folk wondering what Ray is referring to below, I poste= d this to the DPRIVE (dns-privacy@) list last night. I was originally going= to CC dnsop@ but cross-posting leads to many "your message could not = be delivered, you aren't subscribed" errors. The obvious, bestest = solution would just be for everyone in dnsop to subscribe to dns-privacy@ -= - we're a friendly bunch, and are always looking for more victims for r= eviews^w^w^w participants... :-)

Original DPRIVE email:<= /div>
---------
Hi all,

I have created a Docker container f= or easily deploying a DPRIVE RFC7858 (DNS over TLS) server. This is impleme= nted by putting a TLS proxy (NGINX) in front of a recursive nameserver (BIN= D).

It can be found here:=C2=A0https://github.co= m/wkumari/dprive-nginx-bind

This repo contains= the Dockerfile, some rudimentary documentation and supporting files, inclu= ding NGINX and BIND configs, and some Google Container Engine configs for s= tarting and running the container / service.

=
Most = of the credit goes to Sara / Sinodun for documenting how to run BIND behind= NGINX as a TLS proxy. I just wrapped this up in a container.

Please let me know what you think, open issues, send pull reque= sts, etc.=C2=A0

Thanks.
W



On Fri, Jan 6, 20= 17 at 9:49 AM Ray Bellis <ray@isc.org= > wrote:
Spurred on by Warren= 9;s announcement of a Docker image that uses NGINX to
proxy TLS connections into DNS servers that don't natively support TLS,=
I've just written up this short draft describing an EDNS0 option that allows smart proxies to tell the backend server what the original client IP address was.

The master doc is at https://= github.com/raybellis/draft-bellis-dnsop-xpf

Ray

-------- Forwarded Message --------
Subject: New Version Notification for draft-bellis-dnsop-xpf-00.txt
Date: Fri, 06 Jan 2017 06:18:40 -0800
From: internet-drafts@ietf.org
To: Ray Bellis <ray@isc.org>


A new version of I-D, draft-bellis-dnsop-xpf-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bellis-dnsop-xpf
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EDNS X-Proxied-For
Document date:=C2=A0 2017-01-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:
https://www.ie= tf.org/internet-drafts/draft-bellis-dnsop-xpf-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bellis-dnsop-xpf-00


Abstract:
=C2=A0 =C2=A0It is becoming more commonplace to install front end proxy dev= ices in
=C2=A0 =C2=A0front of DNS servers to provide (for example) load balancing o= r to
=C2=A0 =C2=A0perform transport layer conversions.

=C2=A0 =C2=A0This document defines an option within the EDNS(0) Extension =C2=A0 =C2=A0Mechanism for DNS that allows a DNS server to receive the orig= inal
=C2=A0 =C2=A0client source IP address when supplied by trusted proxies.

_______________________________________________
DNSOP mailing list
DNS= OP@ietf.org
https://www.ietf.org/mailman/listinfo= /dnsop
--001a1149dbf42437700545727189-- From nobody Fri Jan 6 12:00:00 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 037D6129E16; Fri, 6 Jan 2017 11:59:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148373279797.17426.16878442999816670436.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 11:59:57 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:59:58 -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 : DNS catalog zones Authors : Mukund Sivaraman Stephen Morris Ray Bellis Witold Krecicki Filename : draft-muks-dnsop-dns-catalog-zones-02.txt Pages : 18 Date : 2017-01-06 Abstract: This document describes a method for automatic zone catalog provisioning and synchronization among DNS primary and secondary nameservers by storing and transferring the catalogs as regular DNS zones. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-muks-dnsop-dns-catalog-zones-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-catalog-zones-02 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 Fri Jan 6 12:41: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 E6C7A129654 for ; Fri, 6 Jan 2017 12:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 bioPjnSAPNTW for ; Fri, 6 Jan 2017 12:41:01 -0800 (PST) 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 1479B129E7C for ; Fri, 6 Jan 2017 12:41:01 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 1ACDF349651; Fri, 6 Jan 2017 20:40:59 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 0E03D216C1C; Fri, 6 Jan 2017 20:40:59 +0000 (UTC) Date: Fri, 6 Jan 2017 20:40:59 +0000 From: Evan Hunt To: "Wessels, Duane" Message-ID: <20170106204059.GB28858@isc.org> References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dnsop , Ray Bellis Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 20:41:02 -0000 On Fri, Jan 06, 2017 at 06:43:30PM +0000, Wessels, Duane wrote: > When a server receives the option from a non-whitelisted client, it > MUST return a FORMERR response. +1 -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Jan 6 14:01: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 6A036129458 for ; Fri, 6 Jan 2017 14:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gGTPhg_INsSS for ; Fri, 6 Jan 2017 14:01:41 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF4512944B for ; Fri, 6 Jan 2017 14:01:41 -0800 (PST) Received: from [46.227.151.81] (port=53130 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cPcZs-0007Wn-2G (Exim 4.72) for dnsop@ietf.org (return-path ); Fri, 06 Jan 2017 22:01:36 +0000 To: dnsop@ietf.org References: <148371232017.17418.17291340320637379369.idtracker@ietfa.amsl.com> <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> From: Ray Bellis Message-ID: Date: Fri, 6 Jan 2017 22:02:16 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <54C32FCA-8248-441A-9D44-9EEFEB1F00E5@verisign.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:01:43 -0000 On 06/01/2017 18:43, Wessels, Duane wrote: > Hi Ray, > > The idea of "X-Forwarded-For" for DNS makes me nervous, but it is > probably inevitable. > > It is of course quite similar to EDNS client subnet, except that > there is no masking and the client cannot opt-out. Might be worth > saying in your document why EDNS client subnet wouldn't work for this > purpose. I believe that dnsdist / PowerDNS is already (ab)using the ECS option for this purpose. The intent in part is to provide a separate option so that "real" ECS can pass unhindered. [ not that I think ECS is a good idea, but some folks want it, c'est la vie ] > Since you use the term proxy throughout I wondered if proxy was > defined in our terminology document. Looks like it is not. > terminology-bis-03 says: > > [RFC5625] does not give a specific definition for forwarding, but > describes in detail what features a system that forwards need to > support. Systems that forward are sometimes called "DNS proxies", > but that term has not yet been defined (even in [RFC5625]). > > I think we should define proxy in the terminology doc, or use some > other well-defined terms in your XPF doc. I should probably define "proxy". I specifically avoided the term "forwarding" (c.f. X-Forwarded-For in HTTP) because in our terminology a forwarder is usually something on the "outbound" side of a resolver, whereas this is on the "inbound" side. > Despite when you say "it is not intended for use on proxy / forwarder > devices that sit on the client-side of a DNS request" and "only > intended for use on server-side proxy devices that are under the same > administrative control" I fully expect XPF will be implemented and > used in all sorts of places. For example, some clients will include > the option in queries to authoritative servers, which will go > unnoticed for a while. Then it will be noticed by servers and > they'll take advantage of it somehow (logging, treating it like ECS, > etc). To hopefully prevent that I might propose something like: > > When a server receives the option from a non-whitelisted client, it > MUST return a FORMERR response. That's a very good idea. I should probably also include even more explicit text explaining that this is for "internal use" only, and MUST NOT be sent from a stub to a resolver, nor from an recursor to an authority server. It's only intended to be injected by server-side DNS equipment that's a front-end onto local DNS servers that would already know the client source IP if the proxy wasn't there. thanks! Ray From nobody Fri Jan 6 14:04: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 33E6012965F for ; Fri, 6 Jan 2017 14:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 zm-0f3kOedMk for ; Fri, 6 Jan 2017 14:04:07 -0800 (PST) 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 D0D4D129642 for ; Fri, 6 Jan 2017 14:04:07 -0800 (PST) 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 80058349644 for ; Fri, 6 Jan 2017 22:04:05 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7681016004F for ; Fri, 6 Jan 2017 22:04:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 68EBC160077 for ; Fri, 6 Jan 2017 22:04:05 +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 V_PAZkoo3_Be for ; Fri, 6 Jan 2017 22:04:05 +0000 (UTC) Received: from rays-mbp.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 0A6BE16004F for ; Fri, 6 Jan 2017 22:04:04 +0000 (UTC) To: dnsop From: Ray Bellis Message-ID: <10df70ca-f153-ea52-2796-9a2c0a8e0d78@isc.org> Date: Fri, 6 Jan 2017 22:04:41 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.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 Workship 26, Madrid, 14-15 May 2017 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:04:09 -0000 [with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 26th Workshop will take place in Madrid, Spain on May 14th and 15th 2017, the Sunday and Monday following the ICANN GDD Industry Summit 2017. The Workshop's Program Committee is now requesting proposals for presentations. This workshop intends to build from previous strong DNS-OARC workshops, where both operational content and research are welcome. 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 will accommodate those talks too. A timeslot will be available for lightning talks (5-10 minutes) on Monday May 15th, for which submissions will be accepted during May 14th on a first-come first-served basis. Workshop Milestones: 6th January 2017, Call for Presentations posted and open for submissions 24th February 2017, Deadline for submission 17th March 2017, Draft Programme published 14th April 2017, Final Program published 28th April 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/26/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 Jan 6 14:20:46 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 695AE12948D for ; Fri, 6 Jan 2017 14:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 9Y4tDE_oc-Jk for ; Fri, 6 Jan 2017 14:20:42 -0800 (PST) Received: from mail-vk0-x245.google.com (mail-vk0-x245.google.com [IPv6:2607:f8b0:400c:c05::245]) (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 3F4DD129487 for ; Fri, 6 Jan 2017 14:20:42 -0800 (PST) Received: by mail-vk0-x245.google.com with SMTP id 19so269855487vko.0 for ; Fri, 06 Jan 2017 14:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=O9WxDG1/7ZFB+JwzBNmZ/AS0wT80jPd6zjwl2aSdSeA=; b=eTOSZRJBTD6mxkgG8LGNY4aTR0nsnvY45qH3grGW3ujLSo6TzE1gHuOnhAsb0BzgN+ iekiE7GToOTs9QAi1Jcxjr7r44yZOSN7j/XGp4oh7QCJ1f6GJU3vMeUTm0v+8oqh0VRs qouFqF5/jUQXO8V8FKza3WYsaEPZx2BTRDF6Y= 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=O9WxDG1/7ZFB+JwzBNmZ/AS0wT80jPd6zjwl2aSdSeA=; b=NjnIFcMFMcu/wpudMUvSQe07uCSW/rkRVF748YRgG/9J/j/4Ug3ZM+4F1wdWQdC0lO OfYB1sW4d5bTPHqDVpAqZUx3Lx/Fi5bSp4iF+driBG+/UY2y4t+KCBlXKukg8LswKNDH ZK4tL/+uiHPlddlc1QTuxoLSAvBLCdosCaXzVQHFBGjLvBOxqD7zGuolCIPSmd2AvnjB Um7S1rqwo7LO0AGVikjxIkKlcY9p1vVGcZ/cHhiceBNEfsYkPmFs/CeiXeT7t+3Wh0zX QANZEXVZEz+2Awc9Z5MtZnDFQUwfCmiwfmoFqh3x+jjvGPy+mD68TAwaaqpRs8n+vDD/ 9DJA== X-Gm-Message-State: AIkVDXI/7xfA7+Eim7GXXatZX2KXLbKqXH+qi4AO+1B5u9pzlO1N1MSObGIAXfa4sja8TWtqV9GthZ2/PpoJwGFa X-Received: by 10.176.4.22 with SMTP id 22mr58977845uav.16.1483741241006; Fri, 06 Jan 2017 14:20:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.131 with HTTP; Fri, 6 Jan 2017 14:20:20 -0800 (PST) In-Reply-To: References: From: Richard Gibson Date: Fri, 6 Jan 2017 17:20:20 -0500 Message-ID: To: dnsop@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05b0509c04f70545746d52 Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:20:44 -0000 --94eb2c05b0509c04f70545746d52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 6 Jan 2017 13:01:10 -0500, Robert Edmonds wrote: > It can be rev'd in the same document that introduces a DNS address RR > for that address family :-) > Why not use Address Family like EDNS Client Subnet ? But for that matter... On Fri, 6 Jan 2017 18:43:30 +0000, "Wessels, Duane" wrote: > It is of course quite similar to EDNS client subnet, except that there is > no masking and the client cannot opt-out. Might be worth saying in your > document why EDNS client subnet wouldn't work for this purpose. > Why *wouldn't* ECS work for this? If the idea is to expose everything obscured by a proxy (e.g., for backend logging), then the option data should include quite a bit more than an address=E2=80=94at minimum, a = protocol number f= or differentiating UDP/TCP, the original OPT CLASS (UDP payload size) and flags (including DO), and a flag indicating presence or absence of an OPT record in the original query. You might also want to include the port and id from the original query (for direct response) and/or allow arbitrary data after the address (for communicating installation-specific metadata). --94eb2c05b0509c04f70545746d52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, 6 Jan 2017 13:01:10 -0500, Robert Edmonds <edmonds@mycre.ws>=C2=A0wrote:
It can be rev'd in the same document that int= roduces a DNS address RR
for that address family :-)

Why not use= =C2=A0Address Family=C2=A0like=C2=A0EDNS Client Subnet? But for= that matter...

On Fri, 6 Jan 2017 18:43:30 +0000,= "Wessels, Duane" <dw= essels@verisign.com>=C2=A0wrote:
It is of course quite similar to EDNS client subnet, ex= cept that there is no masking and the client cannot opt-out.=C2=A0 Might be= worth saying in your document why EDNS client subnet wouldn't work for= this purpose.

Why wouldn't= =C2=A0ECS work for this? If the idea is to expose everything=C2=A0obscured = by a proxy (e.g., for backend logging), then the option data should include= quite a bit more than an address=E2=80=94at minimum, a protocol n= umber=C2=A0for differentiating UDP/TCP, the original OPT CLASS (UDP pay= load size) and flags (including DO), and a flag indicating presence or abse= nce of an OPT record in the original query. You might also want to include = the port and id from the original query (for direct response) and/or allow = arbitrary data after the address (for communicating installation-specific m= etadata).
--94eb2c05b0509c04f70545746d52-- From nobody Fri Jan 6 14:39: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 6E0181295FB for ; Fri, 6 Jan 2017 14:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 mz8Ahajgw5Y5 for ; Fri, 6 Jan 2017 14:39:00 -0800 (PST) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92732129631 for ; Fri, 6 Jan 2017 14:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=268; q=dns/txt; s=VRSN; t=1483742333; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=v7AAL3ujS/NFuUPrENngLrTaPPIAq6dO94atZPzsMsQ=; b=A4uwxZnTWO90xhQle5yY+tHlBjRvgCDmHcCgqtWnyCtZz8l5Z54VtXsR BvCTykMdBNUos23H5CCwu+eVdkV+SEPyL3s4fpQyPxv0I9yK6XcZVxY0u pREKxinUr7JfzBLWXP2MOhYKev4YIWnsD4sgzOuhF1ZI+1uFvwOCTyvX+ PUwb7+o7gDmexhs80aQmMLQcAbMvVFuGFJ1eo0hAkipw/isuSXbHunOpb XZ9vGzZ0FmCfoGuieoACVwEBQm+I2SXpkWTrbDMVlrQ+KtfbmNvF3bC3Q 0MG+P189xeMdKTwo/6GYiIMXY7RGv5DA1UbD74fZk8eJe0OPByYigaxOq A==; X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="1124356" IronPort-PHdr: =?us-ascii?q?9a23=3A/sg0Wh+Ooj0B4f9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?1OIcTK2v8tzYMVDF4r011RmSDNmdsasP0reJ+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFHiTanf79+MRq6oRjRu8QUnIBvNrs/xhzVr3VSZu?= =?us-ascii?q?9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnY?= =?us-ascii?q?UQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRQT2gy?= =?us-ascii?q?kbKTE27GDXitRxjK1FphKhuwd/yJPQbI2MKfZyYr/RcdYcSGFcXMheSjZBD5u8?= =?us-ascii?q?YYUREuQBIehWoYrzp1QMrBuxGQaiC+z0xz9Un3/22LE23/g9HQ3Y2gErAtIAsG?= =?us-ascii?q?7TrNXwLKoeX+C6w7fTzTXYcfxW3Sz95JDVeR4vvPGDR7RwftTfxUIyEA7Kk1uR?= =?us-ascii?q?ppL+PzOOyOsNt3Ob4vF+Ve2xkW4nqhpxojmgxscqkIXGmoUVylXd+Ch/3Y07Js?= =?us-ascii?q?W4RVZmbdK4CpdcqiOXOoVsTs8/Q2xltjw2xqMJtJO0ZCQG1YgrywTCZ/GFfYWE?= =?us-ascii?q?+A/vWeaPLTtii39ofq+0iQyo/ki60OL8U9G50FNNriVYjNbBrmsN1xnP6sifTf?= =?us-ascii?q?t941uh1S6P1w/N7uFEJlg5mrHBK54n37IwkpUSsUHZES/3nEX2i7KWdlk49uS1?= =?us-ascii?q?8ejnfKvppoWdN49viwH+PaIultajDuQ/NwgCR2mb+eKi273/5UD1XalGgucrnq?= =?us-ascii?q?Tbvp3WP9kXq663DgNPzIou5BmyAy+j0NsCnHkHKFxFeAiAj4jsI1zBPf75Aumk?= =?us-ascii?q?g1S3jjhrw+vGM6b/AprTNHjDkazhfbdy605a0gY80ddf55dMBrEbPP3zQlPxtM?= =?us-ascii?q?DfDhIhLgO0xf3nCNJl1o4FWGKAHLOZMK3IvV+P/OIvLPGGZJUJtzblN/gl+/nu?= =?us-ascii?q?gGcjmV8SfKmmxoAXaHe+Hvl9PkqYYXzsjs0dHmcNuwptBNDt3WeDWj5afXr6cK?= =?us-ascii?q?M2/TY9QNa8AobJXYerqLCQ2mGwGZgANU5cDVXZW0jlbJ6JX+xIIA6PK8ls2HRQ?= =?us-ascii?q?WaesUJQs0QqGqgLgyqFmIeyS8Sod48GwnONp7vHewElhvQd/CN6QhiTUFzl5?= X-IPAS-Result: =?us-ascii?q?A2G7AQDgG3BY//SZrQpeHAEBBAEBCgEBFwEBBAEBCgEBgw4?= =?us-ascii?q?BAQEBAYIKB41QkiKTF4IPggmGIgKCFRQBAQEBAQEBAQEBAQKBCIIzGgGCGgEBA?= =?us-ascii?q?QECATo/BQsCAQgNAQoeEDIlAgQOBYhoswOKIAEBAQEBAQEDAQEBAQEBAQEBAQE?= =?us-ascii?q?dhkaCAYJfhDAWgzWCMQWbDwYBkyUBjnuSUR+BdRVEAYYUc4dZgQ0BAQE?= Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v06Mcpts028235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 17:38:51 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Fri, 6 Jan 2017 17:38:50 -0500 From: "Wessels, Duane" To: Richard Gibson Thread-Topic: [EXTERNAL] Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9 Thread-Index: AQHSaGsmMflvKnngaUKHhntIeZtSuKEsXmqA Date: Fri, 6 Jan 2017 22:38:50 +0000 Message-ID: <58F88B75-DF1C-4C63-9A16-E1EB93D55B65@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <755CDA0ED55F8D49B613D024A9D122FE@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:39:03 -0000 > On Jan 6, 2017, at 2:20 PM, Richard Gibson wrote: >=20 > Why wouldn't ECS work for this?=20 I think because you might have a "backend" server that wants to know both t= he recursive server IP (XPF) and the stub client address (ECS). DW From nobody Fri Jan 6 14:50:31 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 E5B3C129637 for ; Fri, 6 Jan 2017 14:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 LEIq5Q1ifIjk for ; Fri, 6 Jan 2017 14:50:28 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9630129649 for ; Fri, 6 Jan 2017 14:50:26 -0800 (PST) Received: from [46.227.151.81] (port=53971 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cPdL3-0008V5-M5 (Exim 4.72) for dnsop@ietf.org (return-path ); Fri, 06 Jan 2017 22:50:21 +0000 To: dnsop@ietf.org References: From: Ray Bellis Message-ID: Date: Fri, 6 Jan 2017 22:51:02 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:50:30 -0000 On 06/01/2017 22:20, Richard Gibson wrote: > Why not use Address Family like EDNS Client Subnet Robert Edmonds and I already had that discussion off-list :) This option isn't intended to carry transport addresses that a DNS server couldn't already handle for itself. As it is, ECS only allows two possible values in its *16 bit* Family field, those being of course the values designating IPv4 and IPv6. If I'd been paying more attention to ECS I would have objected to this pointless over-specification. > Why /wouldn't/ ECS work for this? If the idea is to expose everything > obscured by a proxy (e.g., for backend logging), then the option data > should include quite a bit more than an address—at minimum, a > protocol number for differentiating UDP/TCP, the original OPT CLASS > (UDP payload size) and flags (including DO), and a flag indicating > presence or absence of an OPT record in the original query. You might > also want to include the port and id from the original query (for > direct response) and/or allow arbitrary data after the address (for > communicating installation-specific metadata). The intent isn't to expose *everything*. It's to expose specifically the one value that (most) servers care about because it's used by things like ACLs, and views, and rate limiting - the client source IP. kind regards, Ray From nobody Sat Jan 7 14:55:16 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 08950129412 for ; Sat, 7 Jan 2017 14:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 GlpNrXU_rRJG for ; Sat, 7 Jan 2017 14:55:13 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 4C18C126BF7 for ; Sat, 7 Jan 2017 14:55:13 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with SMTP id PztFcPURXRNZDPztIcHh1O; Sat, 07 Jan 2017 22:55:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483829712; bh=6O9e85AXWtlJRh/zVs/WbhkWx6VlU+b0diXHHpZyHV0=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=YFIjZwUEjR2sHSwPMw1K3AjaZOctVOHSYRFmH9CLzxOA/5xpDg++iJZCTEGT7QjOu hm/N4XGqWtmnUz8zDTNb/0waJIwA2/zimD9qi6Vgkj4B/cH9D5BhPDw5xb1jnlguGt LlaHGwm9eRd0P+DQti87rQ0HPBFgLL/3Yh2umh+XFiy56MgGSA64SeF2oMKThvsy6L NcvY6eUF3d+Z1SeyXKP6e0nFz/Qzq8EFPp76FNdkeLxbA8S8awehXrsgiE1KVTWr3a j9GglrdVV/CUo2fEwlc5e02TlwN47ILrthhhIJmG/AN8Xe06aVoNvmVO+I/bcMtlTH 0I+ZSaJ4JN9sQ== Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-12v.sys.comcast.net with SMTP id Pzt5cjUZ2WEg6Pzt9c8Gsj; Sat, 07 Jan 2017 22:55:10 +0000 Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id v07MsvsT000858; Sat, 7 Jan 2017 17:54:57 -0500 Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id v07Msujn000857; Sat, 7 Jan 2017 17:54:56 -0500 Date: Sat, 7 Jan 2017 17:54:56 -0500 From: Scott Schmit To: John Levine Message-ID: <20170107225456.GB10627@odin.ULTHAR.us> References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20161229163826.34758.qmail@ary.lan> User-Agent: Mutt/1.7.1 (2016-10-04) X-CMAE-Envelope: MS4wfA+l7zKQlfLv6qYlrsp/XMyD682AgOMhOQ7btUnbbSvb7B4Op/Roe2xspLfT8BUa82zUxLSv4+ksRxw5F+tXaJu8m7+JQxtshK5MEBy6CYFi1FpqL9rc xGLm2O6x3tywWd5+U8pnqyd68r3nm/ecFmXGepfixsHxphmih9Bu6I3C Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 22:55:15 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2016 at 04:38:26PM -0000, John Levine wrote: > >> Please see the previous gazillion messages from people who are using > >> RPZ in production to keep malware away from their users. > >>=20 > >> Also see the previous gazillion messages noting that governments do > >> all sorts of DNS censorship now and don't need RPZ. > >>=20 > >> Could you explain in more detail why you don't believe operators will > >> continue to use RPZ to protect their users, and why you think hostile > >> actors will do things with RPZ that they couldn't do now? > > > >I was specifically asking about the redirect/record replacement > >behavior, not the nxdomain/blocking behavior. >=20 > Providers routinely use sandboxing to quarantine infected users both > to protect their other users (malware can't contact C&C) and to force > them to do something about it, since they can't see anything other > than web sites with cleanup tools. =20 >=20 > I've talked to providers who tell me that this is the least bad way > they've found to get their users to clean up infected boxes. Even if > a provider could afford to calli them on the phone, it doesn't work, > first because users not unreasonably think it's a scam, and second > because the malware doesn't bother them, only other people, so they > blow off advice to fix it. Thanks for explaining the use case. > So I reiterate the same two questions. Ok. > >> Could you explain in more detail why you don't believe operators will > >> continue to use RPZ to protect their users I believe you that RPZ is well-intentioned, and I'm sure that operators already using RPZ will continue to do so until it stops working or a better method is available. Eventually, if DNSSEC verification on endpoints becomes widespread, operators will need to turn to other means or break DNSSEC in these cases (but redirection will stop working). > >> why you think hostile actors will do things with RPZ that they > >> couldn't do now? For the very reasons that the authors want to make this an RFC -- RPZ isn't interoperable between DNS resolvers today. Once this RFC is published, it's clearly hoped that RPZ will be more interoperable and thus widespread. It's true that countries can legislate anything they want, and the publication (or not) of an RFC won't change that. But the enforcement of laws costs resources, and resources are finite -- so a country passing laws requiring network operators to filter and/or redirect will have no choice but to prioritize enforcement of such laws against other needs. There are already plenty of examples of countries limiting their enforcement of laws in recognition of implementation/enforcement costs. (For an example, see Richard Clayton's message on Dec 29.) If the implementation of laws is expensive, enforcement will also be expensive. If implementation of the law is cheap, enforcement is also much more cheap, and such laws consequently become more attractive. Having laws that cannot be effectively enforced on the books is certainly possible, but I suspect countries avoid it to maintain their credibility. RPZ being interoperable would appear to make implementation of filtering/redirection laws extremely cheap. Previously, the government would need to make a list of blocks and/or redirections and distribute that list to network operators in some fashion. By default, this would probably be via some kind of document which would then need to be translated into vendor-specific block/redirect lists. This is slow and expensive. Then, to enforce that these lists are being used, officials of the government would need to go around and check that the lists are being used and kept up to date. To do better, the government would need to define some kind of standardized format and get its use implemented. This isn't cheap either. If RPZ becomes interoperable (it doesn't matter if it's "standard", interoperability is standard enough), the government can just mandate use of RPZ and maintain the block lists directly. They can monitor that ISPs are consulting the RPZ in real-time, so enforcement is trivial. (Yes, the ISPs can query the list without enforcing it, but (a) information about what blocked domains are being accessed is useful and (b) that's no harder to check for, so it's irrelevant to the trade-off). Rich and highly-motivated governments will probably operate the same before and after RPZ becomes interoperable (though operating costs could go down, freeing resources for other programs or better enforcement), but other countries will find it easier to implement blocking and/or redirection in their country, increasing the motivation to do so. The blocking behaviors of RPZ will increase the load on networking infrastructure if the blocked addresses are DNSSEC-signed and endpoints validate the signatures. The redirection behavior of RPZ breaks in the face of DNSSEC validation if the records are signed, so it would be in the interests of a country that really wants the redirects to break all DNSSEC. Then the end user faces a choice: no DNSSEC or no Internet. They could try to use VPNs, but RPZ makes them easy to block nationally once discovered as well as easier to find users attempting to use them. (And if they're accessed by IP, that's even easier to block.) Setting aside how governments may choose to use RPZ, there are security risks to RPZ's deployment. Without RPZ, malicious actors that want to effect large-scale redirection of users would need to seek out the recursive resolvers of their endpoints and subvert them all. With RPZ, they only need to find the comparatively fewer RPZ servers and subvert them instead. If the location of the RPZ server is advertised (for accountability and network diagnostic purposes), then these addresses become available for malicious actors to seek out and attack. The redirection capabilities of RPZ are especially interesting to malicious actors, as they can become a means to take over a competing botnet's C&C network or redirect users to malware. If the location of the RPZ servers is hidden, diagnosing network problems becomes much more difficult. This has the net effect of making the DNS less reliable. The widespread use of captive portals has already made implementation of endpoint DNSSEC validation difficult and has essentially inhibited its implementation. I believe that widespread use of RPZ could do the same. All the above leads me to believe that RPZ is harmful to Internet security and infrastructure, however well-intentioned it may be. I do not support adoption of this draft. --=20 Scott Schmit --pf9I7BMVVzbSWLtt Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIINuQYJKoZIhvcNAQcCoIINqjCCDaYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggrhMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkqhkiG9w0BAQsFADB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xp ZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tf rh4bdcC1Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR +8eklf/EqeZWRLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I706 2uHsskM8b7gPxmcCoO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo1 2SLBO5tbk8h2imbKTC8iMs+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aM svi2raFhC643SOGvErWWPPnSEfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEG MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIG A1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggr BgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggr BgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQW BBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu 8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGLhK0PAQJbnOEjJyMEvTTw cAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm7NKezWVnCHuwb3pt gFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAIhV4L8aaya1u4 s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1stp+C7omqM 5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8wBUa BxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe 3X+rn0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvS odfiar0wiM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqm RHYj1TjMSw0lAl7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK 7zmjozCCBPcwggPfoAMCAQICEGPKwxkQcAfNHxuyTp+gD8wwDQYJKoZIhvcNAQELBQAwdTEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENs aWVudCBDQTAeFw0xNjA1MjEwMDE3MDlaFw0xOTA4MjEwMDE3MDlaMEAxGzAZBgNVBAMMEmku Z3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9rQGNvbWNhc3QubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoYYlhqtcVPaI5BU1UTWTzpRI/w2jkAq5 KGx4m8a0hYOeT/rO1IiFU8QqEg+17ygK2i5eFAk6Vbe54hXC8hfEP8a3JjCcNhPURA0HsTiH 31DAgZv50G8BYQMubml9FMHV+inthbwyWfrDIADM6AuOaqhohZnHb2vL2h4VgJHh9dnh0MQr DjJXcTaE4k6+VRrEaDW00V4saSYzjlLedrw9F9m2hntYE9dP9Eqros5r5XYv2WRlJMsKSfBy k2hrMIeCX6fkXvs5lw8FjdW/6GZlG+VyckAHwtyig92kLWj5GGb+PsSkFR9lHZ6d4SqRtGnr X5i5c7+yO1EeFdWTulQSCwIDAQABo4IBtjCCAbIwDgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBSeE/ViLQNUr8n+ O2ZP3xm3TmFVPjAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcB AQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcw AoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1Ud HwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAd BgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMEcGA1UdIARAMD4wPAYLKwYBBAGBtTcBAgUwLTArBggrBgEFBQcCARYf aHR0cHM6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEABj7z gikcowksyBx01urOlbVzBQYEuDTVaTmARQeIsQEkbvorJQ3Pna+38UL2tMoNoIYpGGo+9OwS 13knWprlYPHDD/4XYoPCsnPRHTfQItYeUTcWvG48YykD8XE9OLEhTY2P5yv0blumxyDPuRnD kyeWsoFoDVUo4miLAaY4nuos9oYRd0Kqznt88UmbwDQc4Id3uGf83nJCPmyZfd07enMVCyL/ uC8ThSHxBuK1lag1hQTFlBI8LsWF/+ZMQtUxTkmNxy3gIAYL/vOnsJTx+HV6Wa7V0ZxYbjzq jR1oIkJRye/G8LUykc7/uF8KYS1CRlts+9BeP98xXOGOrc6EezGCApwwggKYAgEBMIGJMHUx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBD bGllbnQgQ0ECEGPKwxkQcAfNHxuyTp+gD8wwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTA3MjI1NDU2WjAvBgkqhkiG 9w0BCQQxIgQgP1X9uLTsenIoFOZrEp1nPmc4mx/wfDRyToXgH0ONCkEweQYJKoZIhvcNAQkP MWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEARQQo+zxKd112fyDuY2mnHtBQNud9512Xy6iGqvO/4jV8 Sy/aQAbpbWDXjURr4PLzEC7Ef8zH4DDMoiIoEGuEr7SC44kUeiIKyqQUhXjpOZBTpaFi9dvf wUmMS2Cjslqd8RqwpwMZtG0iORkXbwEetKFEq05SGbDQPVRqQ8nSxeM6qzJD/mg2QSU1k+F1 D/RqnHtAtKi2u9q39Twahke7tBzyfHgZt6VyqIHSV5CAHjEMl3h6QgkJREfxc0WfymSwYQ0D s48REdkTG/6yP4GWq+ulu+kPZgPH6+bOmWjxodYeIrjQ1fl8EBWxw1idrja89OyUu46eTj42 9s/bER22FA== --pf9I7BMVVzbSWLtt-- From nobody Sun Jan 8 12:26: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 F145D129411 for ; Sun, 8 Jan 2017 12:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.445 X-Spam-Level: * X-Spam-Status: No, score=1.445 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5eQnX7RBk4OP for ; Sun, 8 Jan 2017 12:26:36 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D521296A9 for ; Sun, 8 Jan 2017 12:26:35 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id E3CE412BA13 for ; Sun, 8 Jan 2017 20:26:32 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:355:379:599:800:854:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1534:1541:1593:1594:1683:1711:1730:1747:1777:1792:2393:2525:2553:2565:2682:2685:2692:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4425:4860:5007:6119:7652:7903:8660:8985:9010:9025:10004:10400:10848:11232:11658:11914:12043:12050:12109:12291:12379:12438:12683:12740:12760:12895:13019:13069:13071:13146:13148:13149:13230:13311:13357:13846:13891:14096:14097:14180:14181:14721:14764:14777:14819:21060:21063:21080:21212:21366:21433:21451:30022:30029:30054:30060:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none X-HE-Tag: blow11_1bfa561c3df63 X-Filterd-Recvd-Size: 2689 Received: from [127.0.0.1] (unknown [23.82.54.75]) (Authenticated sender: avri@doria.org) by omf10.hostedemail.com (Postfix) with ESMTPA for ; Sun, 8 Jan 2017 20:26:32 +0000 (UTC) References: To: dnsop@ietf.org From: Avri Doria Organization: Technicalities Message-ID: <4ebfa099-c621-4fdf-db56-05b9e27c4d58@acm.org> Date: Sun, 8 Jan 2017 15:26:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170102-0, 01/02/2017), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: avri@acm.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:26:38 -0000 Hi, Finally had a chance to read all of it. While I understand that it can be used to create enclaves, I think it can also be used in useful ways to increase the flexibility of the DNS system, e.g. for example possibly to avoid some of the problems we see from occasional name collision. I would very much like to see it well documented. And if it is politically too difficult to standardize, informational is good enough. avri On 20-Dec-16 10:16, tjw ietf wrote: > Why not just wade into this discussion... > > The draft is being present as "Informational", and the point here is > to document current working behavior in the DNS (for the past several > years). It is obvious that some feel this draft is a large mistake, > but like edns-client-subnet, more operators are deploying this than > one is aware of. > > This starts a Call for Adoption for draft-vixie-dns-rpz > > The draft is available here: > https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/ > > 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. > > With the holiday period upon us, we'll make this a three week call for > adoption. This call for adoption ends on 10 January 2017 > > Thanks, > tim wicinski > DNSOP co-chair > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- avri@ella.com is going out of use in the near future. Please switch to avri@acm.org --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Sun Jan 8 19:35:15 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 736471296F6 for ; Sun, 8 Jan 2017 19:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156] 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 0ugb_26M4Bz9 for ; Sun, 8 Jan 2017 19:35:14 -0800 (PST) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (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 6DD3C129488 for ; Sun, 8 Jan 2017 19:35:14 -0800 (PST) Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B520B53A2; Sun, 8 Jan 2017 22:35:08 -0500 (EST) X-Auth-ID: bgreene@senki.org Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id AD31E5046; Sun, 8 Jan 2017 22:35:07 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from sin-mpgjx.singapore.corp.akamai.com ([UNAVAILABLE]. [23.62.225.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sun, 08 Jan 2017 22:35:08 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_23DC8CB7-4E6F-4B24-8208-8440B63C5F44"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Barry Raveendran Greene In-Reply-To: <20170107225456.GB10627@odin.ULTHAR.us> Date: Mon, 9 Jan 2017 11:34:57 +0800 Message-Id: <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> To: Scott Schmit X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnsop@ietf.org, John Levine Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 03:35:15 -0000 --Apple-Mail=_23DC8CB7-4E6F-4B24-8208-8440B63C5F44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 8, 2017, at 6:54 AM, Scott Schmit wrote: >=20 > Eventually, if DNSSEC verification on endpoints becomes widespread, > operators will need to turn to other means or break DNSSEC in these > cases (but redirection will stop working). Bad guys are not going to take the time to use DNSSEC to build a path = that can be followed to their place of operations. So the argument that =E2=80=9CDNSSEC deployment will obsolete the = industry need for RPZ=E2=80=9D does not match reality. --Apple-Mail=_23DC8CB7-4E6F-4B24-8208-8440B63C5F44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYcwTpAAoJEFVuk3AWv0XzqLkH/2PdVAuilujVrLqRq2vMQ+bK 8GaK9BPB59nZmqG/Qk9r6TuiKO6wgCkFirSL+AuQJgJHj9xed57kCbp2uXPYZi7S QfaEN32JsftbQ7TKuVFsHN/vGPsi3oZc0uf/tJVRer/XeFIgkP+hvlkn3N2XGSfy w27/QPdk4CSgytbOQZCck3eFITTpUh8YY+E1TFewjs8D8WqV+zCKAPnkPCf5aGo+ 6NVUr3ZMO0t+kagUl9TVrGR9Zv50092M0vYqHXTPOr/i2wnJGs9h3RM/w/hjoEoX /yS6XOTfT8bX7fYkyiarK56w6O46hWU1bh+IrPs04v3IrAkXViVjM3p+aa/dGmE= =vlt0 -----END PGP SIGNATURE----- --Apple-Mail=_23DC8CB7-4E6F-4B24-8208-8440B63C5F44-- From nobody Sun Jan 8 20:49: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 C6CBE1294B5 for ; Sun, 8 Jan 2017 20:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 CntYAJCuu4T9 for ; Sun, 8 Jan 2017 20:49:29 -0800 (PST) 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 813CB129440 for ; Sun, 8 Jan 2017 20:49:27 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3txjNy5jx1z1rr; Mon, 9 Jan 2017 05:49:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483937362; bh=Q4qTZchw/7mKWwLEdC6VsxaPeDxLdJ6tbKpwNdXUIvA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VtfJU+H34g8Df1BFSopj6D4kmLX8/78JR7eBXM4z01NBWhuerod2QzHpn0JG1to44 Zx5/9iK2gSKuMDcYQbACGDuFTzEoksA6c7JZzgOXE37+EijOdlnnc8ObSW9OlXg4BL SwUwZC3Ih7ozUNRvNqz5OLEeIbtUMK9FcchVwIY0= 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 TMScBW0vY9UQ; Mon, 9 Jan 2017 05:49:21 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 9 Jan 2017 05:49:21 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1FDA6CA34B6; Sun, 8 Jan 2017 23:49:18 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 1FDA6CA34B6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 045A940D7281; Sun, 8 Jan 2017 23:49:17 -0500 (EST) Date: Sun, 8 Jan 2017 23:49:17 -0500 (EST) From: Paul Wouters To: Barry Raveendran Greene In-Reply-To: <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> Message-ID: References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 04:49:31 -0000 On Mon, 9 Jan 2017, Barry Raveendran Greene wrote: >> On Jan 8, 2017, at 6:54 AM, Scott Schmit wrote: >> >> Eventually, if DNSSEC verification on endpoints becomes widespread, >> operators will need to turn to other means or break DNSSEC in these >> cases (but redirection will stop working). > > Bad guys are not going to take the time to use DNSSEC to build a path that can be followed to their place of operations. It is actually the other way around. If an end-node performs DNSSEC validation, it can only see RPZ modified answers as an attack. It is in the interest of RPZ to give such clients the confidence that the RPZ produced answer is not an attack but a handbreak action in the user's interest. I won't re-iterate my previous suggestion on how this could be done. See the archive. Paul From nobody Mon Jan 9 04:43: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 8DAEB129C5D for ; Mon, 9 Jan 2017 04:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 5dg6qp5iLIaf for ; Mon, 9 Jan 2017 04:43:05 -0800 (PST) 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 4B205129C62 for ; Mon, 9 Jan 2017 04:43:05 -0800 (PST) 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 E9F4E34930F for ; Mon, 9 Jan 2017 12:43:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DE02D160047 for ; Mon, 9 Jan 2017 12:43:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CBE9C160054 for ; Mon, 9 Jan 2017 12:43:02 +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 OW4OT2q_HA9e for ; Mon, 9 Jan 2017 12:43:02 +0000 (UTC) Received: from rays-mbp-2.local (unknown [46.227.151.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 6B112160047 for ; Mon, 9 Jan 2017 12:43:02 +0000 (UTC) References: <148396571329.24904.14128382959913441373.idtracker@ietfa.amsl.com> To: dnsop From: Ray Bellis X-Forwarded-Message-Id: <148396571329.24904.14128382959913441373.idtracker@ietfa.amsl.com> Message-ID: <484ebc0c-7286-3c80-564c-bf816600c4a4@isc.org> Date: Mon, 9 Jan 2017 12:43:40 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148396571329.24904.14128382959913441373.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:43:06 -0000 I've submitted a -01 revision to address most of the feedback received so far. Ray -------- Forwarded Message -------- Subject: New Version Notification for draft-bellis-dnsop-xpf-01.txt Date: Mon, 09 Jan 2017 04:41:53 -0800 From: internet-drafts@ietf.org To: Ray Bellis A new version of I-D, draft-bellis-dnsop-xpf-01.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsop-xpf Revision: 01 Title: EDNS X-Proxied-For Document date: 2017-01-09 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-01.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-xpf-01 From nobody Mon Jan 9 06:19: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 60253129CDC for ; Mon, 9 Jan 2017 06:19:43 -0800 (PST) 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, 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=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 vBtjPXMSfffv for ; Mon, 9 Jan 2017 06:19:42 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 09825129504 for ; Mon, 9 Jan 2017 06:19:42 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so70604594qtc.2 for ; Mon, 09 Jan 2017 06:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kDuMtucPTWzz8Yh51mMTzwfvd/wTeuIUPaKQca4yCuM=; b=uNcTz/qWhJV0KpVVNfiqBxEe0SoNw+ycht5KaeT20b9rh7xeKFobeUIHMC0bAcbnzT bQiuS8HpMxhHZcp5jblgr183nB0h6qOdPOfZs0Ai8+XI2HC0R8ix4oQ79L4Jaapmz9mq ym1/DJHH42DVbi8AG4l6eqXX8RWI2ExTttzWIKeF1pN9vHdG/bdKEg1Exo9cOQTj5vz/ N41yG2+fa4WwNW2jL0sFM2s/hkuCyTHdn/ld3lMHea29LLIo2U56pHTD/8kmRfOOU9cn eQYbGSUq0yEF6fllMYDki+5pdi3H+0S3n4hYZXyFCPVvme8Eq5Dd6Zbts8NwC1ENZocJ 553A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kDuMtucPTWzz8Yh51mMTzwfvd/wTeuIUPaKQca4yCuM=; b=KapwvyT4aKO50d16g0o4qzNnjVAxLH03GszjyJeEq3JJLO6HxpLnvLSSiHOO4zHRkh 77dO/BE42Z2JVGGMvfNn9AgBbFGmRE5Ea18H/I0zI4md+0TkPfB+lNeRKSSUDcE7oFX0 JefeNfGfsGUcVIpprjvyBjcIxPGOwD5cZ8Ak8DSBv2fbiV8miZBwVtwq3pMVceYLfmmT sNYfv36gCXLF9SMVKq1eZiTq+AVR+CLlm5r7dk1fs93uLmBSMclfMBOSfcFRd6avd7TE FwS/56CiosmR1JOChnr6RGrs19aV8euAIgeNJ3qww/xfo4HevEksaq6K1TOXT+jeky4i yr0Q== X-Gm-Message-State: AIkVDXL0Vt6h3VTRm+h1lS10xpEW66wVho36fG5Sywj5B7sET+TGm4YbV/eaWxbxNFnzZw== X-Received: by 10.200.37.241 with SMTP id f46mr82040020qtf.164.1483971581132; Mon, 09 Jan 2017 06:19:41 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i125sm434316qkf.24.2017.01.09.06.19.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 06:19:39 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_35AC6C55-3172-4B4A-8765-440030C0AB1F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 9 Jan 2017 09:19:37 -0500 In-Reply-To: To: Paul Wouters References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop , Barry Raveendran Greene Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:19:43 -0000 --Apple-Mail=_35AC6C55-3172-4B4A-8765-440030C0AB1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 8, 2017, at 11:49 PM, Paul Wouters wrote: > It is actually the other way around. If an end-node performs DNSSEC > validation, it can only see RPZ modified answers as an attack. It is > in the interest of RPZ to give such clients the confidence that the = RPZ > produced answer is not an attack but a handbreak action in the user's > interest. I think you missed what Barry was saying: you are correct that an = end-node that performs DNSSEC validation will see RPZ on a domain that = is signed as an attack. The point Barry is making is that this only = matters if they sign their zones, and they won't, because doing so = produces a clear audit trail leading back to them. I think this is actually not true: why is a DS record any more of an = audit train than an NS record? Nevertheless, let's be clear on what = RPZ does and does not do. I think the main reason attackers won't sign = is that it's too much trouble, and provides no real benefit in the = presence of an effective RPZ block. Your point here, that in order for RPZ to function in the presence of = widespread DNSSEC signing, there has to be some mechanism for = authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly true. = It may be perfectly functional for RPZ answers to look like an attack. = But it's certainly worth considering, and has been talked about earlier = in this thread. The question is, does it make sense to add code to the = validating resolver to detect and validate an RPZ block, so the user can = be informed that a block occurred, and who did it? Would people = actually code this up? Would it be better or worse? To me it seems like a bad idea: it's a larger attack surface, more = complexity, a single point of attack: if I can compromise the RPZ keys, = I can make an attack look like protection to the end user. Ultimately, = if we were to specify a solution for this, I think we doul actually be = doing something harmful to human rights. Isn't blocking the domain = enough? --Apple-Mail=_35AC6C55-3172-4B4A-8765-440030C0AB1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 8, 2017, at 11:49 PM, Paul Wouters <paul@nohats.ca> = wrote:
It is actually the other way around. If an = end-node performs DNSSEC
validation, it can only see RPZ modified = answers as an attack. It is
in the interest of RPZ to give = such clients the confidence that the RPZ
produced answer is not an attack = but a handbreak action in the user's
interest.

I think you missed what Barry was saying: you are correct = that an end-node that performs DNSSEC validation will see RPZ on a = domain that is signed as an attack.   The point Barry is making is = that this only matters if they sign their zones, and they won't, because = doing so produces a clear audit trail leading back to them.

I think this is actually = not true: why is a DS record any more of an audit train than an NS = record?   Nevertheless, let's be clear on what RPZ does and does = not do.   I think the main reason attackers won't sign is that it's = too much trouble, and provides no real benefit in the presence of an = effective RPZ block.

Your point here, that in order for RPZ to function in the = presence of widespread DNSSEC signing, there has to be some mechanism = for authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly = true.   It may be perfectly functional for RPZ answers to look like = an attack.   But it's certainly worth considering, and has been = talked about earlier in this thread.   The question is, does it = make sense to add code to the validating resolver to detect and validate = an RPZ block, so the user can be informed that a block occurred, and who = did it?   Would people actually code this up?   Would it be = better or worse?

To me it seems like a bad idea: it's a larger attack surface, = more complexity, a single point of attack: if I can compromise the RPZ = keys, I can make an attack look like protection to the end user.   = Ultimately, if we were to specify a solution for this, I think we doul = actually be doing something harmful to human rights.   Isn't = blocking the domain enough?

= --Apple-Mail=_35AC6C55-3172-4B4A-8765-440030C0AB1F-- From nobody Mon Jan 9 07:14: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 E3382128AB0 for ; Mon, 9 Jan 2017 07:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 Pnqc-ELAe1aH for ; Mon, 9 Jan 2017 07:14:36 -0800 (PST) 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 BEDCE129408 for ; Mon, 9 Jan 2017 07:14:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3txzGJ4qD8z1rr; Mon, 9 Jan 2017 16:14:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483974872; bh=fh2FsSV8HMe33vvelA61Fd8IfTcf+zKnBOkG+v0dlxE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=f+waof7/KyOs2gXRv2arrIFW/mbv9+P2VjTN4wOs7hoSsmAMoIwrARHgPdAJzR2YO 3UtfHU61FpE3zkpQsJlPY+Om4ughL/Foek1xQm3DSs8On6IOG0N/zIEAKvKR8wTq7E PzZpFbk1G/FA9hVubPT840AezNpOJBQ6NokQaqnM= 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 895oBbWXYSWq; Mon, 9 Jan 2017 16:14:31 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 9 Jan 2017 16:14:30 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B4CE6CA34C7; Mon, 9 Jan 2017 10:14:27 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B4CE6CA34C7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9E5A540D7281; Mon, 9 Jan 2017 10:14:27 -0500 (EST) Date: Mon, 9 Jan 2017 10:14:27 -0500 (EST) From: Paul Wouters To: Ted Lemon In-Reply-To: Message-ID: References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dnsop , Barry Raveendran Greene Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:14:38 -0000 On Mon, 9 Jan 2017, Ted Lemon wrote: > On Jan 8, 2017, at 11:49 PM, Paul Wouters wrote: > It is actually the other way around. If an end-node performs DNSSEC > validation, it can only see RPZ modified answers as an attack. It is > in the interest of RPZ to give such clients the confidence that the RPZ > produced answer is not an attack but a handbreak action in the user's > interest. > > > I think you missed what Barry was saying: you are correct that an end-node that performs DNSSEC validation will see RPZ on a domain that is signed as an attack.   The point Barry is making is that this only > matters if they sign their zones, and they won't, because doing so produces a clear audit trail leading back to them. Apple is getting ready to drop port 80 support. unsigned/unencrypted transports are dying. I hope we are moving to a word where DNS without DNSSEC will also be seen as bad. So yes, I am assuming in the future, attackers will have to sign DNS and that domains without DNSSEC are seen as "rogue domains that don't have clear audit trails". > I think this is actually not true: why is a DS record any more of an audit train than an NS record? Because it proves ownership of the domain. My nohats.ca DS record cannot be modified by the UK ISPs forced to filter my domain. But they can spoof NS records. See the recent discovery that Heathrow Airport runs a MITM TLS server on torproject.org. Do we want them to run RPZ where they can disappear torproject.org alltogether? No. Do we want them to run RPZ to prevent travelers from getting malware installed? Yes. >   Nevertheless, let's be clear on what RPZ does and does not do.   I think the main reason attackers won't > sign is that it's too much trouble, and provides no real benefit in the presence of an effective RPZ block. It's fine for "attackers" not to sign domains. That is not the point. > Your point here, that in order for RPZ to function in the presence of widespread DNSSEC signing, there has to be some mechanism for authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It > may be perfectly functional for RPZ answers to look like an attack.   But it's certainly worth considering, and has been talked about earlier in this thread.   The question is, does it make sense to add code > to the validating resolver to detect and validate an RPZ block, so the user can be informed that a block occurred, and who did it?   Would people actually code this up?   Would it be better or worse? To me that is quite obvious "yes". If we allow the DNS protocol to randomly rewrite DNS, then why _do_ we have DNSSEC? > To me it seems like a bad idea: it's a larger attack surface, more complexity, a single point of attack: if I can compromise the RPZ keys, I can make an attack look like protection to the end user.   Excellent! It means if the RPZ/DNS provider screws up, they are accountable. And they will properly maintain such systems that are golden opportunity for hackers to compromise. Also, the danger you are describing "I can make an attack look like protection to the end user" is exactly what the current RPZ spec already allows! I guess you really meant to say "a compromised RPZ system can unblock a malicious and previously blocked side". Well yes. You are describing a weakness, not a strength, of the RPZ solution. > Ultimately, if we were to specify a solution for this, I think we doul actually be doing something harmful to human rights.   Isn't blocking the domain enough? Just blocking the domain is "too much". And in my view that _is_ the human rights issue. If we change this discussion and replace DNS and DNSSEC with BGP and RPKI, would you still think it is fine to allow random parties to change BGP announcements in a world of secure BGP so that users can be prevented to go to certain IP ranges? Paul From nobody Mon Jan 9 07:49: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 8DFE9129D96 for ; Mon, 9 Jan 2017 07:49:00 -0800 (PST) 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 OKpxPzRtyu9t for ; Mon, 9 Jan 2017 07:48:59 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 DD241129D91 for ; Mon, 9 Jan 2017 07:48:58 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id x49so73163061qtc.2 for ; Mon, 09 Jan 2017 07:48:58 -0800 (PST) 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=sRIZdwG2khASqHrFVoVAucL6dkJTG7WAxClc4YNwPOo=; b=j+TCYpwCzIQCga0cdllrJMkG+UfCldSiT134shiUJ/+KU9FW/sIbZvJshaVoqj+T22 bJT0dVGx/Q7rtAd9et/UYXXHWwPsS60S20WrZZCR0qejbUSQJrBClt/wgUN4xz7dfqAt XIXxbUSrSiCzOuHzhH2XXCKPD2IolxxP4pOVLrbIKJP/gTQDh97Un8EgGMbw09JYndSa RuBEwOEEanXdYxl/yZm0CIop7mDmQv30qqfeo2TMLkmc6FaBBuILeHozhQnCX58FvzHj Uw/7jHMhSVK64es9DPAU6oXB3kNbi9BykvbwI+h9NVNTKwKDUsC99mocyp/SM3noB8oG slcw== 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=sRIZdwG2khASqHrFVoVAucL6dkJTG7WAxClc4YNwPOo=; b=pDcLwZy7CUB4s2VjEO+XOUwjW/RNDRgw/RQwBYOON8AMRwUmJVoUsqyTJIzn0y26bd o285bTllEyi0Dz9DKLK31eJryntu5S4jI5rpglZYupTvAFDrXU0+Nj7qJKVtpAPFAn0W Rh0hbhRPa6VMaEH7xVAsRTJpHw1JU4JjftAy6otL4cmPtSvhFKhN7WuWjgbYFq4oyDuh Ubm22j145VHr4EVUWsL3Jbexj3jf4KkslI2DsCj4miqvHTbAvZCFZXSB0cSjMFfWk1WG rhZvboQbPvA3wpYSZ4taRj+c2FMVbWYk2F4+r9H/BMjp5LilNGkZayoMZIYRurGfw+U8 1RAg== X-Gm-Message-State: AIkVDXL3/bmyP4ZPq7PFncynCpDCYtCrhGJ+BQ7UMlwPT3z7RAOd4g3HjCNFbHTPX6xmGw== X-Received: by 10.200.55.37 with SMTP id o34mr22584411qtb.48.1483976937887; Mon, 09 Jan 2017 07:48:57 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id w138sm1281995qka.27.2017.01.09.07.48.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 07:48:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: Date: Mon, 9 Jan 2017 10:48:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4634DCAB-0BA3-4B21-B3F9-C66F81CE50A9@fugue.com> References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> To: Paul Wouters X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop , Barry Raveendran Greene Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:49:00 -0000 On Jan 9, 2017, at 10:14 AM, Paul Wouters wrote: > Apple is getting ready to drop port 80 support. unsigned/unencrypted > transports are dying. I hope we are moving to a word where DNS without > DNSSEC will also be seen as bad. So yes, I am assuming in the future, > attackers will have to sign DNS and that domains without DNSSEC are = seen > as "rogue domains that don't have clear audit trails". It remains the case that most service providers at present appear to = believe that PKI is enough, and they don't think DNSSEC is worth the = trouble. Like you, I look forward to the day when this is no longer = true, although I don't look forward to the attack that changes peoples' = minds about this. >> I think this is actually not true: why is a DS record any more of an = audit train than an NS record? >=20 > Because it proves ownership of the domain. My nohats.ca DS record = cannot > be modified by the UK ISPs forced to filter my domain. But they can > spoof NS records. See the recent discovery that Heathrow Airport runs = a > MITM TLS server on torproject.org. Do we want them to run RPZ where = they > can disappear torproject.org alltogether? No. Do we want them to run = RPZ > to prevent travelers from getting malware installed? Yes. We are talking at cross purposes. We agree that the DS record proves = ownership of the zone. But it doesn't provide any more of an audit = trail in terms of zone setup than does an NS record. In terms of = accurately identifying who set up the zone, it is completely useless. >> Your point here, that in order for RPZ to function in the presence of = widespread DNSSEC signing, there has to be some mechanism for = authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly true. = It >> may be perfectly functional for RPZ answers to look like an attack. = But it's certainly worth considering, and has been talked about earlier = in this thread. The question is, does it make sense to add code >> to the validating resolver to detect and validate an RPZ block, so = the user can be informed that a block occurred, and who did it? Would = people actually code this up? Would it be better or worse? >=20 > To me that is quite obvious "yes". If we allow the DNS protocol to > randomly rewrite DNS, then why _do_ we have DNSSEC? Again, not the point I was making. Of course we want the resolver to = do validation. The question is, do we want the resolver to have code = in it to validate who did the RPZ block. I think this would be a = really bad idea, and would be seriously damaging to human rights. > Excellent! It means if the RPZ/DNS provider screws up, they are > accountable. And they will properly maintain such systems that > are golden opportunity for hackers to compromise. Also, the > danger you are describing "I can make an attack look like protection = to > the end user" is exactly what the current RPZ spec already allows! > I guess you really meant to say "a compromised RPZ system can unblock > a malicious and previously blocked side". Well yes. You are describing > a weakness, not a strength, of the RPZ solution. You are thinking like a IETF geek. The average end user will know = nothing of this. To them, it will simply be the case that their = computer says "this is a malware site." They will not see the audit = trail. It doesn't matter if the ACLU can detect the attack: they could = have detected the attack without the signature, and most likely had a = clear idea of who did it. What matters is that we have no provided a way for malicious site = operators to lie to end users, who will not be able to detect the lie. = To be clear, the lie is "I am authorized to block zones on your behalf." > Just blocking the domain is "too much". And in my view that _is_ the > human rights issue. We disagree here. I have seen way too many people screwed over by = malware to think that preserving a perfect uncensored view of the DNS is = more important than blocking malware. As long as we can tell that we = have been given a filtered response, I think we have the best possible = compromise, and if sites are not willing to put in the effort to sign = their zones, that is their problem. > If we change this discussion and replace DNS and DNSSEC with BGP and > RPKI, would you still think it is fine to allow random parties to > change BGP announcements in a world of secure BGP so that users can > be prevented to go to certain IP ranges? If that IP range is being operated by a malware site or for example is = going to redirect all of my traffic through a country that is sniffing = my packets for intelligence purposes, then yes, it should be possible = for the infrastructure to prevent the broken route from being installed, = regardless of whether or not it has been signed. This is the = distinction between authentication and authorization that we all know so = well: just because something is _authentic_ does not mean that it is = authorized. Taking that very clear distinction and turning it political is not = helping anyone. From nobody Mon Jan 9 07:51: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 B6675129541; Mon, 9 Jan 2017 07:50:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148397705774.24976.10332156432214745376.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 07:50:57 -0800 Archived-At: Cc: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-maintain-ds@ietf.org, The IESG , joelja@gmail.com, rfc-editor@rfc-editor.org Subject: [DNSOP] Protocol Action: 'Managing DS records from parent via CDS/CDNSKEY' to Proposed Standard (draft-ietf-dnsop-maintain-ds-04.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:50:58 -0000 The IESG has approved the following document: - 'Managing DS records from parent via CDS/CDNSKEY' (draft-ietf-dnsop-maintain-ds-04.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ Technical Summary This document describes an in-band method for introducing and removing the Initial DNSSEC trust anchor between a parent and a child domain. This is done by using the CDS/CDNSKEY DNS RR Types introduced in RFC7344. The document also attempts to produce reasonable initial acceptance policy. This work is extending the work done in RFC7344, which was published as an Information document. Time and experience has given the working group insight that the use and deployment of the CDS/CDNSKEY are useful in DNSSEC adoption. Therefore, with the publication of this document, the previous document should be elevated to Standards Track. Working Group Summary This working group was very supportive of this document, and discussion was centered around assisting the adoption of DNSSEC, but also the management of the DS Records. There was many constructive comments on the draft that have all been addressed. The consensus was broad across the working group and the authors addressed all issues raised. Document Quality To be addressed in the interregnum, from the Genart review. This document intends to move RFC7344 from Informational to PS in place (without republishing RFC7344. The intent to do so is buried at the end of the document (the abstract doesn't mention it). The Last Call for the document does not make it clear that _this_ document is elevating RFC7344. (It at least mentions it, which is good, but the writeup about the elevation can be read to say "we're considering this elevation somewhere else, keep it in mind while evaluating this document"). There is no hint from the subject line that this is a call to bring RFC7344 onto the standards track. Unless there is some other communication effort that I've missed on a quick search, I think it is very likely that most of the IETF community outside the dnsop working group missed this intent. I strongly encourge a last call focusing _specifically_ on moving RFC7344 to the standards track without republication. My personal feedback on elevating RFC7344 without republishing is that it's not the right thing to do. At the very least "Category: Informational" appears in the document itself, and that will not change. If the IESG decides to proceed with this as currently formulated, count me in the deep rough. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli From nobody Mon Jan 9 07:52: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 3BB70129541 for ; Mon, 9 Jan 2017 07:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-3.199, 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 wcPHfsj9SvyQ for ; Mon, 9 Jan 2017 07:51:57 -0800 (PST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 30E29129DA0 for ; Mon, 9 Jan 2017 07:51:48 -0800 (PST) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v09FpVdW091632 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Mon, 9 Jan 2017 15:51:31 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v09FpVif091631 for dnsop@ietf.org; Mon, 9 Jan 2017 15:51:31 GMT Date: Mon, 9 Jan 2017 15:51:31 GMT From: Vernon Schryver Message-Id: <201701091551.v09FpVif091631@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:51:58 -0000 > From: Ted Lemon > I think the main reason attackers won't sign = > is that it's too much trouble, and provides no real benefit in the = > presence of an effective RPZ block. Yes, but there is a reason more important than RPZ for miscreants to sign their attacks. It is the same reason that plenty of spam is sent with valid STARTTLS, DKIM, and/or SPF signatures and why spammers were the first significant SPF publishers. A large fraction of their targets support the silly notion that authenticated strangers differ from other strangers and that a certificate of authentication from a third party is a bankable guarantee of virtue. > The question is, does it make sense to add code to the = > validating resolver to detect and validate an RPZ block, so the user can = > be informed that a block occurred, and who did it? Would people = > actually code this up? That's the rub. RPZ has multiple independent interoperating implementations, is widely deployed, and is in common use because the customers of DNS recursive server implementators initially welcomed it and now demand it. Those customers are operators of DNS resolvers, especially large operators who pay real money (as opposed to hot air) for DNS server code, hire people to operate it, pay the secondary bandwidth, training, bug and other costs, and pay for RPZ blacklists. Where is the equivalent demand among resolver operators for doubling the size of DNSSEC responses to contain both the original and the RPZ rewritten rrsets including RRSIGs, and to pay the implied costs in bugs, CPU cycles, bandwidth, training, security, etc? People pay money for code implementing what the draft describes, but as Ted Lemon asks, who would pay for the suggested code in resolvers? If it were free, who would pay the costs of turning it on? (You'd also need to convince RPZ blacklist providers to include RRSIGs in their feeds, because you'd need signatures on rewritten responses.) Such considerations are why so many users are behind resolvers that validate DNSSEC but practically no domains are signed. DNSSEC is a good thing for operators of DNS clients, both resolvers and stubs, but it is far more cost than benefit to operators of authority servers. That's why we have the enduring, very discouraging picture at http://scoreboard.verisignlabs.com/percent-trace.png http://scoreboard.verisignlabs.com/ Such issues might also be why some of the most emphatic critics of RPZ in this mailing list nevertheless send their critiques from unsigned domains. Note that the vast majority of clients of RPZ rewriting resolvers are stubs that don't do validation but trust header bits saying that a resolver operated by a third party did the validation. I think that's wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah de blah de blah, but it's also something no one seems willing and able to change. Vernon Schryver vjs@rhyolite.com From nobody Mon Jan 9 07:57: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 B750E129541 for ; Mon, 9 Jan 2017 07:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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_HI=-5, RP_MATCHES_RCVD=-3.199] 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 EvksXoDpt6Zh for ; Mon, 9 Jan 2017 07:57:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19423129620 for ; Mon, 9 Jan 2017 07:57:04 -0800 (PST) Received: from [10.175.27.116] (cst-prg-114-28.cust.vodafone.cz [46.135.114.28]) by mail.nic.cz (Postfix) with ESMTPSA id 714CA6098C for ; Mon, 9 Jan 2017 16:57:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483977422; bh=kdL+/jG2qNqVobI8tLV73N3lfAj1gnrnQ636Iq8Kt5w=; h=From:To:Date; b=d3cm9fC0Ly165NeirUGiVtGC1oCljnaZYPg0Rs9cBN28tSy5X+AihZhv3Aa5ILVOe xZjDdo2uxJZAahBdMEFKqvtLmLTW3I+29wLKMrCrFnGjwO0WqIU7SAMeusKj4/20Nf kZ1qr/BwFHFvLaz6ak0mLQXuKzvJgE4FUtbDtp4U= From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Date: Mon, 09 Jan 2017 16:57:01 +0100 Message-ID: <15983f270c8.2768.111384ef9303931154bc986d03632394@nic.cz> In-Reply-To: <148397538763.24980.3386719923727723156.idtracker@ietfa.amsl.com> References: <148397538763.24980.3386719923727723156.idtracker@ietfa.amsl.com> User-Agent: AquaMail/1.7.1-88 (build: 100700100) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [DNSOP] Fwd: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:57:05 -0000 Dear colleagues, the EDDSA for DNSSEC have been approved by IESG. OndÅ™ej and Robert, co-editors --- Forwarded message --- From: The IESG Date: 9 January 2017 16:23:28 Subject: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt) To: IETF-Announce CC: curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , draft-ietf-curdle-dnskey-eddsa@ietf.org, The IESG , stephen.farrell@cs.tcd.ie, rfc-editor@rfc-editor.org The IESG has approved the following document: - 'EdDSA for DNSSEC' (draft-ietf-curdle-dnskey-eddsa-03.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ Technical Summary This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. Working Group Summary The definition of the signature format was straight forward as it already exists in DNSSEC. In addition the computation and verification of the signature is defined in [I-D.irtf-cfrg-eddsa]. The only discussion was upon the use of using Ed25519ctx versus Ed25519, but the consensus was reached easily. The same discussion also occurred for draft-ietf-ipsecme-eddsa and draft-ietf-curdle-pkix with the same conclusion. The absence of context follows the recommendations of Section 10.3 of I-D.irtf-cfrg-eddsa and avoids unnecessarily complexity. Document Quality The document has been reviewed carefully. Examples have been generated with prototypes. Although no implementations have been reported in the document, there are ongoing effort. Personnel Document Shepherd: Daniel Migault, AD: Stephen Farrell _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jan 9 09:05:24 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 11AAD1297C3 for ; Mon, 9 Jan 2017 09:05:22 -0800 (PST) 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, 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=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 7noN4vB4JuJs for ; Mon, 9 Jan 2017 09:05:20 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 49584129549 for ; Mon, 9 Jan 2017 09:05:20 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v23so141455187qtb.0 for ; Mon, 09 Jan 2017 09:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UCyfeNBCDT1UccwjaefOtCmo7c4J6Ee+bmL/a0Fsri4=; b=ohD0hrb/J7/KXjr4n7TxnXgLYNRj0DMFAHgZIbfqQHtQ3sq31xElCo9r6YiJ5QTWki bN+tDEDhSX6uLXGAdqpCavQzX2e3Y0JTNCQyafGzpjhQP984Fi7PN3e5Qq+RUwbIx1oj 7fTT+UdSkTTRpGWD7way8ZLK/VCJNoMh/5/xLRuQCOqADKr0z8DErOQX8xS7pW/c2VMD kBbUZVU1NTUUIo1GwtXvHw55cFQtBWBP+RZIkb9GkAvXq87ADTUJ90sebn0ZZk6QDPJn 6B7P2Qvcl8NU29qCGM911Te6uohwinpBh6PFeGfevLteyYvtM3pRI6IlKcI50R37aW/U L2Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UCyfeNBCDT1UccwjaefOtCmo7c4J6Ee+bmL/a0Fsri4=; b=ohp4pK/T1qEIvWnQ/lCb65oqi52b0Dgc46mW8lji9b7cvEikR3O5Dw8ZOhHKdN6LF6 YCzUN2uJIIYOEV+bMSisiTpsPwKpXu95aphOPjv1lzeU6aIA3bnp1FjBmMT1cmm8dgHj lBxB9d+Of4SOnLfSKNAe4UPVyZCwiof2Vu+DTj12yIl5+EW9Ge2yVvxjZegWrtwSePMI KDeK2tbtnOowjFwe1xC/I2nFgsooW50runUrilaJ3UvQgjisQ3r7dOUYQM7IqF/Vt9E5 G6wkmPGu9ME76sUDpoYwRGLszPvo4Y5F+1ZAYqw6uE6p1E93Ypf9+STtQ8Z33VkD4DkR jNTA== X-Gm-Message-State: AIkVDXJNXwPAY1s0PAeRFI1xWa5737k5o4MjdxwZQCOMvPiahUsFDPi0nFIT5y56/TB3NA== X-Received: by 10.200.55.178 with SMTP id d47mr86726141qtc.60.1483981519298; Mon, 09 Jan 2017 09:05:19 -0800 (PST) Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e33sm13571299qtb.31.2017.01.09.09.05.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 09:05:18 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8698FA9D-20CA-41C2-AD71-C85649EAAE79" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 9 Jan 2017 12:05:16 -0500 In-Reply-To: <201701091551.v09FpVif091631@calcite.rhyolite.com> To: Vernon Schryver References: <201701091551.v09FpVif091631@calcite.rhyolite.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:05:22 -0000 --Apple-Mail=_8698FA9D-20CA-41C2-AD71-C85649EAAE79 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jan 9, 2017, at 10:51 AM, Vernon Schryver wrote: > Note that the vast majority of clients of RPZ rewriting resolvers are > stubs that don't do validation but trust header bits saying that a > resolver operated by a third party did the validation. I think that's > wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah > de blah de blah, but it's also something no one seems willing and able > to change. *slow clap* --Apple-Mail=_8698FA9D-20CA-41C2-AD71-C85649EAAE79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 9, 2017, at 10:51 AM, Vernon Schryver <vjs@rhyolite.com> = wrote:
Note that the vast majority of clients of RPZ = rewriting resolvers are
stubs that don't do validation but trust = header bits saying that a
resolver operated by a third party did = the validation.  I think that's
wrong, evil, nasty, unethical, a = Major Human Rights Issue, and blah
de blah de blah, but it's also = something no one seems willing and able
to = change.

*slow clap*

= --Apple-Mail=_8698FA9D-20CA-41C2-AD71-C85649EAAE79-- From nobody Mon Jan 9 11:53: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 4C427129588 for ; Mon, 9 Jan 2017 11:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 FBvFnamWussp for ; Mon, 9 Jan 2017 11:53:39 -0800 (PST) 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 E6C9C129575 for ; Mon, 9 Jan 2017 11:53:38 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cQg0e-0000CcC; Mon, 9 Jan 2017 20:53:36 +0100 Message-Id: To: dnsop@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> In-reply-to: Your message of "Mon, 9 Jan 2017 10:14:27 -0500 (EST) ." Date: Mon, 09 Jan 2017 20:53:30 +0100 Archived-At: Cc: Paul Wouters Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:53:41 -0000 >See the recent discovery that Heathrow Airport runs a >MITM TLS server on torproject.org. Do we want them to run RPZ where they >can disappear torproject.org alltogether? No. Do we want them to run RPZ >to prevent travelers from getting malware installed? Yes. Just my crystal ball: 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow Airport can mount a denial of service on DNS. So it does not matter if the malware zone is signed or not. If Heathrow Airport modifies the reply the traveler will be protected. 2) It makes sense to do local validation with something like getdns. If such a local validating resolver notices that DNSSEC validation fails ("Roadblock Avoidance") it may contact auth. DNS servers directly. 3) Heathrow Airport can move to deep packet inspection and also block direct access to malware DNS. 4) DNS is not really private so Google may offer their DNS services over HTTPS. 5) Governments may force Google to block popular sites, so users switch to other DNS resolvers, again over HTTPS. After step 5, any benign malware filtering options are probably lost. In that sense I don't care that much about the more philosophical arguments arguments against rpz. If you care about DNS, run a local DNSSEC validating resolver that does roadblock avoidance and possibly falls back to TLS or HTTPS to some trusted resolver. From nobody Mon Jan 9 13:23:46 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 B5AC61295D8 for ; Mon, 9 Jan 2017 13:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 bCcaAV4G9blc for ; Mon, 9 Jan 2017 13:23:43 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 8A8A51294E4 for ; Mon, 9 Jan 2017 13:23:43 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so82329920qtc.2 for ; Mon, 09 Jan 2017 13:23:43 -0800 (PST) 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=nDoqb3xsEcXudsFfGH6fCX0JUgMtrLW1iWJBPoR37xk=; b=flTinwX0uZrUPbp+wFoE5KD1sEiXPOXh/hKDPed9oVUG0bZKH3++/Xj1nPE0edNz1G XWZHZSbz8hvZnR+4N1BE5evyPa+kuZ5nLxIv+hnPZitnNBLf/04zEK9uBqN5hq917CSi 45R9D5+UUs+6blCBoeFcJCxv2XXV13nOzzlppS79afgoIEr3e0E7HI608zBlZVlsqAo9 WtwfeTHrvPSz+s/tXZQiXjSna3uo5jC4XsFXo0u14PHCbMluEPanZslcVrOpfekXuTlM 9OtP8gUlQFROuX8WStGozraksDM1ApODffWEgAtcv9dmvHxidm09X9JzimWjMDaiQ9VD 1Zug== 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=nDoqb3xsEcXudsFfGH6fCX0JUgMtrLW1iWJBPoR37xk=; b=iK1Bf81KtB4CTrvtyaTz07dhDP9wpCxLy2ok8psx8ysh7/iDwZH+0rr2rN4eFRNIA4 iMI/tlvIR2c9WoSs090nGRtG8s/QeBQkarNmYEdrcAH6mQ4HOUCOccaArl/1EF5kmHL7 IbI6B5wt+mYa+FBcL8nGxX73dT5lrOG29Hd1L1lPfc9bOR0VwcElgJpNIm0I8GeqrT3y k4hSOFdjXt1isnZguNWExNNLsq04vSNluJZ/r9XtQAx8CXGgqHeldFgPUEKL9IoSisyO BqH3aYLZhbBBVZzx9SdW7D3iLKTwOzLGgXvByXwt2dHjO4tBVgJgR7HdAImipKcdUJbI ub2A== X-Gm-Message-State: AIkVDXL5snhvnfb25onDN++vXNMpV8+4PJxZaUrWBF0tZxepmOB6/odcqCtL5AhP3BnnDv8rQB0ivzPDs7XOHQ== X-Received: by 10.200.34.28 with SMTP id o28mr12579007qto.269.1483997022557; Mon, 09 Jan 2017 13:23:42 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Mon, 9 Jan 2017 13:23:41 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 9 Jan 2017 13:23:41 -0800 X-Google-Sender-Auth: SZ6t-xrV5SXPNFKHBaKxVNH-vic Message-ID: To: tjw ietf Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:23:46 -0000 On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf wrote: > The draft is being present as "Informational", and the point here is to > document current working behavior in the DNS (for the past several years). > It is obvious that some feel this draft is a large mistake, but like > edns-client-subnet, more operators are deploying this than one is aware of. > > This starts a Call for Adoption for draft-vixie-dns-rpz > > The draft is available here: > https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/ > > 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'm still reading the 04 version of draft-vixie-dns-rpz and intending to make comments on it later, but I'd like to respond to the call first: I do not think it's suitable for dnsop to adopt the draft in its current form, with the intent of "just describing currently deployed practice", and (as I guess) with the intent of eventually publishing as an (Informational) RFC. But I think the document itself is very useful, so it would be nice if it's made more publicly available in other form, e.g., some white-paper kind or at a popular blog site. If the adoption means polishing the document for that goal (although I don't think it's the intent for this call), I'd support it. Also, if we're really willing to work on a "standard, interoperable DNS firewall specification" without worrying about substantially changing the current practice/implementation, and if the adoption means the first step for that goal (and so the final publication could be totally different and may not be compatible with the existing standard), then I'd support it. But, again, I suspect that's not the intent of this call. Some more specific rationale for this opinion below: - As I believe most people, and perhaps including the draft authors or RPZ implementations, agree, it's an ugly hack to use the standard DNS zone to represent the firewall rules. It might have been a convenient way to implement the idea initially (e.g, we can use the zone transfer behavior to distribute the rules), but I don't see an essential reason why these are represented as DNS RRs. And, (again as I believe everyone knows) it's not just ugly but also has some inherent flaws, such as that not all domain names can be represented due to length limitation. In fact, not all existing implementations of RPZ-like feature use this form as the primary way of rule configuration (unbound is one example I happen to know of, and from a quick look knot resolver also seems to adopt its own configuration syntax). Perhaps operators of these implementations use some conversion tools form the "standard" RPZ policies to its internal form, but that's obviously inconvenient. Standardizing the spec more officially eventually leads to unified configuration (at least in concept) to eliminate the need for such a tool, but it would require changes to other existing implementations anyway. Then it would be far better to develop a better form of policy representation from the beginning. - If this is to be published as an IETF standard (even if "informational") and especially as a product of the dnsop wg, I believe it should contain more DNSSEC-related considerations. The current situation is either + validly DNSSEC-signed responses bypass RPZ policies (when 'break-dnssec' is set to no), or + 'break-dnssec' is enabled, and it would currently confuse validating stub resolvers As long as this wg hopes to see more such stub resolvers deployed (I'm assuming so), any of its protocol work should IMO help such deployment rather than hinder it. - I know the above points are about to be dismissed with "these are out of scope of this doc; it just describes what is currently deployed". And that's exactly another big concern of mine, especially because I heard the adoption of this draft would be similar to that of edns-client-subnet. At that time several wg participants including myself raised unclear or ambiguous points of the spec, some of which were based on attempts of implementing it. Sadly, though, many of them were effectively silenced with the excuse of "not in scope". Another excuse at that time was that there would be another standard truck doc to fix these issues, but, as quite predictably, people seem to have lost interest/energy once the RFC was published and there doesn't seem to be any attempt of revising the spec. I've already sensed the same thing could happen for draft-vixie-dns-rpz from the adoption discussions on this list, and I don't like to see it actually happen. To be clear, "really just describing what is currently deployed" is fine for me. But my lesson from edns-client-subnet it can't well coexist with the intent of having more interoperable implementations. If the intent is purely former, then it's better to publish it somewhere else; if our intent is to promote interoperability starting with the spec and lessons of existing deployment, we should be willing to change the current spec. -- JINMEI, Tatuya From nobody Mon Jan 9 14:19: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 4339112963F for ; Mon, 9 Jan 2017 14:19:18 -0800 (PST) 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_00=-1.9, 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 (1024-bit key) header.d=opendns.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 1gZzH5dMCmPw for ; Mon, 9 Jan 2017 14:19:15 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 D128512960E for ; Mon, 9 Jan 2017 14:19:15 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id 189so22015283pfu.3 for ; Mon, 09 Jan 2017 14:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opendns.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=floR8pzKGBmbTc2pGW3Uz2TFqLaskj+jRVS45e019kU=; b=Jk1uCWHPQuRDA4eP0PPKYBNxGJDh2BtYMrH46umBCFAB7gsffhPru+DOQpfZ5SjJkM gGcbRm5EoGdkd7Hwz3i9eW0hZxldAsaPqn4/XbjFJNQqMdfuUKnoBrJLAz9UG5/KcDiH Rm6WHZyd9wj3F0fm7S65JGmiX3nPMcqI48HZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=floR8pzKGBmbTc2pGW3Uz2TFqLaskj+jRVS45e019kU=; b=rgigXDdtZdFZPSQE5c2SgRV0T2FDW91LT5WIs/MHGB0SJE5AjB4R0+kKSA/oPgz39Q nfQJrOP6zlWGVH89faHY4+xszAvMynx+9IR8DRFaLx996PQeoMhA4Dgr2jozO5B2s8T3 P4CjbV5b7lVaxGxsYyGhm+K24h4rF6Q3C8zeTXHyFdbtLFcmeklRGDXZov/193OLttcW vxfNhEyKCusWsz9qrIkSs8s4nO0Y3PbFqhB1bZlBTuliv9yZptJAKPOowvqFStaSUkhi OfP1LwWOvu3YP7P3p2M6y4wIRFFipO08RjvmGeZMSXESimm7W+BYGPflKqfkqEmIuS46 98GA== X-Gm-Message-State: AIkVDXKgqDizdPfIR5uquaJ1zrv/zK2DoNNNd9c4a2n+zz2LYvipwznPsz7ki3Fr3NFKzlFL X-Received: by 10.84.217.66 with SMTP id e2mr180472290plj.109.1484000355451; Mon, 09 Jan 2017 14:19:15 -0800 (PST) Received: from [192.168.1.246] (24-116-170-61.cpe.cableone.net. [24.116.170.61]) by smtp.gmail.com with ESMTPSA id m12sm133556822pfg.92.2017.01.09.14.19.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 14:19:14 -0800 (PST) From: Brian Hartvigsen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_95B3BF4C-FA1F-4AB2-AABC-7A9CF530929E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 9 Jan 2017 15:19:11 -0700 In-Reply-To: To: Warren Kumari References: <147909930902.10318.12934239778853597228.idtracker@ietfa.amsl.com> <20161127111037.GA10721@jurassic> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop , Mukund Sivaraman Subject: Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:19:18 -0000 --Apple-Mail=_95B3BF4C-FA1F-4AB2-AABC-7A9CF530929E Content-Type: multipart/alternative; boundary="Apple-Mail=_2ECE9368-7E55-46B1-97A8-2A1282126F00" --Apple-Mail=_2ECE9368-7E55-46B1-97A8-2A1282126F00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > > NOTE: I believe that there may be (non-Google) IP associated with > > this. A lawyer will be filing the IPR disclosure later today (time > > zone differences, etc). >=20 > The two approaches are somewhat different, and so at least one of them > may not be covered by this patent. >=20 > Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole = was acquired by Akamai in March 2015. I believe that David will discuss = the IPR with his employer. Thought I should point out that Cisco (previously OpenDNS) also has IPR = in this area (tmk predates Xerocole.) Not sure if there is anything to = be done at this time, but just thought I should put that out there. .:|:.:|:. Brian Hartvigsen Manager, Site Reliability Engineering Cisco Umbrella --Apple-Mail=_2ECE9368-7E55-46B1-97A8-2A1282126F00 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

> NOTE: I believe that there may be (non-Google) IP associated with
> this. A lawyer will be filing the IPR disclosure later today (time
> zone differences, etc).

The two approaches are somewhat different, and so at least one of them
may not be covered by this patent.

Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was acquired by Akamai in March 2015. I believe that David will discuss the IPR with his employer.

Thought I should point out that Cisco (previously OpenDNS) also has IPR in this area (tmk predates Xerocole.)  Not sure if there is anything to be done at this time, but just thought I should put that out there.

.:|:.:|:.
Brian Hartvigsen
Manager, Site Reliability Engineering
Cisco Umbrella
--Apple-Mail=_2ECE9368-7E55-46B1-97A8-2A1282126F00-- --Apple-Mail=_95B3BF4C-FA1F-4AB2-AABC-7A9CF530929E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYdAxgAAoJEEbuoyCBJVvrDTUQAKXIem79PCLXAMyOzYnRoUJP KTUnfXxd4eYbP1kuZFFwsn+lIwbeWUgSZEBBhqoT6vBHBuwkrNOinuuwPirndgVw 92cicOD3J77eA8PcbIQYs75DAsnI3EhujHONLR1dAen0Nt8XGfA6+VFv/aldV6Pt 91geqNn2leKsIX8PiDN0r3rgtBe87QSTVwVVCrHHMwY9sAyFYU2mAEPCPe0u4a6W nAfXTKw3SkEuKl3fj1QYhX9UhzaNYzxeWKEwGpu492zPbCOFrQiybbHDEnD03iMG 1JwUz0uGSztRv7lCg+ky+oGIaV9JXUjloxkcHKPHApnp89t6/iANn8jiFphXTSA3 usGCiv9VIPcaXVjVzqH/DLwed+tV35+oE+/TimtD20vedaxKKJsm8F7doz+6dbzf L+fIseX06XjgkgcKtQFZvCWB4DJvHtzHqc5WmSDtPMYUDGiBFmshNDazHRZgfm1+ +L4lPLGe8yG9FUdsqZiX6OGhJzbm+NTcb1TTYqTBHurtCadNrTMYRfZp0PwPwSmt 8D9SI+RJpdH4Hp5oPcAk4kF/5Jnij3IaVeSANwWqXQJY7O0Fzfx/hfmYDt5LCNn3 SBUoMBhuecVViG6OT61+CXweCirm0EBAoMx0ZGnuxhPrxBVmm4e+rsD87/TwIoiz khCg2KWdJ7F+z9EMwoxr =f/uZ -----END PGP SIGNATURE----- --Apple-Mail=_95B3BF4C-FA1F-4AB2-AABC-7A9CF530929E-- From nobody Mon Jan 9 14:59: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 7E1831295E4 for ; Mon, 9 Jan 2017 14:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 oEpeEBwj8b5H for ; Mon, 9 Jan 2017 14:59:19 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (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 9E8DB12947B for ; Mon, 9 Jan 2017 14:59:19 -0800 (PST) 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.ams1.isc.org (Postfix) with ESMTPS id 454B51FCCB3 for ; Mon, 9 Jan 2017 22:59:12 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C18BB160047; Mon, 9 Jan 2017 22:59:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A6BF216006C; Mon, 9 Jan 2017 22:59:10 +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 Rz5R_Q21DLpa; Mon, 9 Jan 2017 22:59:10 +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 09D10160047; Mon, 9 Jan 2017 22:59:10 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CEECF5EE0242; Tue, 10 Jan 2017 09:59:05 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <148396571329.24904.14128382959913441373.idtracker@ietfa.amsl.com> <484ebc0c-7286-3c80-564c-bf816600c4a4@isc.org> In-reply-to: Your message of "Mon, 09 Jan 2017 12:43:40 -0000." <484ebc0c-7286-3c80-564c-bf816600c4a4@isc.org> Date: Tue, 10 Jan 2017 09:59:05 +1100 Message-Id: <20170109225905.CEECF5EE0242@rock.dv.isc.org> Archived-At: Cc: dnsop Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:59:20 -0000 TSIG and SIG(0) (not yet covered by the draft) require reversable modifications of the message. I would be appending a new additional record (code TBA) and removing it which contains the addresses. I would not be modifying an existing OPT record. Nor would I be adding a new OPT record. Modifying/adding a opt record requires a lot more, error prone, work to add and reverse the changes to make TSIG and SIG(0) work. The additional section count would be increased by 1. TSIG / SIG(0) may now be followed by this record. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jan 9 15:38:34 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 0F40512999B for ; Mon, 9 Jan 2017 15:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 FnELqLB0DFhA for ; Mon, 9 Jan 2017 15:38:31 -0800 (PST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 6D37D129999 for ; Mon, 9 Jan 2017 15:38:31 -0800 (PST) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v09NcFNp059807 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Mon, 9 Jan 2017 23:38:16 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v09NcEqm059806 for dnsop@ietf.org; Mon, 9 Jan 2017 23:38:14 GMT Date: Mon, 9 Jan 2017 23:38:14 GMT From: Vernon Schryver Message-Id: <201701092338.v09NcEqm059806@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 23:38:33 -0000 > From: Philip Homburg > 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow >4) DNS is not really private so Google may offer their DNS services over HTTPS > 5) Governments may force Google to block popular sites, so users switch to > other DNS resolvers, again over HTTPS. See https://developers.google.com/speed/public-dns/docs/dns-over-https but I don't know how clients bootstrap that API without classic DNS. Regardless of that, what if Heathrow Airport deploys HTTPS proxies to block child porn, drug, terrorist, and malware web pages as well as attempts by corrupted laptops and smart phones to bypass blocks on port 53 and reach evil or merely unfiltered DNS/HTTPS servers including those run by Google? > In that sense I don't care that much about the more philosophical arguments > arguments against rpz. If you care about DNS, run a local DNSSEC validating > resolver that does roadblock avoidance and possibly falls back to > TLS or HTTPS to some trusted resolver. Everyone should do that, if necessary without knowing they're doing it, such as with the help of validating resolver code in broswers. Something like that is required to stop the fraud that is commercial PKI. (Google's two alternatives to DANE are great for the Alexa 500 and maybe the Alexa 5000, but useless or worse for the Alexa 100,000,000.) .............. ] From: =?UTF-8?B?56We5piO6YGU5ZOJ?= ] But I think the document itself is very useful, so it would be nice if ] it's made more publicly available in other form, e.g., some ] white-paper kind or at a popular blog site. That will happen whether or not the text gets an RFC number. (If it doesn't get a number, of course I will remove the IETF mumbo-jumbo.) The current de facto standard status of RPZ suggests finding sufficient popular web sites for publication is not an issue. Disclaimer: Many people including the other author want the draft to get an RFC number. But my considered reaction the threats to not publish, the demands to not publish without what I see as ill conceived or worse fixes, and various other sentiments is more like "Please don't throw me in the briar patch." https://www.youtube.com/watch?v=S7tyhpWiZyM ] its not just ugly Yes, RPZ is a nasty, ugly, evil kludge that would not exist if I were in charge of the Internet. ] but also has some ] inherent flaws, such as that not all domain names can be represented ] due to length limitation. Yes, but do you know of a real life example cannot be rewritten because the RPZ trigger name would be too long? ] In fact, not all existing implementations ] of RPZ-like feature use this form as the primary way of rule ] configuration (unbound is one example I happen to know of, and from ] a quick look knot resolver also seems to adopt its own configuration ] syntax). Distributed blacklisting is one of or the most powerful aspect of RPZ. I think (perhaps mistakenly) that the new blocking mechanism in Unbound 1.6.0 lacks that aspect. In addition, there is an RPZ patch for Unbound versions 1.5.4 through 1.6.0 that uses a separate daemon that acts like a slave master for policy zones using AXFR/IXFR/NOTIFY. However, I stopped maintaining and deleted the patches for version 1.5.4 through 1.5.8 long ago. Another caveat is that the work was for hire and so the daemon and its interface .so are not open. The patches to Unbound are open and have been offered to NLnet Labs. Vernon Schryver vjs@rhyolite.com From nobody Mon Jan 9 20:30:58 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 E0D9C129E74 for ; Mon, 9 Jan 2017 20:30:57 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 8D4ajEAeXq07 for ; Mon, 9 Jan 2017 20:30:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A601C129E6F for ; Mon, 9 Jan 2017 20:30:56 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8D7F6284E49; Tue, 10 Jan 2017 04:30:55 +0000 (UTC) Date: Tue, 10 Jan 2017 04:30:55 +0000 From: Viktor Dukhovni To: dnsop@ietf.org Message-ID: <20170110043055.GN13486@mournblade.imrryr.org> References: <201701091551.v09FpVif091631@calcite.rhyolite.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201701091551.v09FpVif091631@calcite.rhyolite.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dnsop@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 04:30:58 -0000 On Mon, Jan 09, 2017 at 03:51:31PM +0000, Vernon Schryver wrote: > Note that the vast majority of clients of RPZ rewriting resolvers are > stubs that don't do validation So far, and at present, correct. Validating resolvers (unbound and the like) are seeing deployment on servers first, including some of the caches queried by said stubs. (Far from representative of course, My home OpenWRT router runs a validating unbound.) > but trust header bits saying that a > resolver operated by a third party did the validation. But not this. The stubs in question are generally security oblivious, and don't in any sense "trust" that any validation happens upstream. > I think that's > wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah > de blah de blah, but it's also something no one seems willing and able > to change. And this part is both irrelevant, and IMHO inappropriately dismissive of legitimate concerns expressed upstream. We won't all agree, but we should be held to a higher standard on the manner of the discourse. -- Viktor. From nobody Mon Jan 9 23:58: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 303D8129B31 for ; Mon, 9 Jan 2017 23:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 ZO4Ut0DcmGjM for ; Mon, 9 Jan 2017 23:58:10 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 8D39F129B29 for ; Mon, 9 Jan 2017 23:58:10 -0800 (PST) Received: from [172.19.128.50] (vpn-10-mht.dyndns.com [216.146.45.33]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 358C28910 for ; Tue, 10 Jan 2017 08:58:07 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: dnsop@ietf.org References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> From: Matthijs Mekking Message-ID: <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> Date: Tue, 10 Jan 2017 08:58:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 07:58:12 -0000 I see that IESG has approved this document, but I am still wondering this: On 01-12-16 13:20, Matthijs Mekking wrote: > Hi, > > I read this again. I still wonder if in the case of DNSSEC Delete > Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is > 0, the Digest/Public Key MUST be ignored. > > This way, you don't have to change the CDS/CDNSKEY format defined in RFC > 7344, most likely causing less problems with deployed software. Best regards, Matthijs From nobody Tue Jan 10 03:17:55 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 BD8D6129BAD for ; Tue, 10 Jan 2017 03:17:52 -0800 (PST) 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] 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 gCpn5n2a4MYN for ; Tue, 10 Jan 2017 03:17:50 -0800 (PST) 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 495A8129B1B for ; Tue, 10 Jan 2017 03:17:50 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cQuR2-0000FjC; Tue, 10 Jan 2017 12:17:48 +0100 Message-Id: To: dnsop@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com In-reply-to: Your message of "Mon, 9 Jan 2017 23:38:14 GMT ." <201701092338.v09NcEqm059806@calcite.rhyolite.com> Date: Tue, 10 Jan 2017 12:17:48 +0100 Archived-At: Cc: Vernon Schryver Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 11:17:53 -0000 >> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathro >w > >>4) DNS is not really private so Google may offer their DNS services over HTTP >S >> 5) Governments may force Google to block popular sites, so users switch to >> other DNS resolvers, again over HTTPS. > >See https://developers.google.com/speed/public-dns/docs/dns-over-https >but I don't know how clients bootstrap that API without classic DNS. The nice this about Google is that they are too big to block. It is not a problem to use plaintext DNS to connect to Google because the CA system and possibly DANE will protect the TLS connection. >block child porn, drug, terrorist, and malware web pages as well as >attempts by corrupted laptops and smart phones to bypass blocks on >port 53 and reach evil or merely unfiltered DNS/HTTPS servers including >those run by Google? I'm not sure what 'HTTPS proxy' means in this context. If a public wifi at an airport can decode TLS traffic then we have a serious security hole. (Of course SNI is a problem. Hopefully TLS 1.3 will improve that) But the bigger problem is that most users don't really care about the difference between a public wifi operated by an airport and a public wifi operated by a criminal. And maybe the criminal just took over the wifi router at a respectable restaurant. So an ISP can null route traffic to known bad destinations (though people may switch to TOR to even deny an ISP even that option) but anything that goes beyond that (ISP access to DNS, etc) also provides great opportunities to attackers. It doesn't really help much if an airport blocks malware but the bar next door doesn't. So for any mobile device, you have to secure the device anyhow. Then this extra protection by ISP mostly becomes another attack vector. So at least for mobile devices it makes sense to make sure that all traffic on the wifi interface is encrypted and we keep the ISP out of the loop as much as possible. From nobody Tue Jan 10 06:56: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 19BDC1294F9 for ; Tue, 10 Jan 2017 06:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsb9obCjup4J for ; Tue, 10 Jan 2017 06:55:59 -0800 (PST) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id E66FD1294FE for ; Tue, 10 Jan 2017 06:55:58 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id ABD965F4081B; Tue, 10 Jan 2017 15:55:57 +0100 (CET) Received: from [192.168.2.129] (p57B9E1B8.dip0.t-ipconnect.de [87.185.225.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 0CEC65F402E9; Tue, 10 Jan 2017 15:55:56 +0100 (CET) From: "Ralf Weber" To: "Scott Schmit" Date: Tue, 10 Jan 2017 15:55:55 +0100 Message-ID: <115D5265-B9C0-49D9-9257-7BBFC0535DFB@fl1ger.de> In-Reply-To: <20170107225456.GB10627@odin.ULTHAR.us> References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop@ietf.org, John Levine Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:56:00 -0000 Moin! On 7 Jan 2017, at 23:54, Scott Schmit wrote: >>>> why you think hostile actors will do things with RPZ that they >>>> couldn't do now? > > For the very reasons that the authors want to make this an RFC -- RPZ > isn't interoperable between DNS resolvers today. Once this RFC is > published, it's clearly hoped that RPZ will be more interoperable and > thus widespread. > > It's true that countries can legislate anything they want, and the > publication (or not) of an RFC won't change that. > > But the enforcement of laws costs resources, and resources are finite -- > so a country passing laws requiring network operators to filter and/or > redirect will have no choice but to prioritize enforcement of such laws > against other needs. I don't know if you ever where involved in law creation, but I can assure you, being involved in lobbying lawmakers to make sensible laws and also implementing redirection via DNS which is common in a lot of countries, that lawmakers give a damn about how much it costs providers to implement the redirection. When implementing redirection via DNS I've seen every sort of possible input thrown at me from snail mail to EBDIC text files, pdf, you name it. The funniest case was one country that had different branches of the government issuing block lists one with a word document over ftp and the other with XML over https. I would love to have had a common format then and not re-invent the wheel on every new case. BTW all of these implementations where in what one would consider democratic countries in Europe (The nice thing about the EU is even if you have a EU directive you still get 27 different laws to follow if you are a pan european provider ;-). My point here is if you don't like redirection and blocking via DNS (which IMHO is much better than mandating DPI - unless you are a DPI vendor ;-) get involved in politics and try to change that at OSI layer 9. None of the stuff we discuss here will change any law or mandated redirection, nor will it change the efforts of lots of sysadmins and security researchers using the discussed technology to block bonnets and bad guys to not infect subscribers. It just would be nice if these poor sysadmins had some common tools, but as said we've solved problems without that until now and as others said RPZ actually might not be the best tool to express DNS policy configuration, but given the current state of the discussion I have serious doubt that the working group would consider working on that at all. So long -Ralf From nobody Tue Jan 10 08:50: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 2875B129D31 for ; Tue, 10 Jan 2017 08:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 druQWVkLuKD6 for ; Tue, 10 Jan 2017 08:50:47 -0800 (PST) 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 D847F129410 for ; Tue, 10 Jan 2017 08:50:46 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tydLp22CBz1Kh; Tue, 10 Jan 2017 17:50:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484067042; bh=8Inrx2/+3SqnruEJXA55Eeu3e2AsElrI+v5eNC1Ttiw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DrRbyV3Vq2o8ZErzASYgcOVf4zEGSeQsr2wmV0mdlxxYZ7c1RXR0qxeBKp5iQZks2 aL+nHMO444/ShG85LJCoLUobi5cpghVuUxIGGu3BVoD93w7250uvHYzpJ/qyBYQ/8o VkxyJOk8U9ofu1fqVdIDz0URn0ha2piOSfOfTu5M= 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 IPbC94jT3KL6; Tue, 10 Jan 2017 17:50:40 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jan 2017 17:50:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8C7D2717D6C; Tue, 10 Jan 2017 11:50:37 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8C7D2717D6C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7541544836EF; Tue, 10 Jan 2017 11:50:37 -0500 (EST) Date: Tue, 10 Jan 2017 11:50:37 -0500 (EST) From: Paul Wouters To: Matthijs Mekking In-Reply-To: <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> Message-ID: References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:50:48 -0000 On Tue, 10 Jan 2017, Matthijs Mekking wrote: > I see that IESG has approved this document, but I am still wondering this: > > On 01-12-16 13:20, Matthijs Mekking wrote: >> Hi, >> >> I read this again. I still wonder if in the case of DNSSEC Delete >> Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is >> 0, the Digest/Public Key MUST be ignored. >> >> This way, you don't have to change the CDS/CDNSKEY format defined in RFC >> 7344, most likely causing less problems with deployed software. I personally think the simplification of using all zero's is good. If someone accidentally changes the wrong number in the DS record when changing parameters, it will prevent a mistaken delete request. While, the zone might still fail, at least it won't be forced to go through a period of insecure while the parental DS gets repopulated. Paul From nobody Tue Jan 10 09:34: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 F0589129538 for ; Tue, 10 Jan 2017 09:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 XRfPTS5DxNUX for ; Tue, 10 Jan 2017 09:34:01 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 E581F128B44 for ; Tue, 10 Jan 2017 09:34:00 -0800 (PST) Received: from [IPv6:2001:981:19be:1:31ac:2630:a2ed:a669] (unknown [IPv6:2001:981:19be:1:31ac:2630:a2ed:a669]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 57495B59F for ; Tue, 10 Jan 2017 18:33:58 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: dnsop@ietf.org References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> From: Matthijs Mekking Message-ID: <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> Date: Tue, 10 Jan 2017 18:33:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:34:03 -0000 On 10-01-17 17:50, Paul Wouters wrote: > On Tue, 10 Jan 2017, Matthijs Mekking wrote: > >> I see that IESG has approved this document, but I am still wondering >> this: >> >> On 01-12-16 13:20, Matthijs Mekking wrote: >>> Hi, >>> >>> I read this again. I still wonder if in the case of DNSSEC Delete >>> Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is >>> 0, the Digest/Public Key MUST be ignored. >>> >>> This way, you don't have to change the CDS/CDNSKEY format defined in >>> RFC >>> 7344, most likely causing less problems with deployed software. > > I personally think the simplification of using all zero's is good. If > someone accidentally changes the wrong number in the DS record when > changing parameters, it will prevent a mistaken delete request. While, > the zone might still fail, at least it won't be forced to go through a > period of insecure while the parental DS gets repopulated. I am fine with using all zero's. I just don't think the change in resource record format is a good idea, dropping the last RDATA field from the CDS record. Matthijs > > Paul > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Jan 10 09:53: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 92D53129541 for ; Tue, 10 Jan 2017 09:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 Yr_7X7LcwkHM for ; Tue, 10 Jan 2017 09:53:40 -0800 (PST) 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 5100A12941D for ; Tue, 10 Jan 2017 09:53:39 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tyflL64BZz3Nq; Tue, 10 Jan 2017 18:53:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484070814; bh=lEVU6BJlZKd8ZcyiVNbY6HJ8ws5c2/5e6ABu6R6zy6A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uN59fbHsE7uy4M8BgUe1v+0vVatsNCw0uPhMAOb0oH15weHFBfX5nXB8DuMmEkyKx QEaQYTSMsUZVdKots5viWoBy92o4vd6lh9wLZx38n+B2j5CUUHtpsXSRmMHJ3demfW 1xNiZiwVKOcmzej2BRLV0RgXOQYYGSjQoyFatHDk= 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 D--ipb8EJ_Yo; Tue, 10 Jan 2017 18:53:33 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jan 2017 18:53:33 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 456316ED5B1; Tue, 10 Jan 2017 12:53:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 456316ED5B1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 340B040D7281; Tue, 10 Jan 2017 12:53:30 -0500 (EST) Date: Tue, 10 Jan 2017 12:53:30 -0500 (EST) From: Paul Wouters To: Matthijs Mekking , Olafur Gudmundsson In-Reply-To: <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> Message-ID: References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:53:41 -0000 On Tue, 10 Jan 2017, Matthijs Mekking wrote: >> I personally think the simplification of using all zero's is good. If >> someone accidentally changes the wrong number in the DS record when >> changing parameters, it will prevent a mistaken delete request. While, >> the zone might still fail, at least it won't be forced to go through a >> period of insecure while the parental DS gets repopulated. > > I am fine with using all zero's. I just don't think the change in > resource record format is a good idea, dropping the last RDATA field > from the CDS record. Ohh, I think Matthijs actually found a bug: The CDS RDATA is identical to the DS RDATA format, which is according to RFC 4034: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft states: The keying material payload is represented by a single 0. So the CDS delete entry currently specified as: CDS 0 0 0 Should in fact be: CDS 0 0 0 0 And similarly, the CDNSKEY is currently specified as: CDNSKEY 0 3 0 and should be: CDNSKEY 0 3 0 0 Olafur, do you agree? Should we push a new draft version with this fix? Paul From nobody Tue Jan 10 13:01: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 9DF731295A2 for ; Tue, 10 Jan 2017 13:01:17 -0800 (PST) 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_00=-1.9, 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 (1024-bit key) header.d=cloudflare.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 ICoiFYmdte7y for ; Tue, 10 Jan 2017 13:01:16 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 1BDC712959D for ; Tue, 10 Jan 2017 13:01:16 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id c206so89053475wme.0 for ; Tue, 10 Jan 2017 13:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z98mMcKNn9g6cNWg6VGHnRxbnRm8iCqktlEnSkow67U=; b=r16xuVPQa7zw4JI1gvf+RgZMG08yLt3+3wmNc7p6Og3Hr9z0ynZOuOd9lU1NJ4ywQC CZfywjjRlIXBi6aKgld4QLBAp3CqhWT5NQW/En58CTXeV7lo85q7LbSPiqmghFKluimk aMsRFwd7Ii87a/GY36DpPeFEVO/X3acqBADVM= 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=Z98mMcKNn9g6cNWg6VGHnRxbnRm8iCqktlEnSkow67U=; b=G5J6lfK8TfN32j3K/7q9SBG6sau44ct+O2PWE2oz0IpWvXEu6XKLb1ALz/p+AlORaY DPEu9rbv1GBnPGq57J6NUzE3yuKejyFlWQgccsqfriXXL6V/HiVlT12/PbEXr0YMuxvY jS8HxQ3ogC7IyAAr7weUwhttVft8fl4GJGAyzOsMwrjIQ4j1BzOHTlxYy/ybbHeHK9fq kjFu85/e+k5Yq1KfC+lxV827B13pUCNJ5CdQS7d7x22WaveKk8MsHSemuiRjz2jYDibS Mk9AQ0cKmpvN3V0Hoglo2Gc4NoXsrPHNhFZKX8m3xtQ2yAvtOC/PvQb/vlyoGvDYdaCx zKLg== X-Gm-Message-State: AIkVDXJxqCTMDPKygrbwt2V9aMeyiB1loUaCjlIdPau9ktJCXL8XNxA3Rkj0qxsqpxVXoaXaVhkmO1s3j628DkqL X-Received: by 10.28.84.88 with SMTP id p24mr1011300wmi.52.1484082074450; Tue, 10 Jan 2017 13:01:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.11.13 with HTTP; Tue, 10 Jan 2017 13:01:13 -0800 (PST) In-Reply-To: References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Tue, 10 Jan 2017 16:01:13 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=94eb2c1cca80dd92a10545c3c8a9 Archived-At: Cc: Matthijs Mekking , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:01:17 -0000 --94eb2c1cca80dd92a10545c3c8a9 Content-Type: text/plain; charset=UTF-8 Yes I agree, Push a new version if Tim agrees ? Olafur On Tue, Jan 10, 2017 at 12:53 PM, Paul Wouters wrote: > On Tue, 10 Jan 2017, Matthijs Mekking wrote: > > I personally think the simplification of using all zero's is good. If >>> someone accidentally changes the wrong number in the DS record when >>> changing parameters, it will prevent a mistaken delete request. While, >>> the zone might still fail, at least it won't be forced to go through a >>> period of insecure while the parental DS gets repopulated. >>> >> >> I am fine with using all zero's. I just don't think the change in >> resource record format is a good idea, dropping the last RDATA field >> from the CDS record. >> > > Ohh, I think Matthijs actually found a bug: > > The CDS RDATA is identical to the DS RDATA format, which is > according to RFC 4034: > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key Tag | Algorithm | Digest Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / / > / Digest / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The draft states: > > The keying material payload is represented by a single 0. > > So the CDS delete entry currently specified as: > > CDS 0 0 0 > > Should in fact be: > > CDS 0 0 0 0 > > > And similarly, the CDNSKEY is currently specified as: > > CDNSKEY 0 3 0 > > and should be: > > CDNSKEY 0 3 0 0 > > > Olafur, do you agree? Should we push a new draft version with this fix? > > > Paul > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c1cca80dd92a10545c3c8a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes I agree,=C2=A0
Push a new version if Tim agrees ?= =C2=A0

Olafur


<= /div>

On Tue, Jan = 10, 2017 at 12:53 PM, Paul Wouters <paul@nohats.ca> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Tue, 10 Jan 2017, Matthij= s Mekking wrote:

I personally think the simplification of using all zero's is good. If someone accidentally changes the wrong number in the DS record when
changing parameters, it will prevent a mistaken delete request. While,
the zone might still fail, at least it won't be forced to go through a<= br> period of insecure while the parental DS gets repopulated.

I am fine with using all zero's. I just don't think the change in resource record format is a good idea, dropping the last RDATA field
from the CDS record.

 Ohh, I think Matthijs actually found a bug:

The CDS RDATA is identical to the DS RDATA format, which is
according to RFC 4034:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Key Tag=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 Algorithm=C2=A0 =C2=A0 |=C2=A0 D= igest Type=C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Digest=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/
=C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+


The draft states:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The keying material payload is represented by a= single 0.

So the CDS delete entry currently specified as:

=C2=A0 =C2=A0CDS 0 0 0

Should in fact be:

=C2=A0 =C2=A0CDS 0 0 0 0


And similarly, the CDNSKEY is currently specified as:

=C2=A0 =C2=A0CDNSKEY 0 3 0

and should be:

=C2=A0 =C2=A0CDNSKEY 0 3 0 0


Olafur, do you agree? Should we push a new draft version with this fix?


Paul

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c1cca80dd92a10545c3c8a9-- From nobody Tue Jan 10 15:51:31 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 8496B1293F9; Tue, 10 Jan 2017 15:51:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148409228853.22174.12379719088278926465.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 15:51:28 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:51:28 -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 : Managing DS records from parent via CDS/CDNSKEY Authors : Olafur Gudmundsson Paul Wouters Filename : draft-ietf-dnsop-maintain-ds-05.txt Pages : 10 Date : 2017-01-10 Abstract: RFC7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC7344 from informational to standards track and adds a standard track method for initial trust setup and removal of secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records) It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key ("KSK") plus Zone Signing Key ("ZSK") rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-05 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 Jan 10 15:59:41 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 51282129424; Tue, 10 Jan 2017 15:59:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148409277832.22242.18273110011780766407.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 15:59:38 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:59:38 -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 : Managing DS records from parent via CDS/CDNSKEY Authors : Olafur Gudmundsson Paul Wouters Filename : draft-ietf-dnsop-maintain-ds-06.txt Pages : 10 Date : 2017-01-10 Abstract: RFC7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC7344 from informational to standards track and adds a standard track method for initial trust setup and removal of secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records) It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key ("KSK") plus Zone Signing Key ("ZSK") rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06 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 Jan 10 16:02:46 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 5FE291295F6 for ; Tue, 10 Jan 2017 16:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 b1tt8uKwo1QQ for ; Tue, 10 Jan 2017 16:02:42 -0800 (PST) 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 6BBF0129426 for ; Tue, 10 Jan 2017 16:02:42 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3typxC3Gydz3Tn; Wed, 11 Jan 2017 01:02:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484092959; bh=wAwCQlUoRbM6JV6dknX/cWxeLxPrcCEjRZbFWTsTpgA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Nd0tjdLaZBAIK7w1G5miJ8XGM8nq4h8nn3yj8hcPTqHyMOad5VtDv+uiv7owZPDxG CyU1TiU8NmRy+rPNKuHAFZ5mNcx2ioibk0c8NaWgo814A4cxlBuMQ0OD6jdLZ1n+7Y lTzcNQaXjLiuKI8F6BjTMLm2oXg8oHA7Bh0lN24I= 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 1LQyFgE8-uE6; Wed, 11 Jan 2017 01:02:37 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 11 Jan 2017 01:02:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 23A746ED5B1; Tue, 10 Jan 2017 19:02:34 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 23A746ED5B1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 15971407E85E; Tue, 10 Jan 2017 19:02:34 -0500 (EST) Date: Tue, 10 Jan 2017 19:02:33 -0500 (EST) From: Paul Wouters To: Matthijs Mekking , Olafur Gudmundsson In-Reply-To: Message-ID: References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: Tim Wicinski , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:02:44 -0000 On Tue, 10 Jan 2017, Paul Wouters wrote: > Ohh, I think Matthijs actually found a bug: Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs for being so persistent in bringing this up. My apologies that I did not understand your concern before. Chairs, it is up to you to decide on redoing a LC on this or not. The diff between 04 and 06 that contains all changes since IETF LC: https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt Paul From nobody Tue Jan 10 18:47: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 54E00129893 for ; Tue, 10 Jan 2017 18:47:53 -0800 (PST) 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 Qo1v0eEO_VzR for ; Tue, 10 Jan 2017 18:47:51 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 A3E35129887 for ; Tue, 10 Jan 2017 18:47:51 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id x2so103644939itf.1 for ; Tue, 10 Jan 2017 18:47:51 -0800 (PST) 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=Gecaf0JcIA0sdHt75M1qnxRFma/rhEYsB3gYzvIJhno=; b=loKAriXcjyfvxtMlrfKL0KaAPZdS9nJX/IcHZPjn5sV3FR5oMeydk53IrjBqioCczh Q/ROS2ELKKg8w72TftbljVyPzBc8GaLGtaU6UB6Yh8KdPEA5XBz4jVvP5FlgcKdS+Tc4 CxOUkuHgyug5CYqyqbkH1h7fMbFD9ZEJZiZq10kfJc+hJ9ygeIckgdOtVEjPCuRbZ/Zt wZTJ0+eUsTKPWj+1gPvUy+3BGAtfBbiFrBpiS67y/uVLZRywf53L7j2rN6IHjBt6NmEk OTypyiSFYc9SYSyNcLaXtqMJ/XyzosGgQKe+Z7i5DbTewipWNYFcJLRyZBnDalZysmq8 t1ug== 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=Gecaf0JcIA0sdHt75M1qnxRFma/rhEYsB3gYzvIJhno=; b=tluo1oIUVEjFAHTMzmXIPN3MMGsVMnmsmisW5alF0WwASoeE3tjVL6YA+4+9Z0Cr3l Qm7eENhY9I/ohkMekign5Q/JjXSy5HWPvL019U2WGB3yFrxo/KRxlAFzSkzeLZelHVCn EeMRLU8TmA9uOgWU3KDNZdZfsYO1vyd9n+ZuSWNHGSAN6SNfoCz2QxJsr2Ms9Y/x+Mpq ZbWZE8PzARyOOcMSa2iAy+yfRNsP//eU2ey7xdjTexp1QtBhZ+XJbSmseD+WbZOHpqPV 8LT1g1Ew75X+IykfrRxVn4XICPAzjOXbLLp3SEPwJITnB6ALYG9vuBX9kuArHQpLrxIJ PIgQ== X-Gm-Message-State: AIkVDXLr6sbfunZtjkmG381SrEU6TK/ur2zrf3j6bAXA/OnjddDkIWGm5cx1cWjHiE4FVgdYHyvNwUrytzQTqw== X-Received: by 10.36.92.145 with SMTP id q139mr3176641itb.107.1484102870837; Tue, 10 Jan 2017 18:47:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.163.19 with HTTP; Tue, 10 Jan 2017 18:47:50 -0800 (PST) In-Reply-To: References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> From: tjw ietf Date: Tue, 10 Jan 2017 21:47:50 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1144b5c06d51d40545c8a0b3 Archived-At: Cc: Matthijs Mekking , dnsop Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:47:53 -0000 --001a1144b5c06d51d40545c8a0b3 Content-Type: text/plain; charset=UTF-8 Thanks Paul, and double thanks to Matthijs for his diligence in wisely forcing this. The new version is minor, but significant. I don't feel that it needs a new WGLC, but I want to put the diff between the two versions here so folks may take a second look. https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintai n-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt I'm going back over all the emails I have during the IETF LC process, just to make sure everything has been addressed. However, I think it's ready to move forward thanks tim On Tue, Jan 10, 2017 at 7:02 PM, Paul Wouters wrote: > On Tue, 10 Jan 2017, Paul Wouters wrote: > > Ohh, I think Matthijs actually found a bug: >> > > Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs > for being so persistent in bringing this up. My apologies that > I did not understand your concern before. > > Chairs, it is up to you to decide on redoing a LC on this or not. > > The diff between 04 and 06 that contains all changes since IETF LC: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintai > n-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt > > > Paul > --001a1144b5c06d51d40545c8a0b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Paul, and double thanks to Matthijs for his diligen= ce in wisely forcing this.

The new version is minor, but= significant.=C2=A0 I don't feel that it needs a new WGLC, but I want t= o put the diff between the two versions here so folks may take a second loo= k.=C2=A0



I'm= going back over all the emails I have during the IETF LC process, just to = make sure everything has been addressed.=C2=A0

How= ever, I think it's ready to move forward=C2=A0

thanks
tim


=

On Tue, Jan 10, 2= 017 at 7:02 PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 10 Jan 2017, Paul Wouters = wrote:

Ohh, I think Matthijs actually found a bug:

 Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs
for being so persistent in bringing this up. My apologies that
I did not understand your concern before.

Chairs, it is up to you to decide on redoing a LC on this or not.

The diff between 04 and 06 that contains all changes since IETF LC:

https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-d= nsop-maintain-ds-06.txt&url1=3Ddraft-ietf-dnsop-maintain-ds-0= 4.txt


Paul

--001a1144b5c06d51d40545c8a0b3-- From nobody Wed Jan 11 00:21:16 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 E9025129A89 for ; Wed, 11 Jan 2017 00:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 nF09E0_9YQLe for ; Wed, 11 Jan 2017 00:21:13 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 D8A4F129A6B for ; Wed, 11 Jan 2017 00:21:12 -0800 (PST) Received: from [IPv6:2001:981:19be:1:71e2:83f:d633:7f4e] (unknown [IPv6:2001:981:19be:1:71e2:83f:d633:7f4e]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id DA229B3E2 for ; Wed, 11 Jan 2017 09:21:10 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: dnsop@ietf.org References: <147792810754.32434.7815626160706350019.idtracker@ietfa.amsl.com> <11dd4e3d-3620-a478-cee5-6be4f9b9a141@pletterpet.nl> <04c6766e-87fe-9355-f651-633df6fe961e@pletterpet.nl> From: Matthijs Mekking Message-ID: <53d07221-46f4-9508-05a0-fb91af5bf8e0@pletterpet.nl> Date: Wed, 11 Jan 2017 09:21:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:21:15 -0000 Thanks, and my apologies for failing to express myself clearer in an earlier stage. If next to the Key Tag, Algorithm, Digest Type, the Digest MUST also be 0, there is no longer a change in record *format* and this line can/should be removed from the draft: This is a change in format from strict interpretation of [RFC7344] and may cause problems with some deployed software. Best regards, Matthijs On 11-01-17 03:47, tjw ietf wrote: > Thanks Paul, and double thanks to Matthijs for his diligence in wisely > forcing this. > > The new version is minor, but significant. I don't feel that it needs a > new WGLC, but I want to put the diff between the two versions here so > folks may take a second look. > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt > > > I'm going back over all the emails I have during the IETF LC process, > just to make sure everything has been addressed. > > However, I think it's ready to move forward > > thanks > tim > > > > On Tue, Jan 10, 2017 at 7:02 PM, Paul Wouters > wrote: > > On Tue, 10 Jan 2017, Paul Wouters wrote: > > Ohh, I think Matthijs actually found a bug: > > > Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs > for being so persistent in bringing this up. My apologies that > I did not understand your concern before. > > Chairs, it is up to you to decide on redoing a LC on this or not. > > The diff between 04 and 06 that contains all changes since IETF LC: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt > > > > Paul > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Thu Jan 12 02:06: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 62A2E1293F8; Thu, 12 Jan 2017 02:06:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148421561340.19370.14177452721086629843.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 02:06:53 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:06:53 -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-08.txt Pages : 16 Date : 2017-01-12 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. They will be removed 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-08 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 Thu Jan 12 10:41: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 58C5F129483 for ; Thu, 12 Jan 2017 10:41:02 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 USmK93HVPEKW for ; Thu, 12 Jan 2017 10:41:00 -0800 (PST) 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 346C8129435 for ; Thu, 12 Jan 2017 10:41:00 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so26418278qtg.3 for ; Thu, 12 Jan 2017 10:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=vbI7h8plXG36NRqAscN1yIGNbkZxwvoKy/FDqhkbBOo=; b=BcnrxPTHp1Ye0AzuWtvoyaXFnZEkZt22ngAGJMOEVMovReUjXzSa7/B13wZFFgV77P sFuMq1xZh6CIYiYWDUPQtqE2NP1WM0l4EJqXMAMmGL+g6ppVpL7T325BvPmDKR60wUMz QXXCv1dc84nQBN9w172T0KIM/Xrv0hMXTMeMO98TPHx7dpnHyqOsjDwCGIMLI7LN2xvt xyY3xqv1G1tbAyXAXyj8v2AMcGKm5US3o1Z8V1AKc71O9qNl/RbNfgMJdQwngICLocsw WndWAc2Vx9sqnd6OrxAVDtKcrZIVWulfeV/2oLvCqQc26thsGslgMig2VuLL8WS6pZZ9 x0dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=vbI7h8plXG36NRqAscN1yIGNbkZxwvoKy/FDqhkbBOo=; b=mRA3ry6RRGbhQr9iQ6El2YpVCViuGwEUDQgnA3bHA2QqvMkUdbqe6o2XB+lwr/+f4j U2xo/GDXd/XVeaZCY9IfxcJ+ATgjtDjiAhntbaLmTsMowXFB+jVvMWOzgd0xSsMWkg9m LMR0XYQKGHqy3TucJqNTQnDV0F4+V8Pia3NFXg0qpCvErXB/CK6yQuIZCFB3rbMXwhN/ VX2DidQuKi/RTi+36W/CRhW4o6x/xZo5IQK0jKGzDY9/BwXicj8GRA0I73l0WGp2FI1C yVksdXKEAGl/YJlEQ/emMh9l+NkWdIoRd4/KJ1kxuP9LUncHYaj9ljzRBhwcL5BdB7Hs pb7Q== X-Gm-Message-State: AIkVDXIwWR1s1TyZdgTJsQk59BQkFQjoGyV+J9thB6BrCMMzOk2TtYkedtyfitL1UY0MEw== X-Received: by 10.200.52.27 with SMTP id u27mr15404080qtb.26.1484246459132; Thu, 12 Jan 2017 10:40:59 -0800 (PST) Received: from [10.0.0.19] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id s65sm7290360qtd.2.2017.01.12.10.40.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 10:40:58 -0800 (PST) From: Suzanne Woolf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> Date: Thu, 12 Jan 2017 11:48:22 -0500 To: dnsop Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:41:02 -0000 Dear Colleagues, It's time to get back to our work on special use names. As the chairs = see it, here's what we need to do between now and IETF 98 (end of = March). We'll be having a DNSOP WG interim meeting shortly, see below. 1. We need to advance the problem statement document, = https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please = review and comment on the list. We'd like to have a WGLC on it before = IETF 98. 2. Now that we have a working problem statement, we'd like to see = proposals on possible changes to IETF procedures to resolve the issues = we've raised. We're looking for on-list discussion, preferably with = posted I-Ds. These proposals do not have to be limited to work for the DNSOP WG; they = may also include work we think belongs in other WGs, or requests to the = IESG or the IAB (such as liaison statements to groups outside of the = IETF). We have had a proposal, for the ALT TLD, before us for some time now, = which we put aside while we worked on the problem statement. As part of = assessing solutions, we need to review = https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determine = what the WG wants to do with it. Comments to the list, please. 3. We're scheduling an interim WG meeting during the week of January 30 = for further work on this topic. We'll provide some possible days/times = to the list for feedback shortly, and we can't promise to accomodate = everyone's schedule constraints but will do our best. best, Suzanne & Tim= From nobody Fri Jan 13 18:47: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 DBA171296DC for ; Fri, 13 Jan 2017 18:47:51 -0800 (PST) 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=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 zwd2eaaZrhMN for ; Fri, 13 Jan 2017 18:47:49 -0800 (PST) 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 136AD1296AA for ; Fri, 13 Jan 2017 18:47:49 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id v23so63988761qtb.0 for ; Fri, 13 Jan 2017 18:47:49 -0800 (PST) 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=yM1W2KRExlPYftV0dS53V8VHeGEG8jNAiIhYaOA9f50=; b=dG9GQ02Aoe8jZ2jDJn/tS4EbA2XzKs6SDeCF6TV4uNLmBBn5998ARQ2U1ySzmc00a+ X0qoltJE6Dmu6LQEMRrG5cHHdZ7sUck8+e7xbkXLSFicp0Q9tBAkYTcoPBhnN+NTTRlw NJ7rf1krmAXtLcAHtRC1uH6PjtGddS7UCTm8CBEzKOgDUwrpkHK+MA+08hKyNe2cfA+l x8J3rblnWfSF4boZpe0sJGO7ikJnXCenX+DVUTJrGXghanRtFlpxMw9lFFXeixukFoFH 9WTDGzHKI83kaD7+3zJpcwoVRaFTgY5NnRAjiTnxhjGerUppeWg0vY6Kbh2h7mskFOL3 HElg== 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=yM1W2KRExlPYftV0dS53V8VHeGEG8jNAiIhYaOA9f50=; b=C5xp0ISiy/e8zHayFS6+ifMaRM29irWnVs3kzkmNcUSBHPnLwFbVWtrlD6TEnACBzq BIKorUvjoauiL+Fm7K0INmBAVuFYH++mq0wykCPYmsjTUotdIV9q7j2zKlir1yPbzlFX Uwbbzl/Q2+uwAbzw7eQfMPxnlGBF7HXwxT1fkRBjF3yDFEvE0AzU+uVBMMt2wdsPH5JT ZWFjdfdSDpCq1fHR7AyMAw2onVIkGvZ8iWOQo9oCta5pq8/3pkFk1JRRhNfmiVsH9wCe EC/iRfQdIVg0rTTdSxfAZnbYb/PIZ22lQR+nPOiTiTguwAZQAF5mupvGogH1q+QD41D2 WpYQ== X-Gm-Message-State: AIkVDXKnSCgFdR8Rzyx7zF+1wtJNzKmtM1Gd15suhBQZBCGGIZWN7vQvDRZTmPpCDWzsQu1V8LGastLu+niRSBMo X-Received: by 10.237.34.116 with SMTP id o49mr14587174qtc.122.1484362068099; Fri, 13 Jan 2017 18:47:48 -0800 (PST) MIME-Version: 1.0 References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> In-Reply-To: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> From: Warren Kumari Date: Sat, 14 Jan 2017 02:47:37 +0000 Message-ID: To: Suzanne Woolf , dnsop Content-Type: multipart/alternative; boundary=001a113e7bf6c99a6f054604f98f Archived-At: Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 02:47:52 -0000 --001a113e7bf6c99a6f054604f98f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf wrote: > Dear Colleagues, > > > It's time to get back to our work on special use names. As the chairs see > it, here's what we need to do between now and IETF 98 (end of March). > We'll be having a DNSOP WG interim meeting shortly, see below. > > 1. We need to advance the problem statement document, > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please > review and comment on the list. We'd like to have a WGLC on it before IETF > 98. > > Some additional background. The ICANN SSAC (Security and Stability Advisory Committee) recently (Dec 22nd) published SAC090 - https://www.icann.org/en/system/files/files/sac-090-en.pdf (full disclosure: I'm an author). It is short, and easily readable -- I'd strongly encourage you to read it (but I'll provide some teasers to tempt you!). It notes that "a central authority to control the way in which domain names are used in all contexts-is both infeasible and undesirable given the robustly non-centralized way in which the Internet ecosystem evolves", and that a coordinated management of the namespace might be best. It also finds that uncoordinated use leads to ambiguity (and instability), and that currently ICANN and the IETF (and others) all allocate from a single namespace. It recommends that ICANN 1: create criteria for determining what labels can be TLDs. 2: figure out how to coordinate with a: the IETF declaring names as "special" (6761) and b: other "private use" names. This is a very quick summary, please go actually read it - there are only ~6 pages of actual content, but it recommends coordination with the IETF. So, please, let's try and get this moving -- I'd hate it if the IETF ends up looking more dysfunctional than ICANN :-P Also, ~3 days ago someone posted about .onion (and Special Use Names) on hackernews -- https://news.ycombinator.com/item?id=13370488 . This topic is still of interest to a bunch of people... > 2. Now that we have a working problem statement, we'd like to see > proposals on possible changes to IETF procedures to resolve the issues > we've raised. We're looking for on-list discussion, preferably with posted > I-Ds. > > These proposals do not have to be limited to work for the DNSOP WG; they > may also include work we think belongs in other WGs, or requests to the > IESG or the IAB (such as liaison statements to groups outside of the IETF). > > We have had a proposal, for the ALT TLD, before us for some time now, > which we put aside while we worked on the problem statement. As part of > assessing solutions, we need to review > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determine > what the WG wants to do with it. Comments to the list, please. > Yes please. The document is still parked, but please send me comments *on the draft* and I'll try keep track of them to incorporate. I know that there is much background which can be culled, I'll post a new version to GitHub with that done soon. W > > 3. We're scheduling an interim WG meeting during the week of January 30 > for further work on this topic. We'll provide some possible days/times to > the list for feedback shortly, and we can't promise to accomodate > everyone's schedule constraints but will do our best. > > > best, > Suzanne & Tim > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a113e7bf6c99a6f054604f98f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , Jan 12, 2017 at 1:41 PM Suzanne Woolf <suzworldwide@gmail.com> wrote:
Dear Colleagues,


It's time to get back to our work on special use names. As the chairs s= ee it, here's what we need to do between now and IETF 98 (end of March)= .=C2=A0 We'll be having a DNSOP WG interim meeting shortly, see below.<= br class=3D"gmail_msg">
1. We need to advance the problem statement document, https://datatracker.ietf.org/doc/draft-iet= f-dnsop-sutld-ps/. Please review and comment on the list. We'd like= to have a WGLC on it before IETF 98.


Some additional ba= ckground.
The ICANN SSAC (Security and Stability Advisory Committ= ee) recently (Dec 22nd) published SAC090 -=C2=A0https://www.icann.org/en/system= /files/files/sac-090-en.pdf=C2=A0(full disclosure: I'm an author).<= /div>

It is short, and easily readable -- I'd strong= ly encourage you to read it (but I'll provide some teasers to tempt you= !).
It notes that "a central authority to control the wa= y in which domain names are used in all contexts-is both infeasible and und= esirable given the robustly non-centralized way in which the Internet ecosy= stem evolves", and that a coordinated management of the namespace migh= t be best.=C2=A0
It also finds that uncoordinated use leads to am= biguity (and instability), and that currently ICANN and the IETF (and other= s) all allocate from a single namespace.
It recommends that ICANN=
1: create criteria for determining what labels can be TLDs.
2: figure out how to coordinate with a: the IETF declaring names as &= quot;special" (6761) and b: other "private use" names.=C2=A0=

This is a very quick summary, please go actually = read it - there are only ~6 pages of actual content, but it recommends coor= dination with the IETF. So, please, let's try and get this moving -- I&= #39;d hate it if the IETF ends up looking more dysfunctional than ICANN :-P=


Also, ~3 days ago someone posted a= bout .onion (and Special Use Names) on hackernews --=C2=A0https://news.ycombinator.com/ite= m?id=3D13370488=C2=A0. This topic is still of interest to a bunch of pe= ople...

=C2=A0
2. Now that we have a working problem statement, we'd like to see propo= sals on possible changes to IETF procedures to resolve the issues we've= raised. We're looking for on-list discussion, preferably with posted I= -Ds.

These proposals do not have to be limited to work for the DNSOP WG; they ma= y also include work we think belongs in other WGs, or requests to the IESG = or the IAB (such as liaison statements to groups outside of the IETF).

We have had a proposal, for the ALT TLD, before us for some time now, which= we put aside while we worked on the problem statement. As part of assessin= g solutions, we need to review https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and= determine what the WG wants to do with it. Comments to the list, please.

Yes please. The docu= ment is still parked, but please send me comments *on the draft* and I'= ll try keep track of them to incorporate. I know that there is much backgro= und which can be culled, I'll post a new version to GitHub with that do= ne soon.

W
=C2=A0

3. We're scheduling an interim WG meeting during the week of January 30= for further work on this topic. We'll provide some possible days/times= to the list for feedback shortly, and we can't promise to accomodate e= veryone's schedule constraints but will do our best.


best,
Suzanne & Tim
_______________________________________________
DNSOP mailing list
DNS= OP@ietf.org
https://www.ietf.org/mailman/listinfo= /dnsop
--001a113e7bf6c99a6f054604f98f-- From nobody Mon Jan 16 17:22: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 E49C7129519 for ; Mon, 16 Jan 2017 17:22:36 -0800 (PST) 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=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 FZycHg7LGOiw for ; Mon, 16 Jan 2017 17:22:34 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 C09B7128B38 for ; Mon, 16 Jan 2017 17:22:33 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id l7so131643227qtd.1 for ; Mon, 16 Jan 2017 17:22:33 -0800 (PST) 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=RrtPl7vaGJ9QrgCZNbgK12whdtwg/31cIZKt74VQu3Y=; b=j6/bH6gje/L0+k9B9r+Tk3zzO1Lg8mlDTfumZM+e0dakkV26P0UWJNs6gCSYOx6Z9s CyT8DVREMT3fvdPDx8mQr9LYRdKnoKH6KgrR+fzQa4DaenaDISRI+MD6IC+5NBSxaQxT 55k6dFTRph/U5NCZZ5uyunucxqKAA2M4EZZk1qIQjyYOCFqNpQEMWwj6irPOQnyLTjG5 WLZvIMbAf8VOeC6ffBA01/ArXb9t+8En13axew1l0k9jdy3Q3nr12/7IHXAeMGVlVpR2 khlwJhDS5Ibg/FuEk4bDng3IRyKclco+Eacs2pbEm1AMmlM4Y2kxqnk+Qz/6EMIf+B7L NwRw== 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=RrtPl7vaGJ9QrgCZNbgK12whdtwg/31cIZKt74VQu3Y=; b=HiSGvcq1DMaa26jSdN9E7QR87v6DO4mYIBj2MnzP2Z8iV6wUImNF3nTZNptm05IT3n PvkRHDrjVKeK0Xw3Dm3SSQSQLW+Jp3LyAUgGZfhp0IEp1Ayd2acxEF42MrH4pOKxwFc1 yaTXPzVyOKnDKfvgwqhDyKvt8tQkKd7Ou6y1mEcDbOTYgmYogV3GPIGskCBjfxm6ZVvl 9vQu/Jzf0GrV7DaOujgv693fBiChb4cnWO/k5UIUyRYZNqVmcYP4yrAVjbISs+MvWb11 O2S7gfDosa/FG1I8Sr/zKobPI/lE5TLtegUZIgn+EqizxsBIKGePyMxBDg1heP7A7t6l /YSA== X-Gm-Message-State: AIkVDXKf6xRHGGmi+lQvJGUdVoniTtQ6ctbOcVaAmbzBlizURwUpoxILhdXn/5l7oJSyfaAWuxhSH3IyE+9D8Xsg X-Received: by 10.237.38.65 with SMTP id z59mr26068548qtc.5.1484616152568; Mon, 16 Jan 2017 17:22:32 -0800 (PST) MIME-Version: 1.0 References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> In-Reply-To: From: Warren Kumari Date: Tue, 17 Jan 2017 01:22:22 +0000 Message-ID: To: Suzanne Woolf , dnsop Content-Type: multipart/alternative; boundary=94eb2c122e5867064805464022d3 Archived-At: Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:22:37 -0000 --94eb2c122e5867064805464022d3 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 9:47 PM Warren Kumari wrote: > On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf > wrote: > > Dear Colleagues, > > > It's time to get back to our work on special use names. As the chairs see > it, here's what we need to do between now and IETF 98 (end of March). > We'll be having a DNSOP WG interim meeting shortly, see below. > > 1. We need to advance the problem statement document, > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please > review and comment on the list. We'd like to have a WGLC on it before IETF > 98. > > > Some additional background. > The ICANN SSAC (Security and Stability Advisory Committee) recently (Dec > 22nd) published SAC090 - > https://www.icann.org/en/system/files/files/sac-090-en.pdf (full > disclosure: I'm an author). > > It is short, and easily readable -- I'd strongly encourage you to read it > (but I'll provide some teasers to tempt you!). > It notes that "a central authority to control the way in which domain > names are used in all contexts-is both infeasible and undesirable given the > robustly non-centralized way in which the Internet ecosystem evolves", and > that a coordinated management of the namespace might be best. > It also finds that uncoordinated use leads to ambiguity (and instability), > and that currently ICANN and the IETF (and others) all allocate from a > single namespace. > It recommends that ICANN > 1: create criteria for determining what labels can be TLDs. > 2: figure out how to coordinate with a: the IETF declaring names as > "special" (6761) and b: other "private use" names. > > This is a very quick summary, please go actually read it - there are only > ~6 pages of actual content, but it recommends coordination with the IETF. > So, please, let's try and get this moving -- I'd hate it if the IETF ends > up looking more dysfunctional than ICANN :-P > > > Also, ~3 days ago someone posted about .onion (and Special Use Names) on > hackernews -- https://news.ycombinator.com/item?id=13370488 . This topic > is still of interest to a bunch of people... > > > > 2. Now that we have a working problem statement, we'd like to see > proposals on possible changes to IETF procedures to resolve the issues > we've raised. We're looking for on-list discussion, preferably with posted > I-Ds. > > These proposals do not have to be limited to work for the DNSOP WG; they > may also include work we think belongs in other WGs, or requests to the > IESG or the IAB (such as liaison statements to groups outside of the IETF). > > We have had a proposal, for the ALT TLD, before us for some time now, > which we put aside while we worked on the problem statement. As part of > assessing solutions, we need to review > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determine > what the WG wants to do with it. Comments to the list, please. > > > Yes please. The document is still parked, but please send me comments *on > the draft* and I'll try keep track of them to incorporate. I know that > there is much background which can be culled, I'll post a new version to > GitHub with that done soon. > ... and I just posted a new version at https://github.com/wkumari/draft-wkumari-dnsop-alt-tld Please take a look and provide any feedback. This document has been in limbo for a really long time - I apologize if I have forgotten any of the comments -- please resend, or just provide pointers to the emails and I'll go reread them. We *know* that this doesn't solve everyone's issues, but, had it existed, it may have provided an option for e.g homenet.alt. Also, we will need to decide what to do about the insecure delegation question -- .onion didn't need one, but perhaps we do? This will add an interesting wrinkle to the whole "coordination with ICANN" discussion. > > W > > > > 3. We're scheduling an interim WG meeting during the week of January 30 > for further work on this topic. We'll provide some possible days/times to > the list for feedback shortly, and we can't promise to accomodate > everyone's schedule constraints but will do our best. > > Interim WG meetings must be announced at least four weeks before the meeting -- RFC 2418 section 3.1 and https://www.ietf.org/iesg/statement/interim-meetings.html. When I initially read the above I figured you might mean a *virtual* interim, but remembered some discussion on this from the Seoul meeting, and so went to the recordings to check - https://www.youtube.com/watch?v=13pGB24g--k#t=6m52s Suzanne: "Worth noting that, as the IESG pointed out today, future progress does not need to wait on a final version of a problem statement document, but we did want to get one adopted and relatively supported before we moved on. If people have forgotten, the alt-tld document that was parked pending a problem statement. We will be looking if it is time to unpark that. We won't be discussing this topic further today. But we are planning an interim in a few weeks that will attempt to sort out possible recommendations, if any, for further action. Now that we have a problem statement and active effort on it. But that's the status of that topic -- we haven't abandoned it, frankly we can't; we promised the IETF that we would say something, even if it's "We don't know what to say". But there has been progress, and we're not talking about it further today." Terry Manderson: "Wearing my IntAD hat, responsible AD for Homenet. Please be aware that there will be a 6761 app coming forward rapidly, and you may want to prioritize within that space please." Paul Hoffman (DNSOP secretary): "Wearing my process weenie hat; you know you have to wait 4 weeks between announcing when an interim is, and when is. Now you are pushing towards xmas" Suzanne Woolf: "Or even New Years" Tim: "Or even New Years. I should have said probably after the 1st. I didn't realize it was already the middle of November" Suzanne: Key point is that we are not waiting till Chicago before we do anything else with this, but it's not immediate either". So, from this exchange, I'm assuming that this is actually a real interim; this makes sense, because the topic feels like it requires a real interim - handling this level of discussion on a confernce call / webex would be very challenging, and would defeat much of the point -- we need actual face-to-face discussion. 4 weeks from now is, I believe, the week for Feb 13th -- I was hoping that the interim could be colocated with a meeting where many of the standard set of people would be anyway (to cut down on travel costs, and possibly take advantage of existing hotel / conference space availability (many times sponsors get the use of a conference room at a location)). Unfortunately NANOG is the week of Feb 5th (too early), NDSS (2017-02-26 - 2017-03-01) may be a possibility, and at least *some* of the usual folk will be there. ICANN (2017-03-11 - 2017-03-17, Copenhagen) could be a possibility, but that is getting close to IETF 98 (2017-03-26 - 2017-03-31). Assuming that this is a real (not virtual) meeting I *may* be able to provide space in NYC; Mountain View; Reston, VA (15 min from IAD); London; or Zurich. W best, > Suzanne & Tim > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --94eb2c122e5867064805464022d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , Jan 13, 2017 at 9:47 PM Warren Kumari <warren@kumari.net> wrote:
On Thu, Jan 12, 2017 at 1:41 PM Suz= anne Woolf <suzworldwide@gmail.com> wrote:
Dear Colleagues,


It's time to get back to our work on special use names. As the chairs s= ee it, here's what we need to do between now and IETF 98 (end of March)= .=C2=A0 We'll be having a DNSOP WG interim meeting shortly, see below.<= br class=3D"gmail_msg">
1. We need to advance the problem statement document, https://datatracker.ietf.org/doc/draft-iet= f-dnsop-sutld-ps/. Please review and comment on the list. We'd like= to have a WGLC on it before IETF 98.


Some additional backgr= ound.
The ICANN SSAC (Security and Stability = Advisory Committee) recently (Dec 22nd) published SAC090 -=C2=A0https://www.icann.org/en/system/files/files/sac-090-= en.pdf=C2=A0(full disclosure: I'm an author).

It is short= , and easily readable -- I'd strongly encourage you to read it (but I&#= 39;ll provide some teasers to tempt you!).
It notes that "a central authority to control th= e way in which domain names are used in all contexts-is both infeasible and= undesirable given the robustly non-centralized way in which the Internet e= cosystem evolves", and that a coordinated management of the namespace = might be best.=C2=A0
It also finds that uncoo= rdinated use leads to ambiguity (and instability), and that currently ICANN= and the IETF (and others) all allocate from a single namespace.
It recommends that ICANN
= 1: create criteria for determining what labels can be TLDs.
2: figure out how to coordinate with a: the IETF declaring n= ames as "special" (6761) and b: other "private use" nam= es.=C2=A0

This is a very quick summary, please go actually read i= t - there are only ~6 pages of actual content, but it recommends coordinati= on with the IETF. So, please, let's try and get this moving -- I'd = hate it if the IETF ends up looking more dysfunctional than ICANN :-P
=


Also, ~3 days a= go someone posted about .onion (and Special Use Names) on hackernews --=C2= =A0https://news.ycombinator.com/item?id=3D13370488=C2=A0. This topic is still of interest to a bunch of people...

=C2=A0
2. Now that we have a working problem statement, we'd like to see propo= sals on possible changes to IETF procedures to resolve the issues we've= raised. We're looking for on-list discussion, preferably with posted I= -Ds.

These proposals do not have to be limited to work for the DNSOP WG; they ma= y also include work we think belongs in other WGs, or requests to the IESG = or the IAB (such as liaison statements to groups outside of the IETF).

We have had a proposal, for the ALT TLD, before us for some time now, which= we put aside while we worked on the problem statement. As part of assessin= g solutions, we need to review https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and= determine what the WG wants to do with it. Comments to the list, please.

Yes please. The documen= t is still parked, but please send me comments *on the draft* and I'll = try keep track of them to incorporate. I know that there is much background= which can be culled, I'll post a new version to GitHub with that done = soon.

... and I just post= ed a new version at=C2=A0https://github.com/wkumari/draft-wkumari-dnsop-alt-tld=

Please take a look and provide any feedback.
This document has been in limbo for a really long time - I apologize = if I have forgotten any of the comments -- please resend, or just provide p= ointers to the emails and I'll go reread them.

We *know* that this doesn't solve everyone's issues, but, had it e= xisted, it may have provided an option for e.g homenet.alt. Also, we will n= eed to decide what to do about the insecure delegation question -- .onion d= idn't need one, but perhaps we do? This will add an interesting wrinkle= to the whole "coordination with ICANN" discussion.
=C2= =A0

W
=C2=A0

3. We're scheduling an interim WG meeting during the week of January 30= for further work on this topic. We'll provide some possible days/times= to the list for feedback shortly, and we can't promise to accomodate e= veryone's schedule constraints but will do our best.

Interim WG m= eetings must be announced at least four weeks before the meeting --=C2=A0RF= C 2418 section 3.1 and=C2=A0https://www.ietf.org/iesg/statement/interim-meetings= .html.=C2=A0
When I initially read the above I figured you mi= ght mean a *virtual* interim, but remembered some discussion on this from t= he Seoul meeting, and so went to the recordings to check -=C2=A0https://www.youtub= e.com/watch?v=3D13pGB24g--k#t=3D6m52s

Suz= anne: "Worth noting that, as the IESG pointed out today, future progre= ss does not need to wait on a final version of a problem statement document= , but we did want to get one adopted and relatively supported before we mov= ed on. If people have forgotten, the alt-tld document that was parked pendi= ng a problem statement. We will be looking if it is time to unpark that.=C2= =A0
We won't be discussing this topic further today.=C2=A0
But we are planning an interim in a few weeks that will attempt to = sort out possible recommendations, if any, for further action. Now that we = have a problem statement and active effort on it. But that's the status= of that topic -- we haven't abandoned it, frankly we can't; we pro= mised the IETF that we would say something, even if it's "We don&#= 39;t know what to say".=C2=A0
But there has been progress, a= nd we're not talking about it further today."

=
Terry Manderson: "Wearing my IntAD hat, responsible AD for Homene= t. Please be aware that there will be a 6761 app coming forward rapidly, an= d you may want to prioritize within that space please."

=
Paul Hoffman (DNSOP secretary): "Wearing my process weenie = hat; you know you have to wait 4 weeks between announcing when an interim i= s, and when is. Now you are pushing towards xmas"

=
Suzanne Woolf: "Or even New Years"
Tim: "Or e= ven New Years. I should have said probably after the 1st. I didn't real= ize it was already the middle of November"
Suzanne: Key poin= t is that we are not waiting till Chicago before we do anything else with t= his, but it's not immediate either".

So, from this exchange, I'm assuming that this is actually a real int= erim; this makes sense, because the topic feels like it requires a real int= erim - handling this level of discussion on a confernce call / webex would = be very challenging, and would defeat much of the point -- =C2=A0we need ac= tual face-to-face discussion. =C2=A0
4 weeks from now is, I belie= ve, the week for Feb 13th -- I was hoping that the interim could be colocat= ed with a meeting where many of the standard set of people would be anyway = (to cut down on travel costs, and possibly take advantage of existing hotel= / conference space availability (many times sponsors get the use of a conf= erence room at a location)).=C2=A0
Unfortunately NANOG is the wee= k of Feb 5th (too early), NDSS (2017-02-26 - 2017-03-01)=C2=A0may be a possibi= lity, and at least *some* of the usual folk will be there. ICANN (2017-03-11 - 2= 017-03-17, Copenhagen) could be a possibility, but that is getting close to= IETF 98 (2017-03-26 - 2017-03-31).
Assuming that this is a = real (not virtual) meeting I *may* be able to provide space in NYC; Mountai= n View; Reston, VA (15 min from IAD); London; or Zurich.
=
<= /span>
W


best,
Suzanne & Tim
_______________________________________________
DNSOP mailing list
DNS= OP@ietf.org
https://www.ietf.org/mailman/listinfo= /dnsop
--94eb2c122e5867064805464022d3-- From nobody Tue Jan 17 06:31: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 C6D2012952B for ; Tue, 17 Jan 2017 06:31:16 -0800 (PST) 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_00=-1.9, 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 YI1GB3LPRgKx for ; Tue, 17 Jan 2017 06:31:08 -0800 (PST) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 C6AD6129521 for ; Tue, 17 Jan 2017 06:31:07 -0800 (PST) Received: by mail-yw0-x244.google.com with SMTP id 17so11686564ywk.2 for ; Tue, 17 Jan 2017 06:31:07 -0800 (PST) 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=ZYIJyS/BYHmJnCd38v12dpoVSGWWMrOSWfXJpKuGf8A=; b=Vm6Y3iMDfrwboq9qDqP1dcnWh5cG69T3ATvsun7rWH9FV6PvkpHLlBLFzt0PhjHhPZ QagQF6p4F50kQGAnUdq4xMSEtQM7noXqzgGldoozzotYYA0NJyxsGXs4mzxY6nKQH6g5 6W78yDgCLq6CSU/FjrKeT/QIDXxvgpXUorjJHDIDDTdgvRTllheUPucO0LYKE8kty5yy i4foA3dIsRFinwLXI/X9TvCLa675mdPZuqIyA/0/INp1h8kbasKKpzwI1FSSvNQCKRQV 1g7Xrwyd/SLUf1TRaeRyc8Y/KqEsqqOwz4YFFE0UblrZhiDA12vOIGSQDT+Z4k5i4YpW aBXA== 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=ZYIJyS/BYHmJnCd38v12dpoVSGWWMrOSWfXJpKuGf8A=; b=KMyml0fJmjpGxKiZykYTNvHuGzZsc6+WUI6RDuYbQRF8N+9qKlvdapjct2Kppu20yz xFDBO5L9JJj0uVzBQf4IvDKDuiMExP7hauP8hY2OTq+oOO1Wg3dkjg3KrdVuS9+Uq5aR VH1V4El5Uvirh6zZuhyRMwoPNvLq51ug6hN5rLULi5Xr/xwACD3Do5fvUkohZQN02s7H xeCViUO4ceP0GeXObmeoNdRuE6HvDC/8Ny/aj1Sop/n1yzhBFVqwu+/Zh20BdhLc8F+i DpdcV2bqFTHRPTp/l80DavJd3oYZ/heSAExrOzuS5YESN+dFj9R+jO1VmmcCwO/Dp0Mp NR4g== X-Gm-Message-State: AIkVDXLbwOAjqvmjNSIukf/qqCpr35DAV6KdHDJrujmCjZTwt+b20AzhZzC66J2pv20al6/PA47PnpC2cn2mJEmo X-Received: by 10.129.110.133 with SMTP id j127mr30171897ywc.214.1484663466951; Tue, 17 Jan 2017 06:31:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.169.130 with HTTP; Tue, 17 Jan 2017 06:31:06 -0800 (PST) In-Reply-To: References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> From: Bob Harold Date: Tue, 17 Jan 2017 09:31:06 -0500 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11492a148f341105464b2665 Archived-At: Cc: dnsop Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:31:17 -0000 --001a11492a148f341105464b2665 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 8:22 PM, Warren Kumari wrote: > > On Fri, Jan 13, 2017 at 9:47 PM Warren Kumari wrote: > >> ... >> >> We have had a proposal, for the ALT TLD, before us for some time now, >> which we put aside while we worked on the problem statement. As part of >> assessing solutions, we need to review https://datatracker.ietf.org/ >> doc/draft-ietf-dnsop-alt-tld/ and determine what the WG wants to do with >> it. Comments to the list, please. >> >> >> Yes please. The document is still parked, but please send me comments *on >> the draft* and I'll try keep track of them to incorporate. I know that >> there is much background which can be culled, I'll post a new version to >> GitHub with that done soon. >> > > ... and I just posted a new version at https://github.com/wkumari/ > draft-wkumari-dnsop-alt-tld > > Please take a look and provide any feedback. > This document has been in limbo for a really long time - I apologize if I > have forgotten any of the comments -- please resend, or just provide > pointers to the emails and I'll go reread them. > > We *know* that this doesn't solve everyone's issues, but, had it existed, > it may have provided an option for e.g homenet.alt. Also, we will need to > decide what to do about the insecure delegation question -- .onion didn't > need one, but perhaps we do? This will add an interesting wrinkle to the > whole "coordination with ICANN" discussion. > >> W > In this section: 4.1. Domain Name Reservation Considerations 3. In general, writers of name resolution APIs and libraries do not need to perform special handing of these names. If developers of other namespaces implement their namespace through a "shim" or library, they will need to intercept and perform their own handling. -- I was hoping that name resolution APIs and libraries would be encouraged to filter out these names. So that over time all the major OS versions would filter them for privacy. That would greatly reduce the chances of them reaching DNS if accidentally used on a device that is not expecting them. -- Bob Harold --001a11492a148f341105464b2665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 16, 2017 at 8:2= 2 PM, Warren Kumari <warren@kumari.net> wrote:

On Fri, Jan 13, 2017 a= t 9:47 PM Warren Kumari <warren@kumari.net> wrote:
...

We have had a proposal, for the ALT TLD, before us for some time now, which= we put aside while we worked on the problem statement. As part of assessin= g solutions, we need to review https://datatracker.ietf.org/doc/d= raft-ietf-dnsop-alt-tld/ and determine what the WG wants to do with it.= Comments to the list, please.

Yes please. The document is still parked, but please = send me comments *on the draft* and I'll try keep track of them to inco= rporate. I know that there is much background which can be culled, I'll= post a new version to GitHub with that done soon.

... and I just posted a new version at=C2= =A0https://github.com/wkumari/draft-wkumari-dnsop-alt-tld

>>= ; W

<= br>4.1. Domain Name Reservation Considerations
3. In general, writers of= name resolution APIs and libraries do not
=C2=A0 =C2=A0 =C2=A0 =C2=A0ne= ed to perform special handing of these names.=C2=A0 If developers of
=C2= =A0 =C2=A0 =C2=A0 =C2=A0other namespaces implement their namespace through = a "shim" or
=C2=A0 =C2=A0 =C2=A0 =C2=A0library, they will need= to intercept and perform their own
=C2=A0 =C2=A0 =C2=A0 =C2=A0handling.=

-- I was hoping that name resolutio= n APIs and libraries would be encouraged to filter out these names.=C2=A0 S= o that over time all the major OS versions would filter them for privacy.= =C2=A0 That would greatly reduce the chances of them reaching DNS if accide= ntally used on a device that is not expecting them.

--=C2=A0
Bob Harold

--001a11492a148f341105464b2665-- From nobody Tue Jan 17 14:47:58 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 DD6471293F3; Tue, 17 Jan 2017 14:47:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148469327590.32003.5771896041307729413.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 14:47:55 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:47: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 : Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) Authors : Duane Wessels Warren Kumari Paul Hoffman Filename : draft-ietf-dnsop-edns-key-tag-04.txt Pages : 12 Date : 2017-01-17 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust (see Section 1.1 for the rationale). The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-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 Thu Jan 19 10:51: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 1F36212952D for ; Thu, 19 Jan 2017 10:51:45 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jbRl75f-RoF6 for ; Thu, 19 Jan 2017 10:51:36 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 5BFF312951F for ; Thu, 19 Jan 2017 10:51:36 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id i68so43231578uad.0 for ; Thu, 19 Jan 2017 10:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=QdnIXdk8S/klKMrBlALHQDhhDvpQDRmz/yWaHKc+VNE=; b=ua1XH0YppkSemRKNIcbZniT0eSw54FXuQuJhmzhRoRy9nPkdZlN0h7NNDtyf6+7q/J r1uM7jWYT3Nn6tsu1VdqjoWn7Jr0CtZcVrJFRxUrxJVpJFil41cQY5i9gPKqxtQvHfb2 AxswKFrQ6uev7kbko6aaDrM+fZiCTBx9XIq/lW2FfYvGaDH5kEl7PvucBdyiwvkTa2GV JyFlI9WFRev5xv5tPGHImPF1IrelfV1WkMIAZyDtyNV4UePqTBa20pIwZOe2M1NI6s3G htBmbYcvolQq9dmtFk04X4PlUIqNMd/ZxXwM2FCnv1J7SJ9+Dqv4sPtdf3paVLvWQxk4 DO/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=QdnIXdk8S/klKMrBlALHQDhhDvpQDRmz/yWaHKc+VNE=; b=Pgt2YYfzhFUm0s9o7bTVhfM/jHcz1Bavq59EzPEWV1VmHX4goPn4+YaEJU8Av72q37 nQP7w++k3e5Wk/c5+nZWpS2C3bjld6jXGhB/3VcDz4WXkdr5+DbX1ZAIvXAFk/rkkg6o EIjzwk5lbJvmj5b3exTkkstcJx64iRhVf+WXRRgi5IIXO3nwkSshPW1t3bWTs5Ip1+Dt CW5+zB/R7VypiGZLFvLpqAMSanCNOvRZML6/9EcW2nwTs5nwNTjHJCdIxAFhEhfPgip8 QsSjZgr5wO7ZeNcw0Hv3gbfWpoyb8bIH49K02Cr34QZr/gGh+e93hZXSOuRWl0XTLgbG trGQ== X-Gm-Message-State: AIkVDXIefwBXTQXa4qhAdxpRFPXmHXSHIFpmXhc9GkKRtXwY43XsYVB63Tf/rWaxlOzl9w== X-Received: by 10.200.54.86 with SMTP id n22mr9695321qtb.254.1484851895038; Thu, 19 Jan 2017 10:51:35 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 127sm3028744qkd.3.2017.01.19.10.51.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 10:51:34 -0800 (PST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_E43416B8-AF12-4886-AD20-9C3F17A538E8" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <02D05E11-F351-405F-8E25-8DC529425FF2@fugue.com> Date: Thu, 19 Jan 2017 13:51:33 -0500 To: dnsop X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [DNSOP] draft-ietf-dnsop-terminology-bis and "recursive resolver" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:51:45 -0000 --Apple-Mail=_E43416B8-AF12-4886-AD20-9C3F17A538E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm updating a document for another working group, and Ralph Droms in = his last call comments on that document asked me to use "recursive = resolver" instead of "caching name server", referencing = draft-ietf-dnsop-terminology-bis. That document doesn't actually = define "recursive resolver," but instead "full service resolver," which = means almost, but not quite, the same thing. The document does use the = term "recursive resolver" fairly liberally despite there not being a = definition for it. Given that "recursive resolver" is in such common = use, including in this document, I think the document should include a = definition for "recursive resolver". To me, it would make sense to say that a recursive resolver is a = resolver that acts in recursive mode. We would expect it to do = caching, which would make it a full-service resolver, but it might not. --Apple-Mail=_E43416B8-AF12-4886-AD20-9C3F17A538E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I'm = updating a document for another working group, and Ralph Droms in his = last call comments on that document asked me to use "recursive resolver" = instead of "caching name server", referencing = draft-ietf-dnsop-terminology-bis.   That document doesn't actually = define "recursive resolver," but instead "full service resolver," which = means almost, but not quite, the same thing.   The document does = use the term "recursive resolver" fairly liberally despite there not = being a definition for it.   Given that "recursive resolver" is in = such common use, including in this document, I think the document should = include a definition for "recursive resolver".

To me, it would make sense to say that a recursive resolver = is a resolver that acts in recursive mode.   We would expect = it to do caching, which would make it a full-service resolver, but it = might not.

= --Apple-Mail=_E43416B8-AF12-4886-AD20-9C3F17A538E8-- From nobody Mon Jan 23 10:20: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 B3FB9129706 for ; Mon, 23 Jan 2017 10:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 qx8_Df6FlG_f for ; Mon, 23 Jan 2017 10:20:55 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (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 4AB741296FD for ; Mon, 23 Jan 2017 10:20:55 -0800 (PST) Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id v0NIKroF008196 for ; Mon, 23 Jan 2017 13:20:54 -0500 (EST) Date: Mon, 23 Jan 2017 13:20:52 -0500 From: Rich Kulawiec To: dnsop@ietf.org Message-ID: <20170123182052.GA12543@gsp.org> 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] DNSOP Call for Adoption draft-vixie-dns-rpz X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:20:58 -0000 I've been following this discussion and have taken a few weeks to think about the comments rendered here in some depth. I find that I most agree with this statement: On Tue, Dec 20, 2016 at 10:53:39PM +0000, Warren Kumari wrote: > I believe that RPZ (and the DNS lies which it creates) is evil -- > unfortunately we live in a world where this is a necessary evil. I started studying the use of domains by spammers 15 years ago. I expanded that study to phishers, typosquatters, domaineers, malware distributors, etc. as it became excruciatingly clear that these are quite often the same people or operations. (See "Sanford Wallace" for one of the canonical examples.) It's become clear to me that most Internet domains are malicious. In the new TLDs, "most" asymptotically approaches "all". ( If anyone doubts this, and you shouldn't unless you've done your own homework, I'll be happy to show you some sample data. Or you can spend your morning coffee time for the next week idly perusing new additions to zone files at https://domainpunch.com/tlds/daily.php and get the flavor of it for yourself. Popular this month: domains being used by boiler room fake technical support operations who make phone calls designed to convince users to handle over control of their systems. They're being registered much faster than I can track them. [1] ) This shouldn't surprise anyone who has even dabbled in the area. Abusers register domains by the tens or hundreds of thousands, burn through them, then register more. Registrars are happy to have high-volume repeat customers, so while they may make a pretense of responsibility by suspending a domain here or there, these are meaningless gestures designed to placate complainers and support maintenance of a facade of responsibility. And in the extremely rare cases where registrars fire a client, there are plenty of others ready to welcome them with open arms. The situation is so bad that I think it's a best practice in mail system operations to block quite a few of the new TLDs outright in MTAs and make exceptions for specific domains if/when the need arises. But even if that's done, it's an insufficient defense mechanism. We need a way to make huge numbers of domains effectively disappear from users' view of the Internet -- and this may be it. I don't like it. This is not the Internet I would have chosen. But I'm not the entity who has allowed registrars to profit handsomely off the Internet's collective misery for a couple of decades, or the entity who handed them a whole new way to do so by unleashing hundreds of TLDs for which there is precisely zero need and precisely zero legitimate purpose, or the entity which let them start obfuscating registration data -- one of the best things that's ever happened to operators of malicious domains. ---rsk [1] Here's a single data point, out of a huge number: http://www.firemountain.net/~rsk/online.txt Those are *some* of the domains registered by one registrant in one TLD in one day. It's thus a speck on a microscopic speck, but I assure you it's representative. From nobody Wed Jan 25 06:42: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 B4000129971 for ; Wed, 25 Jan 2017 06:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 j_2Ps0BCX0pd for ; Wed, 25 Jan 2017 06:41:59 -0800 (PST) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 CB13C12996E for ; Wed, 25 Jan 2017 06:41:58 -0800 (PST) Received: by mail-qk0-x242.google.com with SMTP id e1so10479600qkh.1 for ; Wed, 25 Jan 2017 06:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=syOk1H/lLKRBvqNZwwwZcVr7JSqIwggFF9oOcG24brI=; b=UYytjBPAPFf3Uifm5pIbP/Hc0J5SfGddgmdAOFjVfFIBl1vLN+u7Z3JVyvTWlNlTow GRIVXIhlgusU9SWSYg11pI7Y4coK4E+YXyujdxfhuBRTFG9JWeVDaC8DA/9KLFFhjrvL E1zTo9BAc1FS/2bn9H5RAKUcLQLulNCK+i0waXBJKrraIrcXkMxXYsO59p8a46AOTqkV HAMxntjoR+A0rHvMikULcF6BL6/hOaL+wH8/WzoAWMYqKxDeJqZQpfHu2bCVQTR0tsz7 2cR+grxZn5EiVMLl4ZQn1CremzN3QXrU+Rzgq0+keLBzD0pnw/ewkv7jgpQ8bqpJo5MU 5Oyw== 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=syOk1H/lLKRBvqNZwwwZcVr7JSqIwggFF9oOcG24brI=; b=tscMZAkbTM2HIi+2Chr6iZAh/9/I/FLvUBj2/mzs2DsN0kifFTeYGwCq80FMGY9J0r I/Yc/vMZ/oHukG9tDF6tMPyuoy4ZKJ/JGieQAhI7k4rqAWXqdLG6WhLJ7dBC/yh+97S2 6/O6b0DNmBXj359tPhIYmUDiGMbJSiCX/q1Ps4FuQG50xaEszQ5cwcKk0XQQZqY61MKn Sv7/blZ1UdbuQ9GEV+y0O1NptQbc8IroZxlfM7VKjXcFwvI4UFGqLQwHMR/5BEllttYd 9HmhkAiQ+aooQR3FpqAXGkwMY9PURybKPp1VFhdM1ZQ3LlahqQ0QtKlXJWTPwgx2UvaO XePQ== X-Gm-Message-State: AIkVDXLmCe9EC/8ebOzzuZB7S2nVTQN21cPDRdfyMH0O0W2gvc2GfwkJ9teFe/OYuvVMig== X-Received: by 10.55.86.70 with SMTP id k67mr36067864qkb.280.1485355317887; Wed, 25 Jan 2017 06:41:57 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:30d3:9eab:aa95:7d2c? ([2601:18f:801:600:30d3:9eab:aa95:7d2c]) by smtp.gmail.com with ESMTPSA id o199sm4545927qke.35.2017.01.25.06.41.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 06:41:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: Date: Wed, 25 Jan 2017 09:41:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <541DBEE0-ACAF-4BAE-95D4-A1080FD9DDAC@gmail.com> References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> To: dnsop X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Suzanne Woolf Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 14:42:01 -0000 > On Jan 13, 2017, at 9:47 PM, Warren Kumari wrote: >=20 >=20 >=20 > On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf = wrote: > Dear Colleagues, >=20 >=20 > It's time to get back to our work on special use names. As the chairs = see it, here's what we need to do between now and IETF 98 (end of = March). We'll be having a DNSOP WG interim meeting shortly, see below. >=20 > 1. We need to advance the problem statement document, = https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please = review and comment on the list. We'd like to have a WGLC on it before = IETF 98. >=20 >=20 > Some additional background. > The ICANN SSAC (Security and Stability Advisory Committee) recently = (Dec 22nd) published SAC090 - = https://www.icann.org/en/system/files/files/sac-090-en.pdf (full = disclosure: I'm an author). >=20 > It is short, and easily readable -- I'd strongly encourage you to read = it (but I'll provide some teasers to tempt you!). > It notes that "a central authority to control the way in which domain = names are used in all contexts-is both infeasible and undesirable given = the robustly non-centralized way in which the Internet ecosystem = evolves", and that a coordinated management of the namespace might be = best.=20 > It also finds that uncoordinated use leads to ambiguity (and = instability), and that currently ICANN and the IETF (and others) all = allocate from a single namespace. > It recommends that ICANN > 1: create criteria for determining what labels can be TLDs. > 2: figure out how to coordinate with a: the IETF declaring names as = "special" (6761) and b: other "private use" names.=20 I read SAC090 and also recommend that others read it. The second = recommendation affects the IETF and, specifically, would address some of = the problems listed in draft-ietf-dnsop-sutld-ps. I've reviewed draft-ietf-dnsop-sutld-ps and added some text citing = SAC090; we'll publish that new revision soon. >=20 > This is a very quick summary, please go actually read it - there are = only ~6 pages of actual content, but it recommends coordination with the = IETF. So, please, let's try and get this moving -- I'd hate it if the = IETF ends up looking more dysfunctional than ICANN :-P >=20 >=20 > Also, ~3 days ago someone posted about .onion (and Special Use Names) = on hackernews -- https://news.ycombinator.com/item?id=3D13370488 . This = topic is still of interest to a bunch of people... >=20 > =20 > 2. Now that we have a working problem statement, we'd like to see = proposals on possible changes to IETF procedures to resolve the issues = we've raised. We're looking for on-list discussion, preferably with = posted I-Ds. >=20 > These proposals do not have to be limited to work for the DNSOP WG; = they may also include work we think belongs in other WGs, or requests to = the IESG or the IAB (such as liaison statements to groups outside of the = IETF). >=20 > We have had a proposal, for the ALT TLD, before us for some time now, = which we put aside while we worked on the problem statement. As part of = assessing solutions, we need to review = https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determine = what the WG wants to do with it. Comments to the list, please. >=20 > Yes please. The document is still parked, but please send me comments = *on the draft* and I'll try keep track of them to incorporate. I know = that there is much background which can be culled, I'll post a new = version to GitHub with that done soon. Now that we have draft-ietf-dnsop-sutld-ps, would there be any benefit = to revising draft-ietf-dnsop-alt-tld to point to the specific problems = .alt would address? I was going to suggest 1,$g/alternate/alternative/, but = consulting Merriam-Webster informs me that "For all intents and = purposes, alternate and alternative are synonymous. Oh, = well. - Ralph >=20 > W > =20 >=20 > 3. We're scheduling an interim WG meeting during the week of January = 30 for further work on this topic. We'll provide some possible = days/times to the list for feedback shortly, and we can't promise to = accomodate everyone's schedule constraints but will do our best. >=20 >=20 > best, > Suzanne & Tim > _______________________________________________ > 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 Thu Jan 26 10:23: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 ED56C129968 for ; Thu, 26 Jan 2017 10:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 hY2T5DkvyuuK for ; Thu, 26 Jan 2017 10:23:38 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 B2F45129969 for ; Thu, 26 Jan 2017 10:23:38 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id e137so5917048itc.0 for ; Thu, 26 Jan 2017 10:23:38 -0800 (PST) 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=Yc40Zg56Ba9MYCd5aITnyy2ijKuqLO6W5knXtyXZBbQ=; b=kzYU0Nhct3ydTyjpZkm/A9J6UGods9P4FK7LhbffsNRiVVQ7Bjji4Vv9+EcmYkJzT1 NQ1AvfK+qTtrOjJZwEZFbrON4YmqnPVW7riqRl02f2YTAjUUadZ/RTBYffnOky4yHhPs 7ucbxD2NICMGo5L5P/4/ODgcesmm5WYRb/4Dnr7DppyyJs9HgSYymrAJ44lpjKurMZ0H 9NxaXqFBRwcqoDgKaDnYkP3I0WY2i+NYOq6l9vDY7W3BNCOAs2qa4ax98EI+FJ3YLbtv jhkMxqao56dzTXpmwrbQzusLrhOfnGailI4BnX1P2nzuo6a211ZkXWm26sxrpTLx28co unUg== 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=Yc40Zg56Ba9MYCd5aITnyy2ijKuqLO6W5knXtyXZBbQ=; b=C1zT/hrQ02b6IuPqKXJYJZNapX2+B75qylHXke2xgF7ANvxgsH960ARmjw+xRSUFkx 8o8qJDZT5lQFO8zIgt2SymcT/O3NdgBsC0TC9hXsxVaHf7wROAIS3nTpP1nMXRbaNdYs BTqp6Ddv/Y//UqCIeFa6RYY5nu8f1S+2L7Fo2D8LZdrGaG/H/1Zn7HXbRH49p9toYQEk L4la3TM+IYZnfLDOVvXL4sot0Z+T2BtGiKjI4uGC/iojGFM3VQ0B8X5rT5Ga7MCxvHTX AI0UiP0KxogY7RNJ/bESzmdxZh3V/88j8glLfRrKvCwV2CXQ8lps2Lq9rD9LdzKBekzr 0Y2Q== X-Gm-Message-State: AIkVDXLmgyuKSyzCLwv07FhKf1SEcXC940vTW/ewx34ICONgqaJm6YsPRAHrUg7/9vK0RSXud5joJgCqC0scWQ== X-Received: by 10.36.61.136 with SMTP id n130mr4179012itn.107.1485455017898; Thu, 26 Jan 2017 10:23:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.95.6 with HTTP; Thu, 26 Jan 2017 10:23:37 -0800 (PST) In-Reply-To: <541DBEE0-ACAF-4BAE-95D4-A1080FD9DDAC@gmail.com> References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> <541DBEE0-ACAF-4BAE-95D4-A1080FD9DDAC@gmail.com> From: tjw ietf Date: Thu, 26 Jan 2017 13:23:37 -0500 Message-ID: To: Ralph Droms Content-Type: multipart/alternative; boundary=001a1144454eac95bc05470372a9 Archived-At: Cc: dnsop , Suzanne Woolf Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 18:23:42 -0000 --001a1144454eac95bc05470372a9 Content-Type: text/plain; charset=UTF-8 I think updating alt-tld draft to point to the specific problems in sutld-ps to be useful. I am holding out hope that alt-tld will be unstuck and kicked down the road. I also am holding out for a pony. tim On Wed, Jan 25, 2017 at 9:41 AM, Ralph Droms wrote: > > > On Jan 13, 2017, at 9:47 PM, Warren Kumari wrote: > > > > > > > > On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf > wrote: > > Dear Colleagues, > > > > > > It's time to get back to our work on special use names. As the chairs > see it, here's what we need to do between now and IETF 98 (end of March). > We'll be having a DNSOP WG interim meeting shortly, see below. > > > > 1. We need to advance the problem statement document, > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please > review and comment on the list. We'd like to have a WGLC on it before IETF > 98. > > > > > > Some additional background. > > The ICANN SSAC (Security and Stability Advisory Committee) recently (Dec > 22nd) published SAC090 - https://www.icann.org/en/ > system/files/files/sac-090-en.pdf (full disclosure: I'm an author). > > > > It is short, and easily readable -- I'd strongly encourage you to read > it (but I'll provide some teasers to tempt you!). > > It notes that "a central authority to control the way in which domain > names are used in all contexts-is both infeasible and undesirable given the > robustly non-centralized way in which the Internet ecosystem evolves", and > that a coordinated management of the namespace might be best. > > It also finds that uncoordinated use leads to ambiguity (and > instability), and that currently ICANN and the IETF (and others) all > allocate from a single namespace. > > It recommends that ICANN > > 1: create criteria for determining what labels can be TLDs. > > 2: figure out how to coordinate with a: the IETF declaring names as > "special" (6761) and b: other "private use" names. > > I read SAC090 and also recommend that others read it. The second > recommendation affects the IETF and, specifically, would address some of > the problems listed in draft-ietf-dnsop-sutld-ps. > > I've reviewed draft-ietf-dnsop-sutld-ps and added some text citing SAC090; > we'll publish that new revision soon. > > > > > This is a very quick summary, please go actually read it - there are > only ~6 pages of actual content, but it recommends coordination with the > IETF. So, please, let's try and get this moving -- I'd hate it if the IETF > ends up looking more dysfunctional than ICANN :-P > > > > > > Also, ~3 days ago someone posted about .onion (and Special Use Names) on > hackernews -- https://news.ycombinator.com/item?id=13370488 . This topic > is still of interest to a bunch of people... > > > > > > 2. Now that we have a working problem statement, we'd like to see > proposals on possible changes to IETF procedures to resolve the issues > we've raised. We're looking for on-list discussion, preferably with posted > I-Ds. > > > > These proposals do not have to be limited to work for the DNSOP WG; they > may also include work we think belongs in other WGs, or requests to the > IESG or the IAB (such as liaison statements to groups outside of the IETF). > > > > We have had a proposal, for the ALT TLD, before us for some time now, > which we put aside while we worked on the problem statement. As part of > assessing solutions, we need to review https://datatracker.ietf.org/ > doc/draft-ietf-dnsop-alt-tld/ and determine what the WG wants to do with > it. Comments to the list, please. > > > > Yes please. The document is still parked, but please send me comments > *on the draft* and I'll try keep track of them to incorporate. I know that > there is much background which can be culled, I'll post a new version to > GitHub with that done soon. > > Now that we have draft-ietf-dnsop-sutld-ps, would there be any benefit to > revising draft-ietf-dnsop-alt-tld to point to the specific problems .alt > would address? > > I was going to suggest 1,$g/alternate/alternative/, but > consulting Merriam-Webster informs me that "For all intents and purposes, > alternate and alternative are synonymous. Oh, well. > > - Ralph > > > > > W > > > > > > 3. We're scheduling an interim WG meeting during the week of January 30 > for further work on this topic. We'll provide some possible days/times to > the list for feedback shortly, and we can't promise to accomodate > everyone's schedule constraints but will do our best. > > > > > > best, > > Suzanne & Tim > > _______________________________________________ > > 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a1144454eac95bc05470372a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think updating alt-tld draft to point to the sp= ecific problems in sutld-ps to be useful. =C2=A0

I= am holding out hope that alt-tld will be unstuck and kicked down the road.=
I also am holding out for a pony.=C2=A0

tim

O= n Wed, Jan 25, 2017 at 9:41 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
> On Jan 13, 2017, at 9:47 PM, Warren Kumari <warren@kumari.net> wrote:
>
>
>
> On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf <suzworldwide@gmail.com> wrote:
> Dear Colleagues,
>
>
> It's time to get back to our work on special use names. As the cha= irs see it, here's what we need to do between now and IETF 98 (end of M= arch).=C2=A0 We'll be having a DNSOP WG interim meeting shortly, see be= low.
>
> 1. We need to advance the problem statement document, https://datatracker.ietf.org/doc/draft-ietf-dnsop-su= tld-ps/. Please review and comment on the list. We'd like to h= ave a WGLC on it before IETF 98.
>
>
> Some additional background.
> The ICANN SSAC (Security and Stability Advisory Committee) recently (D= ec 22nd) published SAC090 - https://www.ic= ann.org/en/system/files/files/sac-090-en.pdf (full disclosure= : I'm an author).
>
> It is short, and easily readable -- I'd strongly encourage you to = read it (but I'll provide some teasers to tempt you!).
> It notes that "a central authority to control the way in which do= main names are used in all contexts-is both infeasible and undesirable give= n the robustly non-centralized way in which the Internet ecosystem evolves&= quot;, and that a coordinated management of the namespace might be best. > It also finds that uncoordinated use leads to ambiguity (and instabili= ty), and that currently ICANN and the IETF (and others) all allocate from a= single namespace.
> It recommends that ICANN
> 1: create criteria for determining what labels can be TLDs.
> 2: figure out how to coordinate with a: the IETF declaring names as &q= uot;special" (6761) and b: other "private use" names.

I read SAC090 and also recommend that others read it.=C2=A0 The seco= nd recommendation affects the IETF and, specifically, would address some of= the problems listed in draft-ietf-dnsop-sutld-ps.

I've reviewed draft-ietf-dnsop-sutld-ps and added some text citing SAC0= 90; we'll publish that new revision soon.

>
> This is a very quick summary, please go actually read it - there are o= nly ~6 pages of actual content, but it recommends coordination with the IET= F. So, please, let's try and get this moving -- I'd hate it if the = IETF ends up looking more dysfunctional than ICANN :-P
>
>
> Also, ~3 days ago someone posted about .onion (and Special Use Names) = on hackernews -- https://news.ycombinator.com/it= em?id=3D13370488 . This topic is still of interest to a bunch of people= ...
>
>
> 2. Now that we have a working problem statement, we'd like to see = proposals on possible changes to IETF procedures to resolve the issues we&#= 39;ve raised. We're looking for on-list discussion, preferably with pos= ted I-Ds.
>
> These proposals do not have to be limited to work for the DNSOP WG; th= ey may also include work we think belongs in other WGs, or requests to the = IESG or the IAB (such as liaison statements to groups outside of the IETF).=
>
> We have had a proposal, for the ALT TLD, before us for some time now, = which we put aside while we worked on the problem statement. As part of ass= essing solutions, we need to review https:= //datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determine= what the WG wants to do with it. Comments to the list, please.
>
> Yes please. The document is still parked, but please send me comments = *on the draft* and I'll try keep track of them to incorporate. I know t= hat there is much background which can be culled, I'll post a new versi= on to GitHub with that done soon.

Now that we have draft-ietf-dnsop-sutld-ps, would there be any benef= it to revising draft-ietf-dnsop-alt-tld to point to the specific problems .= alt would address?

<pedantic>I was going to suggest 1,$g/alternate/alternative/, but con= sulting Merriam-Webster informs me that "For all intents and purposes,= alternate and alternative are synonymous.=C2=A0 Oh, well.</pedantic>=

- Ralph

>
> W
>
>
> 3. We're scheduling an interim WG meeting during the week of Janua= ry 30 for further work on this topic. We'll provide some possible days/= times to the list for feedback shortly, and we can't promise to accomod= ate everyone's schedule constraints but will do our best.
>
>
> best,
> Suzanne & Tim
> _______________________________________________
> 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=

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a1144454eac95bc05470372a9-- From nobody Thu Jan 26 13:26: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 2A6CA129BD7 for ; Thu, 26 Jan 2017 13:26:08 -0800 (PST) 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=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 ZEZylj37aCQv for ; Thu, 26 Jan 2017 13:26:06 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 7D7FA129BD3 for ; Thu, 26 Jan 2017 13:26:06 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id v23so98499527qtb.0 for ; Thu, 26 Jan 2017 13:26:06 -0800 (PST) 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; bh=38nQ/VZdVPoLjb/8GqudNSpmRj11isodR6e+kooRDDM=; b=qIJzyQGFqY2sM4KBWYoYFXLeA0ZVzIMunhu3wwdT1TmbsvR0IWPlpuW1kfePC1K62S zU5AaPmp+cDW8e5T8kIBcZGSyHDyCUjVIcmOuy0ONvoDZmdNC/hLakXKRAEJ+XXXdvyD WPuqX41MS0coDSlzxn8BY0l9XlAXYfSoJmQ+x/eW4Z9IPWOkrNUHx6BCQCcnAM2kCKF7 f355OYn1cM2FcV1Y+OgIwbMLty55Vh43knbQQn2RJ3MFnJB7j/hse3cEfcabKZxsRDTG 7Ord/EhaBsyxwiGqyPMIzTylX222wvvAEVZCEea5s5iZ4Ef7rUMrMZvWvCGQwT4dp+G3 lZ/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=38nQ/VZdVPoLjb/8GqudNSpmRj11isodR6e+kooRDDM=; b=Zyks8DhdGjj/5/jVQxZ8YOFSfzQ8FrlhxH02Vn4bXIjWRqPLRKKefl35M6nQXhj9yO 6bHu5TcwfhOxovy9uaA9oUDW7cVCHZj/mFdWw7SqQG84tk8LLl1gHl+iPnUJ0f02i/CI a/XDPUHL9ryifQpbU0ntlbKxMpiLURdxoOMg3L0gJoXWk8Lob6IOPzsW6DdKvU21aotF 7ORZ7+JMipwiQ9tUfciWuubg/YzlsU9/+j8AoFbxU7s1X4DV9PDkN7yJ+L1vLJsXZq6m l6G6p47z5fKlj5VcDOx7f1DCBoFA3QEPPxsTGyRUd6QX/pO2tEBjEknWwPUQwKADofd4 +LWA== X-Gm-Message-State: AIkVDXK/BRPRe80GXG/ogdtPQzmkLHWeD2n6/M4Kr/ZofYRj/NValhxqIQB3rdrKDl8tSfEUPl0KNoZxlOpdzyIL X-Received: by 10.237.63.28 with SMTP id p28mr4744234qtf.263.1485465965301; Thu, 26 Jan 2017 13:26:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Thu, 26 Jan 2017 13:25:34 -0800 (PST) In-Reply-To: <20161105182131.GA28962@sources.org> References: <147785472700.20720.7213789764973815729.idtracker@ietfa.amsl.com> <20161105182131.GA28962@sources.org> From: Warren Kumari Date: Thu, 26 Jan 2017 16:25:34 -0500 Message-ID: To: Stephane Bortzmeyer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Bob Harold , IETF DNSOP WG Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 21:26:08 -0000 On Sat, Nov 5, 2016 at 2:21 PM, Stephane Bortzmeyer wrote: > On Thu, Nov 03, 2016 at 12:04:42PM -0400, > Bob Harold wrote > a message of 124 lines which said: > >> Those changes look good to me. > > OK for me also. > > Except may be the new word "sandbox" that appeared in -06. It is not > the usual sense of this word in computer science, it seems to me. Thank you, that's a good point -- I'd been thinking of it in the "a safe place to play in" context and the computer context didn't occur to me... I've changed "This document reserves the ALT label, using the [RFC6761] process, for use as a pseudo-TLD. This creates an unmanaged sandbox namespace." to " This document reserves the ALT label, using the "RFC6761" process, for use as an unmanaged pseudo-TLD namespace." I think that this is a clearer, thanks. I'm only making these changes in Github until the document is unparked. https://github.com/wkumari/draft-wkumari-dnsop-alt-tld W > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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 Thu Jan 26 13:27: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 645D6129CD8 for ; Thu, 26 Jan 2017 13:27:24 -0800 (PST) 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=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 6QV2NFtPQS76 for ; Thu, 26 Jan 2017 13:27:22 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 AFEE8129CDD for ; Thu, 26 Jan 2017 13:27:22 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id k15so98962567qtg.3 for ; Thu, 26 Jan 2017 13:27:22 -0800 (PST) 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=PxvCSBBsfRCNd5wn1nnzMczhsePzpYanWJq2sSE9WEg=; b=vLy/9IlO2HxhzYB1nrAb21lb5UOegvRrGq0vehdymQbKA3odJE014DKqd5tz6sciHt +oWkhTmf8LT8KwSbW7SmOUNQ5dKzAwy4RmMFp6lqKgWXKl7SFN8lM0bXSqlOpfQYGcXC /PsX+7nnilItvqgI3Ue5ng7D508U3LvirVXZLP3ayCuqdcs4gfO18zN2pD9zAHP7zSv2 JfJ/Kr1Yln+PdH++Ewz4A97b7DoWU45oIOfxt6+K0muG47Ymmz81BvDC20wfq6ZqlNsl tsDaoWhAQFRi4XDHQzkj1Q4S9LIic999+gHM3F14oW4hYt0qctQ547E7HxlOWuzovFLQ IwoA== 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=PxvCSBBsfRCNd5wn1nnzMczhsePzpYanWJq2sSE9WEg=; b=tzISVRa8fyrGDjQijchhsr7mJ1zOIEJAKQW6Vezlrp4ck4myxo0NtAFvP99apdieeb xYuJKuJoVtCnjt42H/jHArit2f+sGB1bFxVtWUkNcD8TlSggwSctqJnCWz67G/bYWQ/c 1SNQ0V3sVRfNpSerNO64sYyxgJDHD6RVbTJi2hyiUuJbxIr2TGHmd5GINv5Aedi5ryYT zbpuEGVPO0L3dn0lWnwbMRgEaC3Zi0hFzxbuDofPdIhkm456wb7QdGkd/Qy8US/hzpmU LIEuL8xcjvCn8L7fYJfjXjebcX1va25JsKchnbj8PixA6EUFcHqj74cQ9ATCSuulouwO zFAA== X-Gm-Message-State: AIkVDXJPkkOg5KGedqylkuHv5Vb4EKn1XI916G5R17tzzWRBcGyK6JdVYgS/wx8zYxW+kMI2eaiyGNLNw3tUsnYy X-Received: by 10.200.54.247 with SMTP id b52mr5093448qtc.124.1485466041644; Thu, 26 Jan 2017 13:27:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Thu, 26 Jan 2017 13:26:51 -0800 (PST) In-Reply-To: <541DBEE0-ACAF-4BAE-95D4-A1080FD9DDAC@gmail.com> References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> <541DBEE0-ACAF-4BAE-95D4-A1080FD9DDAC@gmail.com> From: Warren Kumari Date: Thu, 26 Jan 2017 16:26:51 -0500 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop , Suzanne Woolf Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 21:27:24 -0000 On Wed, Jan 25, 2017 at 9:41 AM, Ralph Droms wrote: > >> On Jan 13, 2017, at 9:47 PM, Warren Kumari wrote: >> >> >> >> On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf w= rote: >> Dear Colleagues, >> >> >> It's time to get back to our work on special use names. As the chairs se= e it, here's what we need to do between now and IETF 98 (end of March). We= 'll be having a DNSOP WG interim meeting shortly, see below. >> >> 1. We need to advance the problem statement document, https://datatracke= r.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please review and comment on the= list. We'd like to have a WGLC on it before IETF 98. >> >> >> Some additional background. >> The ICANN SSAC (Security and Stability Advisory Committee) recently (Dec= 22nd) published SAC090 - https://www.icann.org/en/system/files/files/sac-0= 90-en.pdf (full disclosure: I'm an author). >> >> It is short, and easily readable -- I'd strongly encourage you to read i= t (but I'll provide some teasers to tempt you!). >> It notes that "a central authority to control the way in which domain na= mes are used in all contexts-is both infeasible and undesirable given the r= obustly non-centralized way in which the Internet ecosystem evolves", and t= hat a coordinated management of the namespace might be best. >> It also finds that uncoordinated use leads to ambiguity (and instability= ), and that currently ICANN and the IETF (and others) all allocate from a s= ingle namespace. >> It recommends that ICANN >> 1: create criteria for determining what labels can be TLDs. >> 2: figure out how to coordinate with a: the IETF declaring names as "spe= cial" (6761) and b: other "private use" names. > > I read SAC090 and also recommend that others read it. The second recomme= ndation affects the IETF and, specifically, would address some of the probl= ems listed in draft-ietf-dnsop-sutld-ps. > > I've reviewed draft-ietf-dnsop-sutld-ps and added some text citing SAC090= ; we'll publish that new revision soon. > >> >> This is a very quick summary, please go actually read it - there are onl= y ~6 pages of actual content, but it recommends coordination with the IETF.= So, please, let's try and get this moving -- I'd hate it if the IETF ends = up looking more dysfunctional than ICANN :-P >> >> >> Also, ~3 days ago someone posted about .onion (and Special Use Names) on= hackernews -- https://news.ycombinator.com/item?id=3D13370488 . This topic= is still of interest to a bunch of people... >> >> >> 2. Now that we have a working problem statement, we'd like to see propos= als on possible changes to IETF procedures to resolve the issues we've rais= ed. We're looking for on-list discussion, preferably with posted I-Ds. >> >> These proposals do not have to be limited to work for the DNSOP WG; they= may also include work we think belongs in other WGs, or requests to the IE= SG or the IAB (such as liaison statements to groups outside of the IETF). >> >> We have had a proposal, for the ALT TLD, before us for some time now, wh= ich we put aside while we worked on the problem statement. As part of asses= sing solutions, we need to review https://datatracker.ietf.org/doc/draft-ie= tf-dnsop-alt-tld/ and determine what the WG wants to do with it. Comments t= o the list, please. >> >> Yes please. The document is still parked, but please send me comments *o= n the draft* and I'll try keep track of them to incorporate. I know that th= ere is much background which can be culled, I'll post a new version to GitH= ub with that done soon. > > Now that we have draft-ietf-dnsop-sutld-ps, would there be any benefit to= revising draft-ietf-dnsop-alt-tld to point to the specific problems .alt w= ould address? I added some text which pointed at the general areas of draft-ietf-dnsop-sutld-ps which this would address. > > I was going to suggest 1,$g/alternate/alternative/, but consult= ing Merriam-Webster informs me that "For all intents and purposes, alternat= e and alternative are synonymous. Oh, well. In a move sure to trigger the OCD jean[0] in all the pedants, I've replaced a *random subset* of the "alternate" with "alternative".... (actually I did it where I thought it flowed / read better) W [0]: See what I did there? > > - Ralph > >> >> W >> >> >> 3. We're scheduling an interim WG meeting during the week of January 30 = for further work on this topic. We'll provide some possible days/times to t= he list for feedback shortly, and we can't promise to accomodate everyone's= schedule constraints but will do our best. >> >> >> best, >> Suzanne & Tim >> _______________________________________________ >> 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 > --=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 Thu Jan 26 15:51: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 D87BD128B44 for ; Thu, 26 Jan 2017 15:51:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8l_aY0Z1VBsw for ; Thu, 26 Jan 2017 15:51:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370BC128DF6 for ; Thu, 26 Jan 2017 15:51:14 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D0E6A284DED for ; Thu, 26 Jan 2017 23:51:13 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 26 Jan 2017 18:51:13 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5B132D43-0360-4F50-9031-F3EEEDB5AB80@dukhovni.org> References: To: dnsop@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 122, Issue 24 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dnsop@ietf.org List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 23:51:18 -0000 > On Jan 23, 2017, at 3:00 PM, dnsop-request@ietf.org wrote: > > I've been following this discussion and have taken a few weeks to think > about the comments rendered here in some depth. I find that I most agree > with this statement: > > On Tue, Dec 20, 2016 at 10:53:39PM +0000, Warren Kumari wrote: >> I believe that RPZ (and the DNS lies which it creates) is evil -- >> unfortunately we live in a world where this is a necessary evil. > > I started studying the use of domains by spammers 15 years ago. > I expanded that study to phishers, typosquatters, domaineers, malware > distributors, etc. as it became excruciatingly clear that these are > quite often the same people or operations. (See "Sanford Wallace" > for one of the canonical examples.) > > It's become clear to me that most Internet domains are malicious. > In the new TLDs, "most" asymptotically approaches "all". ISPs that provide DNS recursive servers to consumers will undoubtedly use all the means at their disposal to manage their networks. The question in my mind is not whether they will often find DNS filtering both useful and necessary, but rather whether there needs to be a standard[1] mechanism for sharing DNS policy (mis)information, and what form any such "standard" might then take. If the proposed work is to just document the RPZ format as-is, then why is IETF involvement required? If the proposed work is to address the underlying needs, then discussion of how the format might be modified to reduce harm seems to be in scope... -- Viktor. [1] Or even an informational RFC, since sadly many don't pay close attention to the distinction between standards-track and informational RFCs. From nobody Fri Jan 27 10:08:13 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 ED9881296B6; Fri, 27 Jan 2017 10:08:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148554048796.17823.2041263713143626451.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 10:08:07 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 18:08:08 -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 : DNS Terminology Authors : Paul Hoffman Andrew Sullivan Kazunori Fujiwara Filename : draft-ietf-dnsop-terminology-bis-04.txt Pages : 34 Date : 2017-01-27 Abstract: The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-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 Fri Jan 27 10:12: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 843551296C4 for ; Fri, 27 Jan 2017 10:12:37 -0800 (PST) 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] 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 9BgVjSCI0WTX for ; Fri, 27 Jan 2017 10:12:35 -0800 (PST) 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 29FBB1296C3 for ; Fri, 27 Jan 2017 10:12:33 -0800 (PST) Received: from [10.32.60.132] (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 v0RIBS2S074641 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 27 Jan 2017 11:11:29 -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 [10.32.60.132] From: "Paul Hoffman" To: dnsop@ietf.org Date: Fri, 27 Jan 2017 10:12:30 -0800 Message-ID: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Subject: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 18:12:37 -0000 The authors have tentatively made some substantial changes to the draft, to define "domain name", "global DNS", and "private DNS" in a manner that can be used by other work in the IETF, particularly around RFC 6761. Our first cut of definitions are in the new draft, but we fully expect significant discussion in the WG before there is even rough consensus. We are not even sure that the WG will agree with the idea of adding "global DNS" and "private DNS" to the document. The authors are not even sure they agree with all of this. At the same time, we think that it would be easier to track open issues in our GitHub repo at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis rather than in the document as comments. To be clear, the discussion of how issues are to be resolved should be mostly done on the mailing list, but using GitHub to track issues might give easier-to-follow history of the discussions. We also are open to using GitHub for pull requests for specific changes to the document. As a final note, this version of the draft also has some changes not related to the above, and we encourage review of those changes, plus anything else in the draft, of course. --Paul Hoffman On 27 Jan 2017, at 10:08, 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 : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename : draft-ietf-dnsop-terminology-bis-04.txt > Pages : 34 > Date : 2017-01-27 > > Abstract: > The DNS is defined in literally dozens of different RFCs. The > terminology used by implementers and developers of DNS protocols, > and > by operators of DNS systems, has sometimes changed in the decades > since the DNS was first defined. This document gives current > definitions for many of the terms used in the DNS in a single > document. > > This document will be the successor to RFC 7719. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-04 From nobody Fri Jan 27 12:23: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 06999129898 for ; Fri, 27 Jan 2017 12:23:51 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 IDSICOu87MGQ for ; Fri, 27 Jan 2017 12:23:49 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 33444129883 for ; Fri, 27 Jan 2017 12:23:49 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id w20so85947743qtb.1 for ; Fri, 27 Jan 2017 12:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=i/oQzL7KKX1hpr2PPE59oDT7qII8foce67PNkmHN4+k=; b=TcSO05Duol7Mt8hrs+AnnTbsx2OBA5hCUiljsnlSO0XR6A8Lll8GLDsLfFXL811PVP 7Y1bdBdhW+6iphrZxb9gth1w5B84HQUOu50TsRVZfz2pWQo74j+tuG5ob2SA+MZ9IG/g t6RADor8iUeDNMBq4ygHOcDMmNW25iXB/X0qjMbP7M62lBwQk5znWYgKuP2j4EhufreB BNYXmsDVD/6vGWaHWocnmABdzJfj0TIemTct8TWXbHZzgmwPUcIkVTHqKAhv33+HjLGp TcZRoPUtukkbrdMiyQPKOAFdx6tIeU7oQCSPmI51vd+HolwNLBiw+B9SX3GXRLZp6piX fF6w== 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; bh=i/oQzL7KKX1hpr2PPE59oDT7qII8foce67PNkmHN4+k=; b=LtbkntrZuukcMUnIfbLhWqGxB8IKsn6cdZ1eCPclOWXmFlSndLKuS74K/i60I+mMJR PaTLSpxolxRxw3aadW3t5EBjorKB0VFc/DyCKI60nXGhbIK+aZKQ1ZvTejKOBWrRem2M 9LBKSlG/oM/L+BlHUS5hShXuu0yc7kwmdGKn5a3/j3noCqnWx0Z/AXCLUcAoTNQxBmE6 msHJBnmFcGdGSIOCo5t1FAWB5Yaa262nao86PGvn+Z6RiaPX+FXyJ0Li/dwsui1HzAYe lyGLBLFLixv/m3NYTgXKhyT440wmU4wrqn7WMur99cmi0g/f6b4lQrhYVi2uslFQSt2e OWJg== X-Gm-Message-State: AIkVDXJyGZY9J3D0HFsGJOrLcKv153Y/PnbJbpUZQ6efbdstJEtYlwhgC7TnCwexnA9XYg== X-Received: by 10.55.137.69 with SMTP id l66mr10345912qkd.133.1485548626169; Fri, 27 Jan 2017 12:23:46 -0800 (PST) Received: from twicinski-ltm1.internal.salesforce.com ([204.14.236.150]) by smtp.googlemail.com with ESMTPSA id r57sm5017363qtr.27.2017.01.27.12.23.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 12:23:45 -0800 (PST) To: dnsop@ietf.org References: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> From: Tim Wicinski Message-ID: <81be75a6-15c6-3dd3-6ef4-58b34251ae3c@gmail.com> Date: Fri, 27 Jan 2017 15:23:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 20:23:51 -0000 I spoke with Paul about this and I agree that a mechanism that focuses the discussion on individual definitions should make it easier to either reach consensus, or to quickly realize there is no consensus. tim On 1/27/17 1:12 PM, Paul Hoffman wrote: > The authors have tentatively made some substantial changes to the draft, > to define "domain name", "global DNS", and "private DNS" in a manner > that can be used by other work in the IETF, particularly around RFC > 6761. Our first cut of definitions are in the new draft, but we fully > expect significant discussion in the WG before there is even rough > consensus. We are not even sure that the WG will agree with the idea of > adding "global DNS" and "private DNS" to the document. The authors are > not even sure they agree with all of this. > > At the same time, we think that it would be easier to track open issues > in our GitHub repo at > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis rather than in > the document as comments. To be clear, the discussion of how issues are > to be resolved should be mostly done on the mailing list, but using > GitHub to track issues might give easier-to-follow history of the > discussions. We also are open to using GitHub for pull requests for > specific changes to the document. > > As a final note, this version of the draft also has some changes not > related to the above, and we encourage review of those changes, plus > anything else in the draft, of course. > > --Paul Hoffman > > On 27 Jan 2017, at 10:08, 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 : DNS Terminology >> Authors : Paul Hoffman >> Andrew Sullivan >> Kazunori Fujiwara >> Filename : draft-ietf-dnsop-terminology-bis-04.txt >> Pages : 34 >> Date : 2017-01-27 >> >> Abstract: >> The DNS is defined in literally dozens of different RFCs. The >> terminology used by implementers and developers of DNS protocols, and >> by operators of DNS systems, has sometimes changed in the decades >> since the DNS was first defined. This document gives current >> definitions for many of the terms used in the DNS in a single >> document. >> >> This document will be the successor to RFC 7719. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-04 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Jan 27 12:43:28 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 3BDD2129698; Fri, 27 Jan 2017 12:43:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148554980323.17939.5659649119542635687.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 12:43:23 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 20:43:23 -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 Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-01.txt Pages : 20 Date : 2017-01-27 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 standards 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-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 Sat Jan 28 12:28: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 BAD4D129841 for ; Sat, 28 Jan 2017 12:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 piYAcHZ1ahVm for ; Sat, 28 Jan 2017 12:28:25 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 931D21297F3 for ; Sat, 28 Jan 2017 12:28:25 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id v23so174865452qtb.0 for ; Sat, 28 Jan 2017 12:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ZUC/bfYIJwNtZPqgdLR/ksk06m/IfYU2xiqhbXSKRUo=; b=grNsOcbxHrGrmiYLX9PaGbzJnp51SuSuHep8l1lh5st0GcON3iiGhp2ZV+/XXxprzX awsGSfp57YRphcP7XsFFVJvyPckbwT+MeI0ozSiZkOiUMEFsj166nMV48iizuMHZ/8KI vW8znJcMxoGjNNLYOD+PDdxn6KjAiC5qOviWtp6iz3JJ5Ch67iQOuzKPKJCClyj2WMWy MraeW7RTaMQvdW6Z82yiLGlXfE6uhEEGiK7hECnn83duakLd27TAYfYPhP1XQFulW5Ok jIM+dr/CKFDb4n1ei+B3hIm+30L5bn7N6IB8YarFyOlSKadbiLJt65CtGCb12i5m+qaw LHAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ZUC/bfYIJwNtZPqgdLR/ksk06m/IfYU2xiqhbXSKRUo=; b=Z1TmVySRnUTV0pEurNHoYSKRnDkpepnNZ13p+dw/ydjsMWvYFE95Po54DHv4cvNbSv nc20ZAg4LQjAdcRVn4V99sztbkH0rpu2JIC+jl0SIpRGTp2pxvly/UdbMY0KXHu1435t kC2v9eDkUMIB8RKMZD957gef9JKRvgGfmeoADN/5wQIe/NVQ29ZkVL9rM7FOtB1YHfE6 Bcz3ZWHSXO4iiHVKE93ugFPNL8VqP5XPavNZmOdD4FHnCeRXGIYR3ruKf8lkLE1ZNq8u fqOhXLh589ICcn1kd8uXR6GRKkZfivn/iUIkcIhUxzX8SpCy7rU9DZXv0GV9pNliRBc3 FJYg== X-Gm-Message-State: AIkVDXJLIwSqjIt7Vin61jGBAYcA6sVTuGcUO53UjcqWp0rXsxV9+nRof0jC8DRLsWY71Q== X-Received: by 10.200.43.212 with SMTP id n20mr13599595qtn.117.1485635304557; Sat, 28 Jan 2017 12:28:24 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:3956:dc97:a134:e270? ([2601:18f:801:600:3956:dc97:a134:e270]) by smtp.gmail.com with ESMTPSA id s71sm7484880qkl.22.2017.01.28.12.28.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 12:28:23 -0800 (PST) From: Ralph Droms Content-Type: multipart/alternative; boundary="Apple-Mail=_978C75BE-F0E5-408F-ABB8-9DC3F7BD21C5" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 28 Jan 2017 15:28:25 -0500 References: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> To: dnsop In-Reply-To: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> Message-Id: <54004E75-B865-4297-A254-037BABD55A6A@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 20:28:28 -0000 --Apple-Mail=_978C75BE-F0E5-408F-ABB8-9DC3F7BD21C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've submitted three issues to the doc repo: Issue #8: = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 = Add "context" as a facet in the definition of a naming system. A naming = system needs a context in which to perform resolution of a name. As an = example, "locally served DNS zones" (see Issue #10) use the DNS = resolution mechanism through a local context rather than through the = global root. Issue #9: = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/9 = In the definition of "global DNS", add a description of the context to = be used for the resolution of names under "global DNS" Issue #10: = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/10 = Add a new definition for "locally served DNS names", as defined in RFC = 6303. This definition is likely to be useful in the specification of = the home network DNS context, which is currently a work item for the = homenet WG. - Ralph > On Jan 27, 2017, at 1:12 PM, Paul Hoffman = wrote: >=20 > The authors have tentatively made some substantial changes to the = draft, to define "domain name", "global DNS", and "private DNS" in a = manner that can be used by other work in the IETF, particularly around = RFC 6761. Our first cut of definitions are in the new draft, but we = fully expect significant discussion in the WG before there is even rough = consensus. We are not even sure that the WG will agree with the idea of = adding "global DNS" and "private DNS" to the document. The authors are = not even sure they agree with all of this. >=20 > At the same time, we think that it would be easier to track open = issues in our GitHub repo at = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis rather than in = the document as comments. To be clear, the discussion of how issues are = to be resolved should be mostly done on the mailing list, but using = GitHub to track issues might give easier-to-follow history of the = discussions. We also are open to using GitHub for pull requests for = specific changes to the document. >=20 > As a final note, this version of the draft also has some changes not = related to the above, and we encourage review of those changes, plus = anything else in the draft, of course. >=20 > --Paul Hoffman >=20 > On 27 Jan 2017, at 10:08, internet-drafts@ietf.org wrote: >=20 >> 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 : DNS Terminology >> Authors : Paul Hoffman >> Andrew Sullivan >> Kazunori Fujiwara >> Filename : draft-ietf-dnsop-terminology-bis-04.txt >> Pages : 34 >> Date : 2017-01-27 >>=20 >> Abstract: >> The DNS is defined in literally dozens of different RFCs. The >> terminology used by implementers and developers of DNS protocols, = and >> by operators of DNS systems, has sometimes changed in the decades >> since the DNS was first defined. This document gives current >> definitions for many of the terms used in the DNS in a single >> document. >>=20 >> This document will be the successor to RFC 7719. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-terminology-bis-04= >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_978C75BE-F0E5-408F-ABB8-9DC3F7BD21C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I've submitted three issues to the doc repo:
Issue #8: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issue= s/8

Add = "context" as a facet in the definition of a naming system.  A = naming system needs a context in which to perform resolution of a name. =  As an example, "locally served DNS zones" (see Issue #10) use the = DNS resolution mechanism through a local context rather than through the = global root.

Issue #9: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issue= s/9

In the = definition of "global DNS", add a description of the context to be used = for the resolution of names under "global DNS"

Issue #10: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issue= s/10

Add a = new definition for "locally served DNS names", as defined in RFC 6303. =  This definition is likely to be useful in the specification of the = home network DNS context, which is currently a work item for the homenet = WG.

- = Ralph

On Jan 27, 2017, at 1:12 PM, Paul Hoffman = <paul.hoffman@vpnc.org> wrote:

The = authors have tentatively made some substantial changes to the draft, to = define "domain name", "global DNS", and "private DNS" in a manner that = can be used by other work in the IETF, particularly around RFC 6761. Our = first cut of definitions are in the new draft, but we fully expect = significant discussion in the WG before there is even rough consensus. = We are not even sure that the WG will agree with the idea of adding = "global DNS" and "private DNS" to the document. The authors are not even = sure they agree with all of this.

At the = same time, we think that it would be easier to track open issues in our = GitHub repo at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis = rather than in the document as comments. To be clear, the discussion of = how issues are to be resolved should be mostly done on the mailing list, = but using GitHub to track issues might give easier-to-follow history of = the discussions. We also are open to using GitHub for pull requests for = specific changes to the document.

As a = final note, this version of the draft also has some changes not related = to the above, and we encourage review of those changes, plus anything = else in the draft, of course.

--Paul = Hoffman

On 27 Jan 2017, at 10:08, 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 =           : DNS = Terminology
=        Authors =         : Paul Hoffman
=             &n= bsp;           &nbs= p;Andrew Sullivan
=             &n= bsp;           &nbs= p;Kazunori Fujiwara
Filename =        : = draft-ietf-dnsop-terminology-bis-04.txt
Pages =           : 34
= Date =            : = 2017-01-27

Abstract:
=   The DNS is defined in literally dozens of different RFCs. =  The
  terminology used by implementers = and developers of DNS protocols, and
  by = operators of DNS systems, has sometimes changed in the decades
  since the DNS was first defined.  This = document gives current
  definitions for many = of the terms used in the DNS in a single
=   document.

  This = document will be the successor to RFC 7719.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-b= is/

There's also a htmlized version = available at:
https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04=

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-terminolog= y-bis-04

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

= --Apple-Mail=_978C75BE-F0E5-408F-ABB8-9DC3F7BD21C5-- From nobody Sat Jan 28 13:22: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 73611129DA1 for ; Sat, 28 Jan 2017 13:22:42 -0800 (PST) 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, 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 uZZemttSsv0A for ; Sat, 28 Jan 2017 13:22:41 -0800 (PST) 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 5A41312989D for ; Sat, 28 Jan 2017 13:22:41 -0800 (PST) Received: from [10.32.60.16] (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 v0SLLX4g038964 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Jan 2017 14:21:35 -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 [10.32.60.16] From: "Paul Hoffman" To: "Ralph Droms" Date: Sat, 28 Jan 2017 13:22:37 -0800 Message-ID: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop Subject: [DNSOP] Terminology issue #8: context X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 21:22:42 -0000 On 28 Jan 2017, at 12:28, Ralph Droms wrote: > I've submitted three issues to the doc repo: > > Issue #8: > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 > > > Add "context" as a facet in the definition of a naming system. A > naming system needs a context in which to perform resolution of a > name. As an example, "locally served DNS zones" (see Issue #10) use > the DNS resolution mechanism through a local context rather than > through the global root. Is that "context" or "possible contexts"? That is, if you consider 1034/1035 as a naming scheme, it seems like there could be "the global context" (the root servers that everyone assumed then) and "a local context" (hosts.txt) or even a mixed context ("first try to resolve in hosts.txt but then go to the root servers if you get an NXDOMAIN", or even the reverse of that). Some naming schemes might have other interesting mixes of context. But I agree that something like this is a common, and commonly-ignored, facet that would be useful to list. --Paul Hoffman From nobody Sat Jan 28 16:20: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 5C8FA129989 for ; Sat, 28 Jan 2017 16:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=deccio.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 eZVdzcnpJY3K for ; Sat, 28 Jan 2017 16:20:17 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 3C4EA126CD8 for ; Sat, 28 Jan 2017 16:20:17 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id j13so85600027iod.3 for ; Sat, 28 Jan 2017 16:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=IL9ibqfTKyKHZtAtPUIbm3kpplir+m9dio3epLey2RY=; b=cbkMz+ZaKSmdhJrxosF+fDwDmEjJtj8Iqxifn+sShjVC8JjnThI79AOVzzJwHgarX+ 4/+ptjHw0+xFw62NweY/UI9+91y1/7ikszQMRSybR1N0JkeWHA/wr+N5YhS3lbz9SsGO Sedz7bVRAfLaAl7IuE5H4LoymqQdlpWt09YiE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=IL9ibqfTKyKHZtAtPUIbm3kpplir+m9dio3epLey2RY=; b=Sr27DLomguOi5JOV8zHj+r9ryYFVqexMA7YlGFhXdGQqA8KgK1LYCqjFYmsVe02hJE 86WCOEMAkkQyEhwfXekYDVINn4QRXqsFFCiOyQvGduZIl389sy8BSopDEoOJY88fr+zD udjGjCn8Wk23U377dLFOPa4K9rM+i+KZWo3PlfpAb2vObF2BfNQLFQj4GD0cSKkNcqq9 WGyw3fLjpJbV2sePDWY7WERZ97Q0HDmt6Mw3GAXpKJh41uMc5gIpUI7J9Mav1kozKTgf zlLItpP7+AXvXtnnMNM1tXBb1y735LAoZMMQdz7VGREbdwC4oZ7Mqfc/hsod8Ha1aiEZ hfJg== X-Gm-Message-State: AIkVDXIbJCQYMJlBcNTIPiNKvQRsi6Bj7NGG0PymWbdgBFVgRreceknKFVILan5GCFdfew== X-Received: by 10.107.132.100 with SMTP id g97mr13062907iod.174.1485649216299; Sat, 28 Jan 2017 16:20:16 -0800 (PST) Received: from [192.168.1.6] (c-24-10-162-10.hsd1.ut.comcast.net. [24.10.162.10]) by smtp.gmail.com with ESMTPSA id 202sm3958762ith.7.2017.01.28.16.20.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 16:20:15 -0800 (PST) From: Casey Deccio Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Sat, 28 Jan 2017 17:20:14 -0700 To: dnsop X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [DNSOP] Terminology draft - validation nits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 00:20:20 -0000 Thanks for the efforts that went into the new revision of the DNS = Terminology draft. Just a few comments on the new "Validation" section: > The first two definitions above consider the only validity of... Should be "only the" instead of "the only" (that typo was inherited from = the text I contributed). > The terms "authentication" and "verification" are used=09 > interchangeably with "validation" in the sense of the third=09 > definition above. In the sense of (only) the third definition, only "authentication" is = interchangeable with "validation". However, "verification" and = "validation" are interchangeable for all three definitions. This can be = seen by searching "verify" and "verification" in RFC 4033 and RFC 4034, = for example. My recommendation is that 1) this sentence is rewritten as follows: > The term "verification" is used=09 > interchangeably with "validation", in the sense of the third=09 > definition above. 2) either the term "Validation:" is changed to = "Validation/Verification:" and/or a new term is added: "Verification: = (see Validation)"; If some of the references (e.g., from RFC 4033) for verification should = be added to the text, then I can help with that, but I'm not sure it's = necessary. Casey= From nobody Sat Jan 28 17:45:36 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 79238120726 for ; Sat, 28 Jan 2017 17:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=deccio.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 xkZBE2OalpTf for ; Sat, 28 Jan 2017 17:45:34 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 4ABB5120725 for ; Sat, 28 Jan 2017 17:45:34 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id l66so86499237ioi.1 for ; Sat, 28 Jan 2017 17:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=oZj+RdVe7FQkNZJPT8CXLehsDR2VQVbh6gTeayFW2AM=; b=RvYHa75AD6RK+/TV01igFvxOVVilinkQ7i0R8AV1U4qLzLoBxNEpQUBMzACQTLe5VV P2BZHpyiOmwEVQey9USO5955dOExhgQ9wf9vL7k9v5kqNXA5xG0QATSZXKGuu/Po0D/6 j+sppGsapYDr0zJyA51o1QbNms3nBvVom56Yw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=oZj+RdVe7FQkNZJPT8CXLehsDR2VQVbh6gTeayFW2AM=; b=pdjytsMYyaf/ndY2+mjAppQ+8p+BoO7Wfi14FYXcCRUg9ME0nCaUpJJQDnndQxHkX8 ixlQky1qhnE2FVrjqQTQbhkUcRCbzIgtQQdoJ51orWmRc4SxxSUrL1qikix4g4Ei51Fw xvxB09nkOa70kqxQbd9+KuhODsXp3MTHL0cW2TH7qp7MlTxHRc0CHHWl2nY1TnZXr2zK GHRY6A1c0htfdIulrPpAD4Ge1hEG8Ppqc+4lgEAqPE+iJz3kFDSAEV9+CZKy1dxPz+XX 5/f0GG71F3ARQcZYzT2i8DcB8aoY/EzC/o8pV13h+8tMqNBnGrU0lpfRK0V6YKzR/zAS 6oyw== X-Gm-Message-State: AIkVDXK5JT12kUBS4NWb+lOO6GE00sLvbsrMkPJbe/9GpzYzBj746bnmOXt5mgnn1bYVsA== X-Received: by 10.107.16.217 with SMTP id 86mr13461042ioq.2.1485654333315; Sat, 28 Jan 2017 17:45:33 -0800 (PST) Received: from [192.168.1.6] (c-24-10-162-10.hsd1.ut.comcast.net. [24.10.162.10]) by smtp.gmail.com with ESMTPSA id u63sm5948459ioi.4.2017.01.28.17.45.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jan 2017 17:45:32 -0800 (PST) From: Casey Deccio Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 28 Jan 2017 18:45:30 -0700 References: To: dnsop In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DNSOP] Terminology draft - validation nits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 01:45:35 -0000 > On Jan 28, 2017, at 5:20 PM, Casey Deccio wrote: > > My recommendation is that 1) this sentence is rewritten as follows: > >> The term "verification" is used >> interchangeably with "validation", in the sense of the third >> definition above. > *sigh*. This should have read: > The term "authentication" is used > interchangeably with "validation", in the sense of the third > definition above. Casey From nobody Sun Jan 29 05:26: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 EF716129A1F for ; Sun, 29 Jan 2017 05:26:25 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 MjRzoQa_TxgH for ; Sun, 29 Jan 2017 05:26:24 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 521EF129A14 for ; Sun, 29 Jan 2017 05:26:24 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u25so105578019qki.2 for ; Sun, 29 Jan 2017 05:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WN4sn7o16tQ9khHOjdm6UWR9FKJmVKiqr3yHZEIqKHY=; b=gJCnchmsIYTWpvUKNbUc4WFqT12nmiRxTubNNIdZsLt75JUTmzXKkuCeG/Uzki+qKz KDPnuWTUzmgxH/2aFGw2g9sJWF82ZdN843Uf7cp8nCf7Y2M+LHHiTvPwE+TfjXJTlYyM RILcjIFwQgFcCiHCw3ol3wI0UdnoqJJBD0B4NfZVK+vntrBuKAR/YC12pPBtdHgC4gmh X4wzCsr0tQlOHE3zk+BTHgYr30ZUja3s9Tj8JJMmlLC5lAeQ6iVVL4TPOjhUlVpC1uJb sZtJuZkZR16d1eXDix/f9aZPrljMoP9WZRVpsY1IiAZdvB5jZSa24g1aF8RGq1ayg3bj B1iA== 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=WN4sn7o16tQ9khHOjdm6UWR9FKJmVKiqr3yHZEIqKHY=; b=nVsK9Rpjr5rTq2ZMUlT0dhS3j7k3pGySwvgurOStdhj8HcmHKH9/NtPdkSBObqIIgM UTXlHF7nEWynC/St7RKvjaxd+Ef0/xzSLjmr53sdbmRl74r8mK92lBLHHtNa4ha5329I qkTYZ5KLwCuCN8Nxg7szS18ugHRctQVSS5aCYwxxVJVDsI7TJpCL13Da6Xx6728LpcjT 6iCQKv8gVeRtbUH307yyXN52E5U6ODR88EnjBhB3tzH1odJxJQlAMHRWEae868xzHne+ KNblf5kxj3C45WZ7v9tBMCROhiRD2WjVPJcUDgTm5UvKJX2XFHxdL6FetxuXiqWJi4TV oh+A== X-Gm-Message-State: AIkVDXJrzCd6XU9XrNrG5qy+I4g2R4z7j4G6msmDCT9I5Kbl/tAIKrNlNYvTSrzLEZPUJQ== X-Received: by 10.55.212.22 with SMTP id l22mr16388552qki.48.1485696383321; Sun, 29 Jan 2017 05:26:23 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:f5d5:7879:99a8:b2dc? ([2601:18f:801:600:f5d5:7879:99a8:b2dc]) by smtp.gmail.com with ESMTPSA id b190sm9349131qkg.32.2017.01.29.05.26.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 05:26:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org> Date: Sun, 29 Jan 2017 08:26:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Terminology issue #8: context X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 13:26:26 -0000 > On Jan 28, 2017, at 4:22 PM, Paul Hoffman = wrote: >=20 > On 28 Jan 2017, at 12:28, Ralph Droms wrote: >=20 >> I've submitted three issues to the doc repo: >>=20 >> Issue #8: = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 = >>=20 >> Add "context" as a facet in the definition of a naming system. A = naming system needs a context in which to perform resolution of a name. = As an example, "locally served DNS zones" (see Issue #10) use the DNS = resolution mechanism through a local context rather than through the = global root. >=20 > Is that "context" or "possible contexts"? That is, if you consider = 1034/1035 as a naming scheme, it seems like there could be "the global = context" (the root servers that everyone assumed then) and "a local = context" (hosts.txt) or even a mixed context ("first try to resolve in = hosts.txt but then go to the root servers if you get an NXDOMAIN", or = even the reverse of that). Some naming schemes might have other = interesting mixes of context. >=20 > But I agree that something like this is a common, and = commonly-ignored, facet that would be useful to list. I see your point about "possible contexts". I was thinking of what's = needed for the evaluation of one specific name. Another way to describe = the facet is what are the possible contexts. How about: * Contexts that can be used for resolving a name and obtaining its = associated data, and the way in which a context is specified for = resolution of a name I'd like to discuss your example a little. In my opinion, hosts.txt = lookup and DNS are two different naming systems. They happen to share = the same name syntax but use different resolution methods. The client = name resolution code gets handed a name from an app, and then uses one = or more naming systems - in sequence, if more than one - to resolve the = name. In your example, the client code might go to the hosts.txt naming = system first and then the DNS naming system. But I'm quite naive about the details and it may be common practice to = consider both hosts.txt and DNS server resolution part of the DNS naming = system. - Ralph >=20 > --Paul Hoffman From nobody Sun Jan 29 14:23: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 D6BD81296B2 for ; Sun, 29 Jan 2017 14:23:21 -0800 (PST) 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] 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 0Z_ex8XaCpH6 for ; Sun, 29 Jan 2017 14:23:20 -0800 (PST) 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 AD75512969F for ; Sun, 29 Jan 2017 14:23:20 -0800 (PST) Received: from [10.32.60.26] (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 v0TMMBL1091376 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Jan 2017 15:22: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 [10.32.60.26] From: "Paul Hoffman" To: "Casey Deccio" Date: Sun, 29 Jan 2017 14:23:16 -0800 Message-ID: <4A6ED111-AF66-40BA-9C51-6C6AFE342348@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Terminology draft - validation nits X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 22:23:22 -0000 Added as Issue 11: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/11 From nobody Sun Jan 29 14:32: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 CB1BB1296B8 for ; Sun, 29 Jan 2017 14:32:30 -0800 (PST) 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] 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 lRUSG702pkMW for ; Sun, 29 Jan 2017 14:32:29 -0800 (PST) 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 6D38B1296B2 for ; Sun, 29 Jan 2017 14:32:29 -0800 (PST) Received: from [10.32.60.26] (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 v0TMVLQA091505 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Jan 2017 15:31:22 -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 [10.32.60.26] From: "Paul Hoffman" To: "Ralph Droms" Date: Sun, 29 Jan 2017 14:32:26 -0800 Message-ID: <36CBF217-3514-4E1A-A7AA-5C2897247543@vpnc.org> In-Reply-To: References: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Terminology issue #8: context X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 22:32:31 -0000 On 29 Jan 2017, at 5:26, Ralph Droms wrote: >> On Jan 28, 2017, at 4:22 PM, Paul Hoffman >> wrote: >> >> On 28 Jan 2017, at 12:28, Ralph Droms wrote: >> >>> I've submitted three issues to the doc repo: >>> >>> Issue #8: >>> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 >>> >>> >>> Add "context" as a facet in the definition of a naming system. A >>> naming system needs a context in which to perform resolution of a >>> name. As an example, "locally served DNS zones" (see Issue #10) use >>> the DNS resolution mechanism through a local context rather than >>> through the global root. >> >> Is that "context" or "possible contexts"? That is, if you consider >> 1034/1035 as a naming scheme, it seems like there could be "the >> global context" (the root servers that everyone assumed then) and "a >> local context" (hosts.txt) or even a mixed context ("first try to >> resolve in hosts.txt but then go to the root servers if you get an >> NXDOMAIN", or even the reverse of that). Some naming schemes might >> have other interesting mixes of context. >> >> But I agree that something like this is a common, and >> commonly-ignored, facet that would be useful to list. > > I see your point about "possible contexts". I was thinking of what's > needed for the evaluation of one specific name. Another way to > describe the facet is what are the possible contexts. > > How about: > > * Contexts that can be used for resolving a name and obtaining its > associated data, and the way in which a context is specified for > resolution of a name I'm OK with that for now, but hope that, after we have a definition for "resolve", that we can remove the "and obtaining its associated data" because that's part of resolving. (Maybe. Hopefully.) > I'd like to discuss your example a little. In my opinion, hosts.txt > lookup and DNS are two different naming systems. They happen to share > the same name syntax but use different resolution methods. The client > name resolution code gets handed a name from an app, and then uses one > or more naming systems - in sequence, if more than one - to resolve > the name. In your example, the client code might go to the hosts.txt > naming system first and then the DNS naming system. Client code often goes to a stub resolver (which we do define in 7719). A stub resolver might use the sequence I gave above; in fact, we know of ones that do. So a naming system might go through different mechanisms when doing resolution. > But I'm quite naive about the details and it may be common practice to > consider both hosts.txt and DNS server resolution part of the DNS > naming system. Fortunately, it is not common on the Internet with respect to the global DNS. Unfortunately, when it does happen, it causes collisions to have negative consequences when names (not just new TLDs) are added to the DNS. --Paul Hoffman From nobody Sun Jan 29 18:47: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 8B0F0129851 for ; Sun, 29 Jan 2017 18:47:49 -0800 (PST) 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, 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 qt6gwyiGN7ao for ; Sun, 29 Jan 2017 18:47:47 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 9EB5B127ABE for ; Sun, 29 Jan 2017 18:47:47 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so116182211qki.2 for ; Sun, 29 Jan 2017 18:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=djR+doNFP/74moF+E2KhdT3HWbnMBsQziEn6incXso0=; b=DhSq0eAB8riuvK2RiXaE0uhjmW606Dm7IQXCAkJvEBN5Kw0QvXzMpfjR7er5ynu0zl 8X4SMYRuRiUFH0nZEOTe6mkxXwY1VIDtim1H8WSigkpnEA3IOUZjq8gYS219CgtOk5Xb K5jAFczbAYuaFG1Jf4kqaqaQUitB73KSei+6/LEkVtFrVpvFyT1EXPmCWLunfO9q3/4D klYLS3NBQAJ3omerrx2W3hwyFuWzACMk2FAM76HJrQ07KF4pcwyDu3a2TSL94Ya97o7Q 1lqSWOqciC4Ws8wiybln6Mq1cV0Lra1iMM+IYkmh22kGc+BOT5n9Vf78hA5W5BOAHt9V pXRA== 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=djR+doNFP/74moF+E2KhdT3HWbnMBsQziEn6incXso0=; b=a/nVFbxw1+lmXlMtzo/q09NS6xsiecxUl5SrYgvl/xbUZNzGJH3rpoITwe24dNiyGS GyJU6eeSFv/rtcD4qz7S5+LwTSoV7afIt3yhIVWxO4QXqIIoBXY1zM6iGvXvE9MbRyOm iAPxOyV2iBL069R1m9+3gjBGDZyUbNnraz1bflCnhoGPPE3bLWqyINkjIFtp5XnQiaje U/YuLrQ7p4nxVVD3GBZRIbUqkGSz89QL1Q18r3OKRs4m5Y1vciUovLoYQakGFW8uLhf/ xhWeSExpJnAIPe3gqnGidF0mlLvcnGc3cTNYjDm3Ebf9mg2cEJkyTL87A0fksy7BL36J vY8A== X-Gm-Message-State: AIkVDXKV7WzshpIWIokDqTE+rhMKN7vZjudJli+ROjNOXUEQvIs8V7vwv6ARhaCUCbFnig== X-Received: by 10.55.157.17 with SMTP id g17mr20827626qke.122.1485744466641; Sun, 29 Jan 2017 18:47:46 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:4145:3c3b:7a77:ba0? ([2601:18f:801:600:4145:3c3b:7a77:ba0]) by smtp.gmail.com with ESMTPSA id k19sm10935797qtf.37.2017.01.29.18.47.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 18:47:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ralph Droms In-Reply-To: <36CBF217-3514-4E1A-A7AA-5C2897247543@vpnc.org> Date: Sun, 29 Jan 2017 21:47:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C46C00E-B040-4D49-8032-424187491C7B@vpnc.org> <36CBF217-3514-4E1A-A7AA-5C2897247543@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dnsop Subject: Re: [DNSOP] Terminology issue #8: context X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 02:47:49 -0000 > On Jan 29, 2017, at 5:32 PM, Paul Hoffman = wrote: >=20 > On 29 Jan 2017, at 5:26, Ralph Droms wrote: >=20 >>> On Jan 28, 2017, at 4:22 PM, Paul Hoffman = wrote: >>>=20 >>> On 28 Jan 2017, at 12:28, Ralph Droms wrote: >>>=20 >>>> I've submitted three issues to the doc repo: >>>>=20 >>>> Issue #8: = https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8 = >>>>=20 >>>> Add "context" as a facet in the definition of a naming system. A = naming system needs a context in which to perform resolution of a name. = As an example, "locally served DNS zones" (see Issue #10) use the DNS = resolution mechanism through a local context rather than through the = global root. >>>=20 >>> Is that "context" or "possible contexts"? That is, if you consider = 1034/1035 as a naming scheme, it seems like there could be "the global = context" (the root servers that everyone assumed then) and "a local = context" (hosts.txt) or even a mixed context ("first try to resolve in = hosts.txt but then go to the root servers if you get an NXDOMAIN", or = even the reverse of that). Some naming schemes might have other = interesting mixes of context. >>>=20 >>> But I agree that something like this is a common, and = commonly-ignored, facet that would be useful to list. >>=20 >> I see your point about "possible contexts". I was thinking of what's = needed for the evaluation of one specific name. Another way to describe = the facet is what are the possible contexts. >>=20 >> How about: >>=20 >> * Contexts that can be used for resolving a name and obtaining its = associated data, and the way in which a context is specified for = resolution of a name >=20 > I'm OK with that for now, but hope that, after we have a definition = for "resolve", that we can remove the "and obtaining its associated = data" because that's part of resolving. (Maybe. Hopefully.) Hm. I hadn't noticed I used the words "resolving" and "resolution" = without definition (either mine or elsewhere in the doc). I'll also = admit that I'm still framing this discussion in my head in terms of my = PhD work of 30 years ago, when papers by Shoch and Saltzer were a little = more current and we had a lot less operational experience cluttering the = conversation. Looking back more carefully at the other facets of a naming system, how = about: * Contexts in which the protocol is applied to get data from a name, and = the way in which a context is specified for that application of the = protocol >=20 >> I'd like to discuss your example a little. In my opinion, hosts.txt = lookup and DNS are two different naming systems. They happen to share = the same name syntax but use different resolution methods. The client = name resolution code gets handed a name from an app, and then uses one = or more naming systems - in sequence, if more than one - to resolve the = name. In your example, the client code might go to the hosts.txt naming = system first and then the DNS naming system. >=20 > Client code often goes to a stub resolver (which we do define in = 7719). A stub resolver might use the sequence I gave above; in fact, we = know of ones that do. So a naming system might go through different = mechanisms when doing resolution. Following the pointers to RFC 1123, it seems a stub resolver only = performs DNS name resolution. Not meaning to be pedantic, in my opinion = there is another type of resolution mechanism in a client, which chooses = between different naming systems and contexts, one of which is the = global DNS (accessed through the stub resolver). I understand that = draft-ietf-dnsop-terminology-bis is about DNS terminology, but if we = agree about that mechanism for choosing among naming systems, we should = consider naming and defining it in draft-ietf-dnsop-terminology-bis. >=20 >> But I'm quite naive about the details and it may be common practice = to consider both hosts.txt and DNS server resolution part of the DNS = naming system. >=20 > Fortunately, it is not common on the Internet with respect to the = global DNS. Unfortunately, when it does happen, it causes collisions to = have negative consequences when names (not just new TLDs) are added to = the DNS. Thanks for the clarification... - Ralph >=20 > --Paul Hoffman From nobody Mon Jan 30 10:16: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 D6DD9129A6C for ; Mon, 30 Jan 2017 10:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 gjR_x0nNzsS2 for ; Mon, 30 Jan 2017 10:15:59 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 46368129578 for ; Mon, 30 Jan 2017 10:15:59 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id j82so99498460ybg.1 for ; Mon, 30 Jan 2017 10:15:59 -0800 (PST) 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=g0BCM84J3zQpZKX4eHhD+6fhS0lpmxPYtwyfH+G2T8c=; b=PyuR/S/zEAbWcd4pBA9Z/dWTfDm1elbepp+AlQCXDlYomtC+t6dzgfjMQlwanq4Omf 5jC0eo3rGi1yrxqdj2MrthrQJW6Ljr31z93SUsqGJpVYIoZREbyRQNSLFW8Fnr6cgPEV K2F1FWSw077FG24liZFMQ6nSQrzlrgi6ROYPNdnR3h5yTc3h8SK4IaW/W46W286UCX/g lUoigHUKhXVZqkf61g9ZV0GwQpAS4z1k03GArM81Cpn50zx3ivnG47pEa4qJD9BEPaKU aiHwmrFZORUGKX2znZVggbRo9WdZyocmGtiQfRR9DKZQtnPpswyQDjFynxhrLDZBg2Mu Ra6g== 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=g0BCM84J3zQpZKX4eHhD+6fhS0lpmxPYtwyfH+G2T8c=; b=OmLPQ/H93+ZF0SEkD4fkn+IotKyWN/3iPUSLlxYKdHE6XiWpFikOicLw7P/ISHh5N2 mGUtRQiy1EhTYk1L8TbKTrMaAx0rsT5TJhzSs7oeqlbKo6RdY20Zb6z0/dVRfRKTOMKi C9XH8DBZNRimAv0UZvz6mgrsPpFvYB5BzujccHOqJ1SLkCNAxxMkan965LqKjRPJPcIt EaCyeQC9vbcnkcvxt9bb0kylu4iDTCQg9obUJC6VxmRduYww1+tHw80OyUQXkvmDDQ9q xZin+mMkPaY72/55nhzeyCUCCb/ncTn5BJ8+xCnCABc0nJGy8Zt2qxpfAHwbcUzHCc7B NYSw== X-Gm-Message-State: AIkVDXLbeON0cosIC/4dTHxYUzHggdOrVss7lHOlm1w6roricYe64++vnPfjYz0WAh8ePL/qeqsVQeO3OYBRlZ+a X-Received: by 10.129.81.12 with SMTP id f12mr15582508ywb.80.1485800158259; Mon, 30 Jan 2017 10:15:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.237.68 with HTTP; Mon, 30 Jan 2017 10:15:57 -0800 (PST) In-Reply-To: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> References: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> From: Bob Harold Date: Mon, 30 Jan 2017 13:15:57 -0500 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11463018a4059f054753ce75 Archived-At: Cc: IETF DNSOP WG Subject: Re: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 18:16:02 -0000 --001a11463018a4059f054753ce75 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 27, 2017 at 1:12 PM, Paul Hoffman wrote: > The authors have tentatively made some substantial changes to the draft, > to define "domain name", "global DNS", and "private DNS" in a manner that > can be used by other work in the IETF, particularly around RFC 6761. Our > first cut of definitions are in the new draft, but we fully expect > significant discussion in the WG before there is even rough consensus. We > are not even sure that the WG will agree with the idea of adding "global > DNS" and "private DNS" to the document. The authors are not even sure they > agree with all of this. > > At the same time, we think that it would be easier to track open issues in > our GitHub repo at https://github.com/DNSOP/draft > -ietf-dnsop-terminology-bis rather than in the document as comments. To > be clear, the discussion of how issues are to be resolved should be mostly > done on the mailing list, but using GitHub to track issues might give > easier-to-follow history of the discussions. We also are open to using > GitHub for pull requests for specific changes to the document. > > As a final note, this version of the draft also has some changes not > related to the above, and we encourage review of those changes, plus > anything else in the draft, of course. > > --Paul Hoffman > > On 27 Jan 2017, at 10:08, 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 : DNS Terminology >> Authors : Paul Hoffman >> Andrew Sullivan >> Kazunori Fujiwara >> Filename : draft-ietf-dnsop-terminology-bis-04.txt >> Pages : 34 >> Date : 2017-01-27 >> >> Abstract: >> The DNS is defined in literally dozens of different RFCs. The >> terminology used by implementers and developers of DNS protocols, and >> by operators of DNS systems, has sometimes changed in the decades >> since the DNS was first defined. This document gives current >> definitions for many of the terms used in the DNS in a single >> document. >> >> This document will be the successor to RFC 7719. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-04 >> > > > 2. Names Global DNS: Administration of names -- I think we need to add IETF to this section as an administrator. -- Bob Harold --001a11463018a4059f054753ce75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2017 at 1:1= 2 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
The authors have tentatively= made some substantial changes to the draft, to define "domain name&qu= ot;, "global DNS", and "private DNS" in a manner that c= an be used by other work in the IETF, particularly around RFC 6761. Our fir= st cut of definitions are in the new draft, but we fully expect significant= discussion in the WG before there is even rough consensus. We are not even= sure that the WG will agree with the idea of adding "global DNS"= and "private DNS" to the document. The authors are not even sure= they agree with all of this.

At the same time, we think that it would be easier to track open issues in = our GitHub repo at https://github.com/DNSOP= /draft-ietf-dnsop-terminology-bis rather than in the document as c= omments. To be clear, the discussion of how issues are to be resolved shoul= d be mostly done on the mailing list, but using GitHub to track issues migh= t give easier-to-follow history of the discussions. We also are open to usi= ng GitHub for pull requests for specific changes to the document.

As a final note, this version of the draft also has some changes not relate= d to the above, and we encourage review of those changes, plus anything els= e in the draft, of course.

--Paul Hoffman

On 27 Jan 2017, at 10:08, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= DNS Terminology
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Paul= Hoffman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Andrew Sullivan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kazunori Fujiwara
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-terminology-bis-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 34
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-27

Abstract:
=C2=A0 =C2=A0The DNS is defined in literally dozens of different RFCs.=C2= =A0 The
=C2=A0 =C2=A0terminology used by implementers and developers of DNS protoco= ls, and
=C2=A0 =C2=A0by operators of DNS systems, has sometimes changed in the deca= des
=C2=A0 =C2=A0since the DNS was first defined.=C2=A0 This document gives cur= rent
=C2=A0 =C2=A0definitions for many of the terms used in the DNS in a single<= br> =C2=A0 =C2=A0document.

=C2=A0 =C2=A0This document will be the successor to RFC 7719.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draf= t-ietf-dnsop-terminology-bis-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-dnsop-terminology-bis-04


=C2=A02. Names=C2=A0
Global DNS:
= Administration of names --
I think we need to add IETF to this s= ection as an administrator.

--=C2=A0
Bob Harold



--001a11463018a4059f054753ce75-- From nobody Mon Jan 30 10:49:30 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 6E08B129566 for ; Mon, 30 Jan 2017 10:49:29 -0800 (PST) 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=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 fM0TUXu-oReV for ; Mon, 30 Jan 2017 10:49:27 -0800 (PST) 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 44F4F129A98 for ; Mon, 30 Jan 2017 10:49:27 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 11so139117871qkl.3 for ; Mon, 30 Jan 2017 10:49:27 -0800 (PST) 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=73mpT33TsIc/bwd+FiQGMT9NzH2JUgwyj1hM6q4sq54=; b=dElWMPHVdsojVuJsisrNeIx8ryCZebcx3AjNi1NhE+UNeddx5qZatUr7h4Bq+gi2q5 M8+FhFx98ox+SaVRH75XyGafokenv9z/+gOGPdLLLOt6qsw1TmZuAaRdFMCMEYllrIwG QA38oaC1mPXIbEfwM/QA+VbUN8xz11v9IT0NAf8Lq8AEWxHh4MHIqNU+qz40kOkOkhNq RBy1LjKOPOz4BujcwRKnZVey3ZXTI9zN+R9PG6DLg2gKf5x+SGiz0DLUc0htsKXgvVLA JbCV6QZfJZorQbtoAdXDS/vDa+z25UJsyZ2uMABxvKaKNXlKltHOJ2ImwyTMZ+7OiRmn N/PQ== 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=73mpT33TsIc/bwd+FiQGMT9NzH2JUgwyj1hM6q4sq54=; b=Y6h7YlxFwsvJist4ZN/CL7ZvzoNIZQDa4LVWOEs9sapozguSqNME+Fr0ENIvhIgOZy eqp5GsZhFAcwNf0gKIFYtqXgpXQmz4OvXPXQdAIqY4L67YCdRLs0u5k16bDwVh6ul/6H lpK6IeMByC0Nw8G2XHo2WLaCYD+QrIhdZ3/PRODOvXWgoGfCZUB87VgA4hFIvQgN6mqS ftK9TRYd7eaTfYViWR/Z76frBtOaJ5RuKgNXGu9th8m8uVg2jaijGOOVY7QRv6GbFWEL EKsBZmQgSFZ+0Jpu8XECCp1xGuapHTSbTFZMfE5wQrvuOwBJhtw6+XC0biSXELornpsa h9EA== X-Gm-Message-State: AIkVDXLfvX36W8wpQwORD6T1pRUR8ipnS84NR5kKAv3JvyWdoT55B3MHxvikz/vQMpwbWdD2njsCG6TJ/3+p91nu X-Received: by 10.55.20.105 with SMTP id e102mr22452413qkh.35.1485802166024; Mon, 30 Jan 2017 10:49:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Mon, 30 Jan 2017 10:48:55 -0800 (PST) In-Reply-To: References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> <541DBEE0-ACAF-4BAE-95D4-A1080FD9DDAC@gmail.com> From: Warren Kumari Date: Mon, 30 Jan 2017 13:48:55 -0500 Message-ID: To: tjw ietf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dnsop , Suzanne Woolf , Ralph Droms Subject: Re: [DNSOP] getting back to our work on special use names X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 18:49:29 -0000 So, clearly we are not going to be having an interim on the week of January 30th. For those trying to follow along at home, I heard (off-list, through a 3rd party) that the interim is supposed to be virtual. That means that it only needs one week notice, but we've missed that deadline as well. There was discussion of having an interim before BA, then before Berlin, then before Seoul. The Special Use Names topic was specifically not given time on the agenda in Seoul, instead being "saved" for the interim (see my Jan 16 email, and below). We've repeatedly been told that this is an important topic (and we see pressure from e.g homenet, ipv4only, SSAC090, etc), and that it will get the attention that it deserves -- but this doesn't seem to be happening.... On Thu, Jan 26, 2017 at 1:23 PM, tjw ietf wrote: > > I think updating alt-tld draft to point to the specific problems in sutld= -ps > to be useful. > > I am holding out hope that alt-tld will be unstuck and kicked down the ro= ad. > I also am holding out for a pony. Yes, but unlike a pony there is a really easy way to get movement on alt-tld -- you clicked the "Park" button on 2015-11-17 -- it can be unparked equally easily. I'd been told numerous times that it would be unparked and WGLCed once a design team was formed, then once an initial document was published, then once a document was actually adopted; this hasn't happened. If alt-tld had been moved through the working group as expected, it would have provided an opportunity for people to experiment and take some of the pressure off -- for example, home.alt *might* have been a reasonable option for homenet. I'd been (mostly!) patiently waiting for this to be unparked with the understanding that the SUN topic would actually get attention, but I don't really see this happening. Can alt-tld be unparked so that we can actually discuss it? Because the process has been going on for so long, I thought it would be useful to provide a timeline. The timeline is abbreviated; if I go back through mail on this topic to add more detail, I will just become further disappointed: ~ 2013. Topic of Special Use Names began simmering - growing concern/realization that issues will arise regarding in which context names should be resolved. Nov 13, 2013 - draft-grothoff-iesg-special-use-p2p-names-00 published. February 10, 2014 - draft-wkumari-dnsop-alt-tld-00 published. May 2015 - DNSOP Interim meeting June 2015 - draft-ietf-dnsop-alt-tld adopted July 2015 - IETF93 (Prague). Design Team announced. Call for volunteers for design team[0] October 2015 - draft-adpkja-dnsop-special-names-problem published Nov 2015 - IETF94 (Yokohama). Concerns raised about status and progress, lack of replies to the volunteers, repeated statements that the process would be transparent and that it would move along.[1] Nov 2015 - draft-ietf-dnsop-alt-tld parked -- "Waiting for the 6761 design team to sort out the bigger issues before moving this forward." April 2016 - IETF95 (Buenos Aires). ARCING BoF -- large amounts of useful content here, reasonable support for .alt. April 2016 - draft-tldr-sutld-ps published. Joint presentation. April 2016 - numerous requests to start Call for Adoption / some other way to help WG choose between adpkja-dnsop-special-names-problem and tldr-sutld-ps. Told CfA would start before[3] IETF96, then would occur during IETF96, then "immediately after IETF96" July 2016 - IETF96 (Berlin): draft-adpkja-dnsop-special-names-problem: Geoff Huston, draft-tldr-sutld-ps: Ted Lemon, draft-wkumari-dnsop-alt-tld: Warren Kumari. Discussions of an interim [4]. 12 Sept 2016 - Call for adoption stated[5]. 7 Oct 2016 - CfA completes, draft-ietf-dnsop-alt-tld adopted. Nov 2016 - IETF97 (Seoul) - topic specifically not given time, with the understanding an interim meeting would be held soon specifically for this topic. From the video https://www.youtube.com/watch?v=3D13pGB24g--k#t=3D6m52s: =E2=80=9CWorth noting that, as the IESG pointed out today, future progress does not need to wait on a final version of a problem statement document, but we did want to get one adopted and relatively supposed before we moved on. If people have forgotten, the alt-tld document that was parked pending a problem statement. We will be looking if it is time to unpark that. We won=E2=80=99t be discussing this topic further today. But we are planning an interim in a few weeks that will attempt to sort out possible recommendations, if any, for further action. Now that we have a problem statement and active effort on it. But that=E2=80=99= s the status of that topic -- we haven=E2=80=99t abandoned it, frankly we can= =E2=80=99t; we promised the IETF that we would say something, even if it=E2=80=99s =E2= =80=9CWe don=E2=80=99t know what to say=E2=80=9D. But there has been progress, and w= e=E2=80=99re not talking about it further today.=E2=80=9D Terry Manderson: =E2=80=9CWearing my IntAD hat, responsible AD for Homenet. Please be aware that there will be a 6761 app coming forward rapidly, and you may want to prioritize within that space please.=E2=80=9D Paul Hoffman (DNSOP secretary): =E2=80=9CWearing my process weenie hat; you have to wait 4 weeks between announcing when an interim is, and when is. Now you are pushing towards xmas=E2=80=9D Chairs: =E2=80=9CYes, or even new years. Yup, should have said after the 1s= t. Key point is that we are not waiting till Chicago before we do anything else with this, but it=E2=80=99s not immediate either=E2=80=9D. Jan 12th 2017 - "getting back to our work on special use names" says want to WGLC SUTLD before IETF98, and that there will be an interim "during the week of January 30 for further work on this topic". I heard (off-list) that this is a virtual, which needs 7 days instead of 30, but this will still need to be scheduled today or tomorrow (for Feb 2nd or 3rd) if it is still intended to happen next week. So: I hope we can make some substantive progress on the Special Use Names topic. I know I have mentioned this a number of times, and have received repeated apologies and reassurances that the topic will be moved along and that alt-tld will be unparked and moved to WGLC. We had to request the CfA on alt-tld more than 10 times before that was started, and had also made numerous requests for WGLC before it was parked. Special Use Names was a hard topic to begin with -- it has been made much, much harder and more contentious by the delays and similar -- people have either become apathetic and no longer participate, or increasingly entrenched in their positions. At a minimum, I hope that the interim meeting will be scheduled soon, and alt-tld unparked. There's just no reason for further delays. W [0]: https://www.ietf.org/mail-archive/web/dnsop/current/msg15679.html [1]: =E2=80=9C Suzanne: We have clear ideas about how it will be transparent Not sure how to implement this, but make sure whatever we do is transpare= nt Regular meetings, will post minutes Collection point for the input from the WG Do the work, not make the decisions Suzanne: doesn't have to take time in the meetings, but will do whatever it takes to make progress =E2=80=A6 Warren: The chairs asked for volunteers, but we never heard back Is the design team going to grow? Suzanne: the process has not held together well so far Wanted to be sure the work got started Jari Arkko: IESG view is that it is a problem that the IESG should not fix, it should be in the community. Should discuss the process. =E2=80=9C" [3]: https://www.ietf.org/mail-archive/web/dnsop/current/msg17332.html (and more in person) [4]: https://www.ietf.org/proceedings/96/minutes/minutes-96-dnsop [5]: https://www.ietf.org/mail-archive/web/dnsop/current/msg17983.html [6]: https://www.ietf.org/mail-archive/web/dnsop/current/msg19114.html > > tim > > On Wed, Jan 25, 2017 at 9:41 AM, Ralph Droms wrot= e: >> >> >> > On Jan 13, 2017, at 9:47 PM, Warren Kumari wrote: >> > >> > >> > >> > On Thu, Jan 12, 2017 at 1:41 PM Suzanne Woolf >> > wrote: >> > Dear Colleagues, >> > >> > >> > It's time to get back to our work on special use names. As the chairs >> > see it, here's what we need to do between now and IETF 98 (end of Marc= h). >> > We'll be having a DNSOP WG interim meeting shortly, see below. >> > >> > 1. We need to advance the problem statement document, >> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/. Please re= view >> > and comment on the list. We'd like to have a WGLC on it before IETF 98= . >> > >> > >> > Some additional background. >> > The ICANN SSAC (Security and Stability Advisory Committee) recently (D= ec >> > 22nd) published SAC090 - >> > https://www.icann.org/en/system/files/files/sac-090-en.pdf (full discl= osure: >> > I'm an author). >> > >> > It is short, and easily readable -- I'd strongly encourage you to read >> > it (but I'll provide some teasers to tempt you!). >> > It notes that "a central authority to control the way in which domain >> > names are used in all contexts-is both infeasible and undesirable give= n the >> > robustly non-centralized way in which the Internet ecosystem evolves",= and >> > that a coordinated management of the namespace might be best. >> > It also finds that uncoordinated use leads to ambiguity (and >> > instability), and that currently ICANN and the IETF (and others) all >> > allocate from a single namespace. >> > It recommends that ICANN >> > 1: create criteria for determining what labels can be TLDs. >> > 2: figure out how to coordinate with a: the IETF declaring names as >> > "special" (6761) and b: other "private use" names. >> >> I read SAC090 and also recommend that others read it. The second >> recommendation affects the IETF and, specifically, would address some of= the >> problems listed in draft-ietf-dnsop-sutld-ps. >> >> I've reviewed draft-ietf-dnsop-sutld-ps and added some text citing SAC09= 0; >> we'll publish that new revision soon. >> >> > >> > This is a very quick summary, please go actually read it - there are >> > only ~6 pages of actual content, but it recommends coordination with t= he >> > IETF. So, please, let's try and get this moving -- I'd hate it if the = IETF >> > ends up looking more dysfunctional than ICANN :-P >> > >> > >> > Also, ~3 days ago someone posted about .onion (and Special Use Names) = on >> > hackernews -- https://news.ycombinator.com/item?id=3D13370488 . This t= opic is >> > still of interest to a bunch of people... >> > >> > >> > 2. Now that we have a working problem statement, we'd like to see >> > proposals on possible changes to IETF procedures to resolve the issues= we've >> > raised. We're looking for on-list discussion, preferably with posted I= -Ds. >> > >> > These proposals do not have to be limited to work for the DNSOP WG; th= ey >> > may also include work we think belongs in other WGs, or requests to th= e IESG >> > or the IAB (such as liaison statements to groups outside of the IETF). >> > >> > We have had a proposal, for the ALT TLD, before us for some time now, >> > which we put aside while we worked on the problem statement. As part o= f >> > assessing solutions, we need to review >> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ and determi= ne >> > what the WG wants to do with it. Comments to the list, please. >> > >> > Yes please. The document is still parked, but please send me comments >> > *on the draft* and I'll try keep track of them to incorporate. I know = that >> > there is much background which can be culled, I'll post a new version = to >> > GitHub with that done soon. >> >> Now that we have draft-ietf-dnsop-sutld-ps, would there be any benefit t= o >> revising draft-ietf-dnsop-alt-tld to point to the specific problems .alt >> would address? >> >> I was going to suggest 1,$g/alternate/alternative/, but >> consulting Merriam-Webster informs me that "For all intents and purposes= , >> alternate and alternative are synonymous. Oh, well. >> >> - Ralph >> >> > >> > W >> > >> > >> > 3. We're scheduling an interim WG meeting during the week of January 3= 0 >> > for further work on this topic. We'll provide some possible days/times= to >> > the list for feedback shortly, and we can't promise to accomodate ever= yone's >> > schedule constraints but will do our best. >> > >> > >> > best, >> > Suzanne & Tim >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 > --=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 Mon Jan 30 15:44:05 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 11FB01296B0; Mon, 30 Jan 2017 15:43:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148581983506.29884.10422621371134208995.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 15:43:55 -0800 Archived-At: Cc: Tim Wicinski , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-resolver-priming@ietf.org, The IESG , joelja@gmail.com, rfc-editor@rfc-editor.org Subject: [DNSOP] Protocol Action: 'Initializing a DNS Resolver with Priming Queries' to Best Current Practice (draft-ietf-dnsop-resolver-priming-11.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 23:43:55 -0000 The IESG has approved the following document: - 'Initializing a DNS Resolver with Priming Queries' (draft-ietf-dnsop-resolver-priming-11.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ Technical Summary This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS RRSet for the root zone and the necessary address information for reaching the root servers. Working Group Summary This document has been active in the working group for several years. It had strong consensus to adopt and publish. However, due to working group inertia and authors busy schedules, the document stalled several times. It was picked back up recently and the document went through an editing process to streamline the language. This time through the process there was enough attention paid by the working group to address any outstanding issues, provide editorial comments, and see the document through. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli From nobody Mon Jan 30 17:08:30 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 374B11297A7 for ; Mon, 30 Jan 2017 17:08:29 -0800 (PST) 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] 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 YUwXyD5Lqm45 for ; Mon, 30 Jan 2017 17:08:27 -0800 (PST) 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 C67991294AD for ; Mon, 30 Jan 2017 17:08:27 -0800 (PST) Received: from [10.32.60.132] (35-1.lax.icann.org [192.0.35.1]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v0V17Kht045983 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jan 2017 18:07:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 35-1.lax.icann.org [192.0.35.1] claimed to be [10.32.60.132] From: "Paul Hoffman" To: "Bob Harold" Date: Mon, 30 Jan 2017 17:08:26 -0800 Message-ID: In-Reply-To: References: <0D318AAC-5846-4E65-9030-19C91854CA8D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: IETF DNSOP WG Subject: Re: [DNSOP] Big changes in draft-ietf-dnsop-terminology-bis X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:08:29 -0000 On 30 Jan 2017, at 10:15, Bob Harold wrote: >> 2. Names > Global DNS: > Administration of names -- > I think we need to add IETF to this section as an administrator. Could you please say more, maybe with actual text? I can see a few different ways to interpret the words above. --Paul Hoffman From nobody Mon Jan 30 22:06:55 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 23F7B12940F for ; Mon, 30 Jan 2017 22:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 v2txxsriCI_K for ; Mon, 30 Jan 2017 22:06:52 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 97B5A1293FD for ; Mon, 30 Jan 2017 22:06:52 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v0V66p93002729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2017 00:06:51 -0600 Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id F065C1E0049; Tue, 31 Jan 2017 00:06:45 -0600 (CST) Received: from lxdnp31k.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id CA5761E003F; Tue, 31 Jan 2017 00:06:45 -0600 (CST) Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v0V66jSh004784; Mon, 30 Jan 2017 23:06:45 -0700 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v0V66jvO004781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jan 2017 23:06:45 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0294.000; Tue, 31 Jan 2017 00:06:44 -0600 From: "Woodworth, John R" To: "dnsop@ietf.org" Thread-Topic: [DNSOP] FW: New Version Notification for draft-woodworth-bulk-rr-03.txt Thread-Index: AQHSe4el867EeT9Kuk6ZVLNBiobESA== Date: Tue, 31 Jan 2017 06:06:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "Woodworth, John R" , 'shash raghu' , "Ballew, Dean" Subject: [DNSOP] FW: New Version Notification for draft-woodworth-bulk-rr-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 06:06:54 -0000 QWxsLA0KDQpJJ3ZlIHN1Ym1pdHRlZCBhIC0wMyB2ZXJzaW9uIHRvIHByb3ZpZGUgYWRkaXRpb25h bCBjbGFyaXR5IGluIGEgZmV3IGFyZWFzLiAgQWxzbyBpbmNsdWRlZCBpcyBhIG1pbmktRkFRIChi ZWxvdykgYXMgdGhlIGRyYWZ0IGlzIGEgYml0IG9mIGEgbG9uZyByZWFkLg0KDQpBcyB1c3VhbCwg dGhlIG90aGVyIGF1dGhvcnMgYW5kIEkgbG9vayBmb3J3YXJkIHRvIGFueSBxdWVzdGlvbnMsIGNv bmNlcm5zIG9yIGNvbW1lbnRzLg0KDQoNClRoYW5rcywNCkpvaG4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCioqICBJLUQgIkJVTEsg RE5TIFJlc291cmNlIFJlY29yZHMiIE1pbmktRkFRICAgMDEtMzEtMTcgKioNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpRKSBX aHkgZG8gd2UgbmVlZCBCVUxLIFJScz8NCkEpIEJVTEsgaXMgYSB0b29sIGxpa2UgbWFueSBvdGhl cnMuDQogICBJdCB3YXMgZGVzaWduZWQgdG8gaGVscCBzaW1wbGlmeSB0aGUgbWFuYWdlbWVudCBv Zg0KICAgcGF0dGVybiBiYXNlZCAiZ2VuZXJpYyIgcmVjb3JkcyBhbmQgc2NhbGUgdG8gZml0IHRo ZQ0KICAgZ3Jvd2luZyBkZW1hbmQgb2YgSVB2NiBzdXBwb3J0LiBJdCBidWlsZHMgb24gcG9wdWxh cg0KICAgdGVjaG5vbG9neSBjdXJyZW50bHkgdXNlZCB0b2RheSB3aGlsZSBwcm92aWRpbmcgYQ0K ICAgbnVtYmVyIG9mIG1vZGVybiBlbmhhbmNlbWVudHMuIFRoZSBhdXRob3JzIGZlZWwgQlVMSw0K ICAgaXMgdGhlIG5leHQgbG9naWNhbCBwcm9ncmVzc2lvbiBvZiB3aGF0IGlzIGFscmVhZHkNCiAg IGZpZWxkLXByb3ZlbiBhbmQgYWNjZXB0ZWQgaW4gdGhlIGluZHVzdHJ5IHRvZGF5Lg0KDQoNClEp IERvZXMgQlVMSyBjb3ZlciBhbGwgUlIgdHlwZXM/DQpBKSBOby4gVGhlIGRyYWZ0IG9ubHkgY292 ZXJzIEEsIEFBQUEsIFBUUiBhbmQgQ05BTUUgUlIgdHlwZXMuDQoNCg0KUSkgV2hhdCBoYXBwZW5z IGlmIHRoZXJlIGFyZSBvdGhlciBSUnMgd2hpY2ggZmFsbCBpbnNpZGUNCiAgIGEgQlVMSyBwYXR0 ZXJuIHJhbmdlPw0KQSkgQlVMSyByZWNvcmRzIGNhbiBvbmx5IGV4aXN0IHdoZXJlIG90aGVyIHJl Y29yZHMgZG8gbm90LA0KICAgYSBjb25jZXB0IHJlZmVycmVkIHRvIGFzICJSZWNvcmQgU3VwZXJp bXBvc2l0aW9uIiBbNS4xXQ0KDQoNClEpIENhbiBCVUxLIGdlbmVyYXRlZCBSUnMgYmUgRE5TU0VD IHZhbGlkYXRlZC4NCkEpIFRoZSBkcmFmdCBvZmZlcnMgdHdvIEROU1NFQyBzb2x1dGlvbnMsIG9u LXRoZS1mbHkNCiAgIGdlbmVyYXRlZCBzaWduYXR1cmVzIGFuZCBhIHBhdHRlcm4gYmFzZWQgc29s dXRpb24gaW4NCiAgIHRoZSBmb3JtIG9mIGEgc3VwcG9ydCBOUE4gUlIgdHlwZSAoaW5jbHVkZWQg aW4gdGhlIGRyYWZ0KS4NCg0KDQpRKSBJcyBCVUxLIG9ubHkgZm9yIElQdjYgbmFtZXNwYWNlPw0K QSkgTm8sIEJVTEsgaXMgaW50ZW5kZWQgdG8gc2ltcGxpZnkgbWFuYWdlbWVudCBvZiBib3RoIElQ djQNCiAgIGFuZCBJUHY2ICJnZW5lcmljIiByZWNvcmRzLg0KDQoNClEpIFdoeSBub3QganVzdCBz Y3JpcHQgdGhlc2UgcmFuZ2VzLCB1c2UgJEdFTkVSQVRFIG9yDQogICBzaW1wbHkgZm9yYmlkIHRo ZSBsYXJnZXIgb25lcz8NCkEpIFR3byBmdW5kYW1lbnRhbCBnb2FscyBiZWhpbmQgQlVMSyBhcmUg dG8gYmUgYWJsZSB0bw0KICAgcHJvdmlkZSB0aGUgc2FtZSBjYXBhYmlsaXR5IGJlaGluZCBzY3Jp cHRpbmcgYW5kDQogICAkR0VORVJBVEVzIHdpdGhvdXQgdGhlIG1lbW9yeSByZXF1aXJlbWVudHMg YW5kDQogICBiZSBhYmxlIHRvIHRyYW5zZmVyIHRoZSB6b25lIG1haW50YWluZXIncyAiaW50ZW50 Ii4NCiAgIEZvciBleGFtcGxlLCB3aGVuIHlvdSB0cmFuc2ZlciBSUnMgbWFuYWdlZCBieSBhIHNj cmlwdA0KICAgb3IgJEdFTkVSQVRFIHRoZSByZWNlaXZlciBnZXRzICJhbGwiIHJlY29yZHMgYW5k IG5vdA0KICAgdGhlIHNob3J0aGFuZCB1c2VkIHRvIGNyZWF0ZSB0aGVtLiAgQlVMSyB0cmFuc2Zl cnMNCiAgIHRoaXMgaW50ZW50IHNvIHRoZSBjb3B5IGxvb2tzIGp1c3QgbGlrZSB0aGUgb3JpZ2lu YWwuDQogICBTZXZlcmFsIEROUyBTb2Z0d2FyZSBWZW5kb3JzIGFyZSBhbHJlYWR5IHByb3ZpZGlu Zw0KICAgdGhpcyBjYXBhYmlsaXR5IGluIGEgcHJvcHJpZXRhcnkgbWFubmVyLCBCVUxLIG9mZmVy cw0KICAgYW4gb3BlbiAic3RhbmRhcmQiIHdheSB0byBleGNoYW5nZSB0aGVzZSByZWNvcmRzDQog ICB3aGljaCBzY2FsZXMgdG8gZml0IGFueSBzaXplLg0KDQoNClEpIEJVTEsgc3ludGF4IGxvb2tz IGxpa2UgcmVndWxhciBleHByZXNzaW9uLCBpc24ndCB0aGF0DQogICBhIGJpdCB0b28gY29tcGxp Y2F0ZWQ/DQpBKSBCVUxLIGRvZXMgb2ZmZXIgYWR2YW5jZWQgcmVndWxhci1leHByZXNzaW9uLWVz cXVlDQogICBiYWNrcmVmZXJlbmNlcyBidXQgaW4gYSBzaW1wbGlmaWVkIG1hbm5lci4gSW4gZmFj dCwNCiAgIHRoZSAic3RhciIgYmFja3JlZmVyZW5jZSB3aWxsIHdvcmsgZmluZSBpbiBtb3N0DQog ICBzY2VuYXJpb3MgKGUuZy4gIm1lbWJlci0keyp9LmV4YW1wbGUuY29tLiIpLiBOQVBUUg0KICAg UlJzIGN1cnJlbnRseSBwcm92aWRlIGNsaWVudC1hc3Npc3RlZCByZWd1bGFyLQ0KICAgZXhwcmVz c2lvbiBwYXR0ZXJuIHN1YnN0aXR1dGlvbiBzbyBCVUxLIGxldmVyYWdlcw0KICAgYSBmYW1pbGlh ciAiZmVlbCIgd2hpbGUgYWxzbyBwcm92aWRpbmcgc29tZSBvZiB0aGUNCiAgIGhlYXZ5IGxpZnRp bmcuDQoNCi0tDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLTAzLnR4dA0KRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXQ0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd29vZHdvcnRoLWJ1bGstcnItMDMu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBXb29kd29ydGggYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQt d29vZHdvcnRoLWJ1bGstcnINClJldmlzaW9uOiAgICAgICAwMw0KVGl0bGU6ICAgICAgICAgIEJV TEsgRE5TIFJlc291cmNlIFJlY29yZHMNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTAxLTI2DQpHcm91 cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMzANClVS TDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt d29vZHdvcnRoLWJ1bGstcnItMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd29vZHdvcnRoLWJ1bGstcnIvDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLTAz DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXdvb2R3b3J0aC1idWxrLXJyLTAzDQoNCkFic3RyYWN0Og0KICAgVGhlIEJVTEsgRE5TIHJlc291 cmNlIHJlY29yZCB0eXBlIGRlZmluZXMgYSBtZXRob2Qgb2YgcGF0dGVybiBiYXNlZA0KICAgY3Jl YXRpb24gb2YgRE5TIHJlc291cmNlIHJlY29yZHMgdG8gYmUgdXNlZCBpbiBwbGFjZSBvZiBOWERP TUFJTg0KICAgZXJyb3JzIHdoaWNoIHdvdWxkIG5vcm1hbGx5IGJlIHJldHVybmVkLiAgVGhlc2Ug cmVjb3JkcyBhcmUgY3VycmVudGx5DQogICByZXN0cmljdGVkIHRvIHJlZ2lzdGVyZWQgRE5TIHJl c291cmNlIHJlY29yZCB0eXBlcyBBLCBBQUFBLCBQVFIgYW5kDQogICBDTkFNRS4gIFRoZSBrZXkg YmVuZWZpdCBvZiB0aGUgQlVMSyByZXNvdXJjZSByZWNvcmQgdHlwZSBpcyB0aGUNCiAgIHNpbXBs aWZpY2F0aW9uIG9mIG1haW50YWluaW5nICJnZW5lcmljIiByZWNvcmQgYXNzaWdubWVudHMgd2hp Y2gNCiAgIHdvdWxkIG90aGVyd2lzZSBiZSB0b28gbWFueSB0byBtYW5hZ2Ugb3IgcmVxdWlyZSBz Y3JpcHRzIG9yDQogICBwcm9wcmlldGFyeSBtZXRob2RzIGFzIGJpbmQncyAkR0VORVJBVEUuDQoN CiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkNzIDIzMDgsIDQwMzMsIDQwMzQgYW5kIDQwMzUu DQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0KDQotLSBUSEVTRSBBUkUgVEhFIERST0lEUyBUTyBXSE9NIEkgUkVGRVI6DQpU aGlzIGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3Jp emVkIHVzZSBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQg bWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBl LW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55 IGF0dGFjaG1lbnRzLg0K From nobody Tue Jan 31 07:18: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 8676F129890; Tue, 31 Jan 2017 07:18:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148587593254.2430.14973732777369498327.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 07:18:52 -0800 Archived-At: Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:18:52 -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 Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-02.txt Pages : 20 Date : 2017-01-31 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 standards 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-02 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 Jan 31 13:31: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 C7C581295BB for ; Tue, 31 Jan 2017 13:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 gETUPrmYP3d5 for ; Tue, 31 Jan 2017 13:31:47 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 EA7731295B7 for ; Tue, 31 Jan 2017 13:31:46 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id l126so46313286qkc.1 for ; Tue, 31 Jan 2017 13:31:46 -0800 (PST) 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=dirdcNlt7r12zgL8l2/EW3qvkKWtnEp5ZDJsi4ZyUO4=; b=q+ejD5JLKSkOAit8MAdbvE7mFovX1WECBg8kgucZ/N1rdfKsramCD8eqywkRRaT/ej kfcvU1uow4h7Oj7pgPOL9b8XIuXDRTGmlxrfUYJ7/XiGw93+kO+ch02HoYGEF21n+rhy J6ssxtLDjYS9XNJzYJuflxpb/bjpmOwsnCyuY+NJ16M+IK1Wk2nC8jUf5W+kjq+sA3ed dM/NcabNqA2dD1+qA4aCm6qBHQ28sc3B0WdMJV2HCbPhWFNAv/5g1pOR5IzldlR9m5nt A2EEdNAibzh9/MgXLRyEexRqQj4c2oUVTqQg4rAe8tbt3kQvaQnlt3abBbPsJm+GDLTl g7VA== 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=dirdcNlt7r12zgL8l2/EW3qvkKWtnEp5ZDJsi4ZyUO4=; b=o+t+ObMAKgKaWLipeOquk5/j5qr+fq2E7JCgOIPzOB8XSrVcoICZScRXEK3nNNVWI2 Pr/3T+wNXuhWJPSb+SSPgq9VeRWvG+qvD9/5uDYW+clHK5so2GDz07rJlbiiKvmSD742 X0eDRPH5+JkQKvZZb9kxNMI9kLYzFFSeiMHYHByrOuX+7WT54xQF8UBGqJIbLeWJCakF 1WDUznPr+SC8X4N6ZIkg5gUuWT24J4qUhbIqBt09ZT2k2hIoLYHxdGF2buA3mGb+pka9 gNREUPiUqvbG+ZBKLLKz7n1LF6We8HQKoaVjCC3CBrENY+Hrk5PvCHd+Gafxr/MhKrbT KnXA== X-Gm-Message-State: AMke39mhUOXAE/NZAs5smXlIfSSRQBuStIuAyDJUVqNvi4OBaGfA7go6L80T+47sw8xHJ7YZZ80Qhvvi3t3ImA== X-Received: by 10.233.222.197 with SMTP id s188mr3178221qkf.311.1485898305886; Tue, 31 Jan 2017 13:31:45 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 31 Jan 2017 13:31:45 -0800 (PST) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 31 Jan 2017 13:31:45 -0800 X-Google-Sender-Auth: up5pFZAfOYjkpjLkTBuYUaJllbs Message-ID: To: draft-vixie-dns-rpz@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop Subject: [DNSOP] comments on draft-vixie-dns-rpz-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:31:49 -0000 This is my technical comments on draft-vixie-dns-rpz-04 that I promised to submit when I responded to the wg adoption call. Some of the points may be considered "out of scope" if the draft really intends to just describe what's currently deployed, but I nevertheless made these points for the reasons I said in my response to the adoption call. - Abstract This document describes a method for expressing DNS response policy inside a specially constructed DNS zone, and for recursive name servers to use such policy to return modified results to DNS clients. I don't think this document limits its scope to recursive servers as it talks about the "recursive-only" option in Section 6. The same sense of comment applies to some other use of "recursive servers" throughout the document. - Section 4.1.1 The BIND 9 RPZ implementation rejects a prefix length of 0: if (prefix_num < 1U || prefix_num > 128U) { badname(log_level, src_name, "; invalid prefix length of ", prefix_str); return (ISC_R_FAILURE); } I don't know the rationale behind it, but since /0 is not a syntactically invalid prefix it's probably better to describe it explicitly, if the restriction is intentional and especially if this document seeks for wider interoperability among multiple implementations. Furthermore, if the intent is to avoid accidentally apply a policy to too broad addresses, some other shorter prefixes (e.g., /1) may also need a similar consideration. - Section 4.1.1 As in [RFC5952], in order to avoid confusion with octal notation, leading zeroes MUST be suppressed. This reads awkward or confusing to me. First, it could read as if RFC5942 suppresses leading zeros to avoid confusion with octal notation, but as far as I understand it that's not the reason (it's basically just to provide unique and consistent representations.) Second, unlike the case of IPv4 addresses, not all hex block can this confusion; if avoiding the confusion were the reason, there should be no reason for banning '0db8' instead of 'db8'. So I suggest: As in [RFC5952], in order to make the representation unique, leading zeroes MUST be suppressed. - Section 4.2 To control the policy for both a name and its subdomains, two policy RRsets must be used, one for the domain itself and another for a wildcard subdomain. IMO this part of the spec is one of the reasons why abusing zone data to represent filtering policies is not good. I guess (and I know that's actually the case in some real world deployments) in many cases we want to apply the same policy to both 'example.com' and '*.example.com'. So this spec can easily lead to wasting memory for straightforward implementations. Although an implementation could employ an internal compression scheme to save memory, it seems to me to make much more sense to design the spec so a straightforward implementation would just work without a waste in the first place. Following the standard DNS protocol can also result in counter-intuitive results. For example, if you have the following policy records: example.com CNAME . *.example.com CNAME . a.b.example.com AAAA 2001:db8::1 then no policy will apply to a query for b.example.com./AAAA or c.a.b.example.com./AAAA (or other query types than AAAA for that matter). That would be quite likely to be different from what the admin of this config intends to implement (the most likely intended policy would be to return NXDOMAIN for everything on and under example.com except for a.b.example.com./AAAA). We might say an admin of RPZ should be very familiar with all the subtlety of the DNS protocol details like this one, but to me this seems to be another case for designing a better spec at this opportunity. - Section 4.4 Recall also that the target of a CNAME is not added to the response if the QTYPE is ANY Is this guaranteed by a protocol standard? Or is this a requirement to RPZ implementations? (If it's the latter while the former isn't explicitly guaranteed, then I think the current draft should be clearer about it). - Section 5.2 Matches on rules in an RPZ specified earlier in the ordered list of RPZs take precedence over matches on rules in an RPZ specified later. I may miss something, but the concept of "ordered list of RPZs" isn't explicitly described elsewhere (at least earlier) in the draft. I think it should be explicitly documented as part of assumptions. - Section 5.6 When comparing two Response IP Address matches or two NSIP matches on rules within a single RPZ, choose the match whose rule trigger has the longest "internal prefix length". [...] For an IPv4 address trigger, the internal prefix length is the numeric value of its first label plus 96 (that is, 128-32). Does this apply when a response to type ANY query contains both AAAA and A RRsets, i.e., choose the IPv6 or IPv4 address that has the longest internal prefix length among all AAAA and A RRsets? If so, (I think it's better to clarify that explicitly and) it means IPv4 prefixes would tend to be preferred even if they are effectively very short. For example, a /8 (whose internal plen is 104) IPv4 prefix will be preferred over a /64 IPv6 prefix. Depending on the rationale of this precedence it may or may not be ideal (if it's just for making it deterministic it's okay, but if it tries to prefer more specific prefixes then it's probably not). - Section 5.7 The three addresses above are compared as these 128-bit hexadecimal numbers, respectively: 0x000000000000000000000000c0000200, 0x000000000000000000000000c0000280, and 0x20010db80000000000000000c0000280. Thus, the first IPv4 address is most preferred and the IPv6 address is least preferred. The latter part of the previous comment applies here; with this logic IPv4 prefixes will be generally preferred over IPv6 prefixes (when the internal plen is identical) since in practice most IPv6 addresses contain non-0 bits in the first 96-bit part. - Section 6 RPZ rules do not apply to synthetic data generated by using RPZ rules. For example, if RPZ supplies a CNAME pointing to a walled garden, RPZ policies will not be used while following that CNAME. Consider the following policy record: a.example.com CNAME garden.example.org. and assume following the CNAME target results in the chain as follows: garden.example.org. CNAME a.example.com. a.example.com. AAAA 2001:db8::1 Then should this server includes these two RRs as well as the first CNAME in the answer? If so, it would result in "CNAME and other type for the same name" and violate the protocol standard (forgetting RPZ violates the standard anyway). Is it okay? - Section 6.1 For each DNS RPZ configured for use by a recursive name server, it SHOULD be possible to specify a single, OPTIONAL overriding policy action to be used for all policy triggers found in that RPZ. I'd suggest explaining what "override" means in a bit more detail. I know what it means from the actual behavior of existing implementations, but I'm not sure if this is clear enough just from this text. Also, I'm not really sure for what this overriding is useful except DISABLED (for which the draft explains its possible purpose). Some more background motivation would be helpful for readers and for implementers who will end up supporting these SHOULDs. - Section 7 Because minimal data latency is critical both to the prevention of crime and abuse and to the withdrawal of erroneous or outdated policy, a DNS RPZ producer SHOULD also make every effort to minimize data latency, including ensuring that NOTIFY messages are sent in a timely manner after each change of the DNS RPZ on the master server. I'd note that this is another case why abusing DNS zone data wouldn't be a good choice: notifies are unreliable and often delayed (if for a short period). - Section 9 (or regarding NSDNAME and NSIP in general) RPZ checks can add significant processing and network costs to the processing of recursive DNS requests. This is particularly true of rules with NSDNAME and NSIP triggers. [...] I wonder how widely these triggers are used. My personal experiences are of course very limited, but none of the large scale RPZ deployments I know of uses these triggers. On the other hand the implementation of these would be quite complicated and error prone in addition to the performance overhead described in the draft text, and, in fact, the support for these triggers certainly makes the BIND 9's RPZ implementation even more unreadable. So, depending on the actual deployment status, we might want to make these triggers optional or even excluded from a spec aiming to be a base of broader interoperability. -- JINMEI, Tatuya From nobody Tue Jan 31 16:05: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 264F2129679 for ; Tue, 31 Jan 2017 16:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 lK-hDEp078NX for ; Tue, 31 Jan 2017 16:05:48 -0800 (PST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 B8BD5129672 for ; Tue, 31 Jan 2017 16:05:47 -0800 (PST) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v1105Whr097030 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) env-from ; Wed, 1 Feb 2017 00:05:32 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v1105VsA097029; Wed, 1 Feb 2017 00:05:31 GMT Date: Wed, 1 Feb 2017 00:05:31 GMT From: Vernon Schryver Message-Id: <201702010005.v1105VsA097029@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] comments on draft-vixie-dns-rpz-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 00:05:50 -0000 > From: =?UTF-8?B?56We5piO6YGU5ZOJ?= > To: draft-vixie-dns-rpz@tools.ietf.org > Cc: dnsop > promised to submit when I responded to the wg adoption call. Some of > the points may be considered "out of scope" if the draft really > intends to just describe what's currently deployed, Yes, that's the remit. > This document describes a method for expressing DNS response policy > inside a specially constructed DNS zone, and for recursive name > servers to use such policy to return modified results to DNS clients. > > I don't think this document limits its scope to recursive servers as > it talks about the "recursive-only" option in Section 6. The same > sense of comment applies to some other use of "recursive servers" > throughout the document. The "recursive-only" option concerns bits in the headers of requests from DNS clients. When a DNS client sends a request with RD=0 to a recursive server, that recursive server does not become other than a recursive server. In addition, it does not sound useful for an authoritative DNS server to use RPZ to rewrite the DNS data for which it is authoritative. If I were starting RPZ today, I'd fight harder to ignore the RD bit and so not have the "recursive-only yes-no" option. But I think that's all irrrelevant to this document, which is supposed to be about RPZ as it is instead of what it should have been. > - Section 4.1.1 > > The BIND 9 RPZ implementation rejects a prefix length of 0: > > if (prefix_num < 1U || prefix_num > 128U) { > badname(log_level, src_name, > "; invalid prefix length of ", prefix_str); > return (ISC_R_FAILURE); > } > > I don't know the rationale behind it, That restriction intended to make the function that maps IP addresses to RPZ triggers well defined and so the RPZ rewriting function well defined in the mathematical sense. Having two different triggers and potentially differing rewrite rules that refer to the same IP address could make particular instantiations of the RPZ rewriting function not well defined. I also don't know which IPv4 addresses an RPZ trigger of 0.0.0.0.0.rpz-ip should match. Should it match all IPv4 addresses or no IPv4 addresses? If they are needed, could you suggest words to that effect for the document? > but since /0 is not a > syntactically invalid prefix Is there a normative reference that declares /0 valid or invalid? It sounds like a nice thing to dump into the references section. > it's probably better to describe it > explicitly, The second sentence of 4.1.1. in the current draft is The prefix length ("prefix") is a decimal integer from 1 to 32. Is not sufficiently explicit? > - Section 4.1.1 > > As in [RFC5952], in order to avoid confusion with octal notation, > leading zeroes MUST be suppressed. > > This reads awkward or confusing to me. First, it could read as if > RFC5942 suppresses leading zeros to avoid confusion with octal > notation, but as far as I understand it that's not the reason (it's > basically just to provide unique and consistent representations.) > Second, unlike the case of IPv4 addresses, not all hex block can > this confusion; If the word "avoid" is missing there, as in "not all hex [blocks] can [avoid] this confusion", then I half disagree. The only hextet with a leading 0 that cannot be suppressed is the zero hextet. > if avoiding the confusion were the reason, there > should be no reason for banning '0db8' instead of 'db8'. "Unique and consistent representations" must be unique, and so there can be only one. If both 0db8 and db8 were allowed, then they could have differing rules and so the RPZ rewriting function would not be well defined. > So I > suggest: > > As in [RFC5952], in order to make the representation unique, > leading zeroes MUST be suppressed. I think there were objections to exactly those words in a previous version of the draft. Would you accept "unnecesary leading zeroes MUST be suppressed"? > - Section 4.2 > > To control the policy for both a name and its > subdomains, two policy RRsets must be used, one for the domain itself > and another for a wildcard subdomain. > > IMO this part of the spec is one of the reasons why abusing zone > data to represent filtering policies is not good. ... I agree that requiring two rules in that case instead of some other scheme involving example.com rewrite only example.com *.example.com rewrite only children of example.com rewrite both example.com and children of example.com would save bandwidth. But when I wrote that first RPZ implementation, I could not see a sufficiently quick way to make BIND9 do the right things for any obvious kinds of trigger. Please recall that that was before we came up with rpz-ip and other subdomains. I also agree that using the DNS to define and distribute DNS policy data is a kludge. But to the point, I don't understand your suggested change to the draft. This draft is intended to describe RPZ as it is and not what it should have been in hindsight or what it might become in the future. > - Section 4.4 > > Recall also that the target of a CNAME is not added to the > response if the QTYPE is ANY > > Is this guaranteed by a protocol standard? Or is this a requirement > to RPZ implementations? ... It's nothing to do with RPZ but what DNS implementations do. I assume that one or more of the documents that came after RFC 1035 mandate that behavior. If I knew of a normative reference, I'd add it. > - Section 5.2 > > Matches on rules in an RPZ specified earlier in the ordered list of > RPZs take precedence over matches on rules in an RPZ specified later. > > I may miss something, but the concept of "ordered list of RPZs" > isn't explicitly described elsewhere (at least earlier) in the > draft. I think it should be explicitly documented as part of > assumptions. There are these words in the draft: ] 6. Application of the Policy ] ] To enable the use of RPZs, the recursive name server's control plane ] is connected to the DNS RPZ data plane by supplying an ordered list ] of RPZs in the name server's configuration. I think the draft should avoid words about individual resolver configuration languages, and so the draft does not mention the BIND9 implementation of those words. > - Section 5.6 > > When comparing two Response IP Address matches or two NSIP matches on > rules within a single RPZ, choose the match whose rule trigger has > the longest "internal prefix length". [...] > For an IPv4 address trigger, the > internal prefix length is the numeric value of its first label plus > 96 (that is, 128-32). > > Does this apply when a response to type ANY query contains both AAAA > and A RRsets, i.e., choose the IPv6 or IPv4 address that has the > longest internal prefix length among all AAAA and A RRsets? If so, > (I think it's better to clarify that explicitly and) it means IPv4 > prefixes would tend to be preferred even if they are effectively > very short. I could blather about the difficulties of relating IPv4 prefixes to IPv6. I won't defend the preference for IPv4 in the current RPZ. If pressed, I might suggest a possibly hard to implement scheme such as giving one IPv4 prefix bit the same weight as four IPv6 prefix bits. But again, whether the current RPZ preference for IPv4 is ideal or even just reasonable is irrelevant to this document. It is intended to describe RPZ as it is and not what it should have been or might become. I think the current version of the draft makes that aspect of the current notion of RPZ clear. If it is not clear, do you have an explicit suggestion? > - Section 6 > > RPZ rules do not apply to synthetic data generated by using RPZ > rules. For example, if RPZ supplies a CNAME pointing to a walled > garden, RPZ policies will not be used while following that CNAME. > > Consider the following policy record: > > a.example.com CNAME garden.example.org. > > and assume following the CNAME target results in the chain as follows: > garden.example.org. CNAME a.example.com. > a.example.com. AAAA 2001:db8::1 > > Then should this server includes these two RRs as well as the first > CNAME in the answer? If so, it would result in "CNAME and other > type for the same name" and violate the protocol standard > (forgetting RPZ violates the standard anyway). Is it okay? I'm sorry, but I don't understand that question or questions. But please note again that whether whatever the current RPZ protocol does is okay is irrelevant to this document. > - Section 6.1 > > For each DNS RPZ configured for use by a recursive name server, it > SHOULD be possible to specify a single, OPTIONAL overriding policy > action to be used for all policy triggers found in that RPZ. > > I'd suggest explaining what "override" means in a bit more detail. > I know what it means from the actual behavior of existing > implementations, but I'm not sure if this is clear enough just from > this text. I don't know to make it more clear. Could you suggest some words? > Also, I'm not really sure for what this overriding is useful except > DISABLED (for which the draft explains its possible purpose). Some > more background motivation would be helpful for readers and for > implementers who will end up supporting these SHOULDs. This overriding is required for most 'walled garden' RPZ schemes. A policy zone vendor cannot provide rules that rewrite to the domain names all of its customers' walled gardens, because each customer is likely to want to use its own local walled garden. Moreover, in practice RPZ zone vendors use "CNAME ." or NXDOMAIN rules, perhaps because those require the least storage on authoritative policy zone servers and the least bandwidth for AXFR/IXFR zone transfers. If you think that should be stated explicitly, could you suggest some words? > - Section 9 (or regarding NSDNAME and NSIP in general) > > RPZ checks can add significant processing and network costs to the > processing of recursive DNS requests. This is particularly true of > rules with NSDNAME and NSIP triggers. [...] > > I wonder how widely these triggers are used. My personal > experiences are of course very limited, but none of the large scale > RPZ deployments I know of uses these triggers. On the other hand > the implementation of these would be quite complicated and error > prone in addition to the performance overhead described in the draft > text, and, in fact, the support for these triggers certainly makes > the BIND 9's RPZ implementation even more unreadable. So, depending > on the actual deployment status, we might want to make these > triggers optional or even excluded from a spec aiming to be a base > of broader interoperability. I think NSDNAME and NSIP triggers should be used more than they are. If you don't trust the A and AAAA RRs for example.com, then you shouldn't trust any domains hosted or controlled by example.com However, whether NSDNAME and NSIP are useful, unwise, or hard to implement seems irrelevant to this document. They are present in more than one RPZ implementation and so present in the RPZ protocol as it exists today. Vernon Schryver vjs@rhyolite.com