From hallam@gmail.com Fri Feb 1 08:30:30 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DC921E8096 for ; Fri, 1 Feb 2013 08:30:30 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj1BYKg5JA1e for ; Fri, 1 Feb 2013 08:30:28 -0800 (PST) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id F12F621E8030 for ; Fri, 1 Feb 2013 08:30:27 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so3185685wey.14 for ; Fri, 01 Feb 2013 08:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=D3xC2hO4gS2B5SfKSOANCiNq8aAXa+gyeUet6R5rJ30=; b=e291CMGy/Pr2b+oaCXVSGpg77gztdK4b/aZY0UjZ6Mw9SszebvIvrMqP6NGj3/6aeW klMYVxBFrjuV5dXkVD7xQQmbLaSZJPl7MhF7UY+q4y5i1tM4o0jrc3EyTinothjOHJE6 iKG9uqh9FaxhjR91nwBntaSNqkvvtOUrAgq0Ppa3pCLq4IRFiX5PtV8oeJUsqTK9dwBd jse1yhT1LB3QvRjdsH0s2sMJ8Q5b6JjFdb1TSec8LVrp+HBwNwOBC8zWo4Q7YhcMKYzH HK2o8VOcI5ajP/eZn1aNCghc1HCydK0WOdWatVXqZ/ZVe7pjWkjyB1vp3ESLhmdifgly TxLA== MIME-Version: 1.0 X-Received: by 10.194.156.170 with SMTP id wf10mr4717504wjb.25.1359736227065; Fri, 01 Feb 2013 08:30:27 -0800 (PST) Received: by 10.194.16.74 with HTTP; Fri, 1 Feb 2013 08:30:26 -0800 (PST) Date: Fri, 1 Feb 2013 11:30:26 -0500 Message-ID: From: Phillip Hallam-Baker To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=089e012280fccd6f1704d4ac425d Subject: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:30:30 -0000 --089e012280fccd6f1704d4ac425d Content-Type: text/plain; charset=ISO-8859-1 Over the years several people have proposed a record that would be used to specify a public suffix. For example: .com PUBLIC .co.uk PUBLIC .ac.uk PUBLIC .net PUBLIC The idea here being to provide a mechanism in the DNS to advertise the fact that a zone is considered to be a public delegation point and that features such as Cookies, JavaScript, CA cert issue, etc. can then avoid security issues that arise from the assumption that the domains A.X.Y and B.X.Y or X.Y are in the same 'zone of trust'. DNS deployment constraints mean that it is not possible for applications to use this information directly as there is no guarantee that the application will have access to the necessary records. So each application would still need to maintain a public suffix list but it would be a public suffix list that can be maintained using an automatic script run as part of the build process rather than a list that is maintained by hand and in the most error prone way imaginable. I do not want to get into a discussion of the design decisions made by Netscape without any consultation fifteen years ago at this point. The public suffix list was a design botch then and it is a design botch now. It is also legacy that we cannot change. The choice therefore is whether we live with the current situation where there are multiple unofficial public suffix lists or move to a scheme which at least permits the information to be published by the authoritative source for the domain in question. The forcing function that I believe is going to make the current situation untenable is the introduction of new TLDs by ICANN. I do not believe that the current system of unofficial public prefix lists with multiple maintainers is capable of reacting to change. It only works at all because the changes to the public prefixes have been gradual and most have been zones that have a two level hierarchy going to a flat TLD scheme. Has anyone written a draft to propose such a record or is interested in helping to make such a proposal? Since the objective is to expose a single bit of information per domain, the design space is not large. I see only two real design options. Option 1: All zones are considered private by default unless the zone publishes PUBLIC record in that zone which makes it a public delegation point. Con: This requires all TLDs to comply before the registry is effective. Option 2: The PUBLIC record takes an integer parameter as follows: PUBLIC 0 : Domain is NOT a public suffix PUBLIC 1 : Domain in which it is published is public suffix, default for subdomains is not public suffix PUBLIC 2 : Domain in which it is published is public suffix, default for subdomains is public sufix A domain is a public suffix if and only if * There is a PUBLIC RR with the parameter 1 or 2 published in the domain OR * There is no PUBLIC RR published in the domain AND (it is a TLD OR the parent domain has a PUBLIC RR with a parameter of 2) In the second option it would be sufficient for the small number of second level public delegation points to publish the appropriate records and for ICANN to require new TLDs to take the appropriate action if they are supporting public delegation points at levels lower than the TLD. The proposal could even be tweaked further to explicitly grandfather existing domains, though the public suffix list is actually rather large. Consider the Mozilla version: http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 -- Website: http://hallambaker.com/ --089e012280fccd6f1704d4ac425d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Over the years several people have proposed a record that would be used to = specify a public suffix. For example:

=A0 =A0.com =A0 = =A0PUBLIC
=A0 =A0.co.uk =A0PUBLIC
=A0 =A0.ac.uk =A0PUBLIC
=A0 =A0.net =A0 =A0 PUBLIC

The idea here bein= g to provide a mechanism in the DNS to advertise the fact that a zone is co= nsidered to be a public delegation point and that features such as Cookies,= JavaScript, CA cert issue, etc. can then avoid security issues that arise = from the assumption that the domains A.X.Y and B.X.Y or X.Y are in the same= 'zone of trust'.

DNS deployment constraints mean that it is not possible= for applications to use this information directly as there is no guarantee= that the application will have access to the necessary records. So each ap= plication would still need to maintain a public suffix list but it would be= a public suffix list that can be maintained using an automatic script run = as part of the build process rather than a list that is maintained by hand = and in the most error prone way imaginable.


I do not want to get into a discussion o= f the design decisions made by Netscape without any consultation fifteen ye= ars ago at this point. The public suffix list was a design botch then and i= t is a design botch now. It is also legacy that we cannot change. The choic= e therefore is whether we live with the current situation where there are m= ultiple unofficial public suffix lists or move to a scheme which at least p= ermits the information to be published by the authoritative source for the = domain in question.

The forcing function that I believe is going to make th= e current situation untenable is the introduction of new TLDs by ICANN. I d= o not believe that the current system of unofficial public prefix lists wit= h multiple maintainers is capable of reacting to change. It only works at a= ll because the changes to the public prefixes have been gradual and most ha= ve been zones that have a two level hierarchy going to a flat TLD scheme.= =A0

Has anyone written a draft to propose such a record or = is interested in helping to make such a proposal?

=
Since the objective is to expose a single bit of information= per domain, the design space is not large. I see only two real design opti= ons.

Option 1:

All zones are consid= ered private by default unless the zone publishes PUBLIC record in that zon= e which makes it a public delegation point.

Con: T= his requires all TLDs to comply before the registry is effective.


Option 2:

The P= UBLIC record takes an integer parameter as follows:

PUBLIC 0 : Domain is NOT a public suffix
PUBLIC 1 : Domain in w= hich it is published is public suffix, default for subdomains is not public= suffix
PUBLIC 2 : Domain in which it is published is public suffix, default f= or subdomains is public sufix

A domain is a public= suffix if and only if

* There is a PUBLIC RR with= the parameter 1 or 2 published in the domain OR
* There is no PUBLIC RR published in the domain AND (it is a TLD OR th= e parent domain has a PUBLIC RR with a parameter of 2)

=
In the second option it would be sufficient for the small number of se= cond level public delegation points to publish the appropriate records and = for ICANN to require new TLDs to take the appropriate action if they are su= pporting public delegation points at levels lower than the TLD.


The proposal could even be tweaked furth= er to explicitly grandfather existing domains, though the public suffix lis= t is actually rather large. Consider the Mozilla version:

--089e012280fccd6f1704d4ac425d-- From paul.hoffman@vpnc.org Fri Feb 1 08:58:03 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1992721E8095 for ; Fri, 1 Feb 2013 08:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpNRC2o1YE8X for ; Fri, 1 Feb 2013 08:58:02 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B3BA121E8030 for ; Fri, 1 Feb 2013 08:58:02 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r11Gw1J7051799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Feb 2013 09:58:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 1 Feb 2013 08:58:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: DNSEXT Working Group X-Mailer: Apple Mail (2.1499) Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:58:03 -0000 On Feb 1, 2013, at 8:30 AM, Phillip Hallam-Baker = wrote: > Has anyone written a draft to propose such a record or is interested = in helping to make such a proposal? draft-sullivan-domain-origin-assert deals with the core issue, and does = so in healthier way than simply reproducing the Mozilla list (which is = often wrong due to insufficient input and validation). I still would like to see draft-sullivan-domain-origin-assert adopted as = a standard. --Paul Hoffman= From matthijs@nlnetlabs.nl Fri Feb 1 09:26:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6619E21E80BD for ; Fri, 1 Feb 2013 09:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeeaUqK7yJkt for ; Fri, 1 Feb 2013 09:26:23 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5015A21E8041 for ; Fri, 1 Feb 2013 09:26:22 -0800 (PST) Received: from [IPv6:2001:981:19be:1:ddbe:bfea:8adc:9a4a] ([IPv6:2001:981:19be:1:ddbe:bfea:8adc:9a4a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r11HQJOP021589 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 18:26:20 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.4 open.nlnetlabs.nl r11HQJOP021589 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1359739581; bh=gyiGSAhRVmnMm8ktqbXrPT2W6Pw7++Qu2kKSojOGNO8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=hBpm8MYBN5A0SXz9Vzv90z0gLwctTEZLoD7EvJA4MMUBX4vjtqfreqCc4iqKuJccN 7HCK6FI52K6mYLqBu0OL9gVLBIKAa7Ca5S89VMgUNVG9XwQuF+MqS94HA5H4vO5VIc 6SDUIgSFCFAMyFxtjT8R0JwhhPdihttr4hLvp1oE= Message-ID: <510BFABB.3030100@nlnetlabs.nl> Date: Fri, 01 Feb 2013 18:26:19 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 01 Feb 2013 18:26:20 +0100 (CET) Cc: dnsext@ietf.org Subject: Re: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:26:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You are right: The errata fixes only the case "No Data Responses, QTYPE is not DS", but not for the case "Wildcard No Data Responses". On 02/01/2013 05:55 AM, JINMEI Tatuya / 神明達哉 wrote: > I have a question related to the recent errata for RFC5155 on empty > non terminal: > http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441 > > What if the empty non terminal is a wildcard? For example, > > example. ;; zone origin, has SOA, NS, matching NSEC3 etc ;; > x.example. ;; empty, covered by opt-out NSEC3 ;; *.x.example. ;; > empty and wildcard, covered by opt-out NSEC3 child.*.x.example. IN > NS ns.example.com. ;; insecure, no DS, opt-out > > and query is y.x.example./A. What should be returned in this > case? Following the same logic as errata #3441, the closest provable encloser proof, with the NSEC3 covering the next closer having the Opt-Out flag set to one. > > Section 7.2.5 of RFC5155 states: > > If there is a wildcard match for QNAME, but QTYPE is not present > at that name, the response MUST include a closest encloser proof > for QNAME and MUST include the NSEC3 RR that matches the wildcard. > This combination proves both that QNAME itself does not exist and > that a wildcard that matches QNAME does exist. Note that the > closest encloser to QNAME MUST be the immediate ancestor of the > wildcard RR (if this is not the case, then something has gone > wrong). > > In this case, the closest encloser proof is NSEC3 that matches > example. and NSEC3 that covers x.example (that would have > Opt-Out). But there's no "NSEC3 RR that matches the wildcard". > Also, the closest (provable) encloser to QNAME (= example.) is not > the immediate ancestor of the wildcard (RR), which is x.example. > > Is this case included in the discussion that led to the errata? I > re-read the dnsext archive but couldn't be sure (as far as I can > see the wildcard-related discussions at that time were about > different issues than this one). Or is this case excluded by some > other rules? I think Section 7.2.5 and Section 8.7 require a similar errata. Best regards, Matthijs > > --- JINMEI, Tatuya Internet Systems Consortium, Inc. > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRC/q4AAoJEA8yVCPsQCW54MMH+wW89591hjbnPA1ozt+RhfB9 aqW37CHZ/E8AGOObmGStXYrt2X/AEpmvuDvS7yXnz3ELx5DeIuG6Y1AylXAJU7tk vYy/ya50JWiVrX8qO91yOmOSsWE8yDO1s7R4NwvEQ9WwUiaUyqmXmC9Wnj4rPVX2 C1t9CHK3MJpTHJ0DLVsvPZHXDkyUJRCyTL1/QK1EYnzHyS0/auJBYpFISwj2NMpr hZVudexFKE3jGic0vF50TU4C4N7uCej6PYvQiAT6OOBh3MCdYkYQZRiBxL0E8AXZ gUt0Ryflz/695xiwl+QJVmzxNLvO+LNzFkQpReTUO755u7XsZAFJsp+FYC66W1U= =eZfu -----END PGP SIGNATURE----- From hallam@gmail.com Fri Feb 1 09:32:27 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6FD21F868F for ; Fri, 1 Feb 2013 09:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gmN2H13Tk8d for ; Fri, 1 Feb 2013 09:32:26 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5470921E80C9 for ; Fri, 1 Feb 2013 09:32:13 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so3011608wge.34 for ; Fri, 01 Feb 2013 09:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lY1FHdqcAsQN2uYv63bc4wTo3TrJUUE5aIr6RpZJQRI=; b=Ip/kquSSAmTXeHrR2ClqCnndENfhD3J0kn7L3TFWp5QwA+tmW5W1bN1jLgNpasjQvn ZJ0LBhN2xT8DybRYS0Vh5R3btEDZHNVB8b+2/f5ELot2ojVi9S06lfSuRPchAtOj9AKO 1F+lYMMmvEivr0huhxO6MFkWBl+PqAwUcLv4e+CeWYmG3xiY++GHB+fmSCm0t31M9sD3 CMVuObq7ClBLF3Jb4cjPlaGbP9x1LfI0JVUP/84b7ZHPJlGaNcbylryWgBP3rEextQcV 0NI2dKBwgrSdp3LUHtOxhNmXTtCVuqHX64LukhgyPsi1TDuMxx65Xg8ol6v575FLdw/t oyNw== MIME-Version: 1.0 X-Received: by 10.180.78.34 with SMTP id y2mr4405435wiw.3.1359739932494; Fri, 01 Feb 2013 09:32:12 -0800 (PST) Received: by 10.194.16.74 with HTTP; Fri, 1 Feb 2013 09:32:12 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 12:32:12 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d043c7ecca9cc9a04d4ad1f96 Cc: DNSEXT Working Group Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:32:27 -0000 --f46d043c7ecca9cc9a04d4ad1f96 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 11:58 AM, Paul Hoffman wrote: > On Feb 1, 2013, at 8:30 AM, Phillip Hallam-Baker wrote: > > > Has anyone written a draft to propose such a record or is interested in > helping to make such a proposal? > > draft-sullivan-domain-origin-assert deals with the core issue, and does so > in healthier way than simply reproducing the Mozilla list (which is often > wrong due to insufficient input and validation). > Well it is not just a question of 'the Mozilla list' there are multiple lists in use maintained separately :( The idea would be to migrate away from that position and do so by pushing the responsibility for maintaining these lists onto ICANN and the operators of large public spaces like blogspot.com > > I still would like to see draft-sullivan-domain-origin-assert adopted as a > standard. > Andrew's proposal is essentially the opposite of mine. Instead of assertions of the form 'this is a gap in the trust model', Andrew proposes that the default is disconnected and trust is only established if there is an explicit link. That is definitely the right way to do this particular feature for JavaScript if starting from scratch. (OK no the right way is not to do it at all but..) But I don't see a viable transition strategy from where we are to where we want to be. Happy to be proved wrong here... -- Website: http://hallambaker.com/ --f46d043c7ecca9cc9a04d4ad1f96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 1, 2013 at 11:58 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
On Feb 1, 2013, at 8:30 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> Has anyone written a draft to propose such a record or is interested i= n helping to make such a proposal?

draft-sullivan-domain-origin-assert deals with the core issue, and do= es so in healthier way than simply reproducing the Mozilla list (which is o= ften wrong due to insufficient input and validation).

Well it is not just a question of 'the Mozilla list= ' there are multiple lists in use maintained separately :(
The idea would be to migrate away from that position and do so= by pushing the responsibility for maintaining these lists onto ICANN and t= he operators of large public spaces like bl= ogspot.com
=A0

I still would like to see draft-sullivan-domain-origin-assert adopted as a = standard.

Andrew's proposal is esse= ntially the opposite of mine. Instead of assertions of the form 'this i= s a gap in the trust model', Andrew proposes that the default is discon= nected and trust is only established if there is an explicit link.

That is definitely the right way to do this particular = feature for JavaScript if starting from scratch. (OK no the right way is no= t to do it at all but..) But I don't see a viable transition strategy f= rom where we are to where we want to be.

Happy to be proved wrong here...

--
Website: http://halla= mbaker.com/
--f46d043c7ecca9cc9a04d4ad1f96-- From ajs@anvilwalrusden.com Fri Feb 1 10:01:52 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2121E8047 for ; Fri, 1 Feb 2013 10:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZbd8iaCqH4K for ; Fri, 1 Feb 2013 10:01:52 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F197D21E8041 for ; Fri, 1 Feb 2013 10:01:51 -0800 (PST) Received: from mx1.yitter.info (nat-06-mht.dyndns.com [216.146.45.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 50CB28A031 for ; Fri, 1 Feb 2013 18:01:50 +0000 (UTC) Date: Fri, 1 Feb 2013 13:01:48 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130201180147.GW24535@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 18:01:52 -0000 On Fri, Feb 01, 2013 at 11:30:26AM -0500, Phillip Hallam-Baker wrote: > > Has anyone written a draft to propose such a record or is interested in > helping to make such a proposal? Yes, and in fact you have commented on it. http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Feb 1 23:02:29 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CB121F8B3B for ; Fri, 1 Feb 2013 23:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XNVg2lMFAiI for ; Fri, 1 Feb 2013 23:02:28 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BC88121F8B33 for ; Fri, 1 Feb 2013 23:02:28 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DC97A8A031 for ; Sat, 2 Feb 2013 07:02:27 +0000 (UTC) Date: Sat, 2 Feb 2013 02:02:26 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20130202070225.GB25364@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 07:02:29 -0000 In case it wasn't clear, no hat. On Fri, Feb 01, 2013 at 12:32:12PM -0500, Phillip Hallam-Baker wrote: > Andrew's proposal is essentially the opposite of mine. Instead of > assertions of the form 'this is a gap in the trust model', Andrew proposes > that the default is disconnected and trust is only established if there is > an explicit link. > > That is definitely the right way to do this particular feature for > JavaScript if starting from scratch. (OK no the right way is not to do it > at all but..) But I don't see a viable transition strategy from where we > are to where we want to be. I don't see why. First, it seems to me that it is the only reasonable security model at all. Moreover, the mechanism I propose fully subsumes your proposal, because ICANN and others could make an equivalent to the PUBLIC proposal you offer, just by publishing a record that says nobody lives in the same administrative realm. (This is the SOPA with root-target record.) Indeed, the reason I had a default-don't-trust _plus_ a mechanism to state don't-trust explicitly was exactly so that we could start out by making such don't-trust statements; that way, you could "fail hard" on the root-target statements and still play games guessing with domain names, until the new mechanism can be adopted widely. Anyway, that's the intention, so if it's not clear discussion is welcome. I was hoping to have that discussion on apps-discuss, mostly because that's where the consumers of this data are, and previous attempts to work out this stuff in the DNS community (and then present it to consumers as finished) have failed. Maybe we could move this there? Also, I'd be delighted to have a tag-team discussion of these two competing proposals in Orlando, if you think it's worth pursuing. A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Sat Feb 2 09:06:34 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53721F8545 for ; Sat, 2 Feb 2013 09:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BGLjEmKCNGS for ; Sat, 2 Feb 2013 09:06:33 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D083121F8549 for ; Sat, 2 Feb 2013 09:06:33 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r12H6C91090478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Feb 2013 10:06:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20130202070225.GB25364@mx1.yitter.info> Date: Sat, 2 Feb 2013 09:06:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A686B03-4D2B-4002-A660-8334E29CC960@vpnc.org> References: <20130202070225.GB25364@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: dnsext@ietf.org Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 17:06:34 -0000 +1 to this being a discussion for AppsArea (the consumer of the = proposals). It might be worth asking Pete and Barry for some time to = introduce the two different approaches to the area in advance of the = list discussion. --Paul Hoffman= From dougb@dougbarton.us Sat Feb 2 17:07:19 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2B921F8419 for ; Sat, 2 Feb 2013 17:07:19 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu+GiHOa9bwO for ; Sat, 2 Feb 2013 17:07:19 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3557721F8319 for ; Sat, 2 Feb 2013 17:07:19 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:5d4:899b:954b:aada] (unknown [IPv6:2001:470:d:5e7:5d4:899b:954b:aada]) by dougbarton.us (Postfix) with ESMTPSA id E084822B2B; Sun, 3 Feb 2013 01:07:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1359853638; bh=OUKSfo1vtOoUWHwA67Y+h0nyGLgKR0EmQGCyfDpFqMs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=K5s+VRv82KZrhr6q06wlqumS2tXOUkn8Quexpkk5CfrLQcwpEU8gWdM7Wi+XObJyT WqYArqjMET2Oi0UCIKQD2hYwQInecdL0WIVHzgB/6ntVFWNZWoZcHdiF10AQPCb3iQ K+a/Lf63qr2Kj2j3ukdRRvJwYBr2NKpidWwLsdKE= Message-ID: <510DB845.2090705@dougbarton.us> Date: Sat, 02 Feb 2013 17:07:17 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <50FA1596.6050803@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 01:07:19 -0000 On 01/22/2013 06:21 AM, Phillip Hallam-Baker wrote: > OK so looks like the optional policy string is not a good idea. At least > as far as the normal form goes. > > > > On Fri, Jan 18, 2013 at 10:40 PM, Doug Barton > wrote: > > On 01/18/2013 09:35 AM, Phillip Hallam-Baker wrote: > > * SRV (does not work well for Web services) > > > Can you elaborate, or provide a reference? > > Doug > > > The problem with SRV and Web services is that a typical Web Server > deployment supports multiple Web Services, some of which are only going > to be called maybe five times a day, if that. So the Web Services > actually make use of the stem part of the URI to identify the location > on the Web Server. How would that change with the use of an SRV record? > So to use SRV to announce a Web Service you need some way to specify the > location on the Web Server. Why? > One approach is to specify a .well-known > location for the service but that is rather less flexible than many > deployments will accept and it stops a server having two different > versions of the same protocol running in parallel - something you are > very likely to want to do if you are witching between protocol versions > or implementation versions. Sorry, I don't parse the above paragraph at all. In my (perhaps naive) view, the purpose of the SRV record is to allow the end user system to find the right address and port to connect to for the specified service. The things you're describing seem to me to be the business of the web server once the end user is connected. If I have missed something here, please clue me in. Doug From fw@deneb.enyo.de Tue Feb 5 06:15:30 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E0B21F881E for ; Tue, 5 Feb 2013 06:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJcCjACE5B04 for ; Tue, 5 Feb 2013 06:15:29 -0800 (PST) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id A7E3F21F881C for ; Tue, 5 Feb 2013 06:15:29 -0800 (PST) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1U2jJ1-0001Ws-4G; Tue, 05 Feb 2013 15:15:27 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1U2jJ0-0006AW-Sf; Tue, 05 Feb 2013 15:15:26 +0100 From: Florian Weimer To: Phillip Hallam-Baker References: Date: Tue, 05 Feb 2013 15:15:26 +0100 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 1 Feb 2013 11:30:26 -0500") Message-ID: <878v72hmo1.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dnsext@ietf.org Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:15:30 -0000 * Phillip Hallam-Baker: > Over the years several people have proposed a record that would be used to > specify a public suffix. For example: > > .com PUBLIC > .co.uk PUBLIC > .ac.uk PUBLIC > .net PUBLIC ISC recommends a configuration for the BIND resolver which suppresses such RRs in the COM and NET zones (and others), so it's not clear to me if such records would make it to clients in practice. From cet1@hermes.cam.ac.uk Tue Feb 5 08:39:02 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B116421F8915 for ; Tue, 5 Feb 2013 08:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wncTgPKf5ebG for ; Tue, 5 Feb 2013 08:39:01 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id B85CA21F8911 for ; Tue, 5 Feb 2013 08:39:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47271) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1U2lXv-0006Od-q9 (Exim 4.72) (return-path ); Tue, 05 Feb 2013 16:38:59 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1U2lXv-0000fF-4L (Exim 4.72) (return-path ); Tue, 05 Feb 2013 16:38:59 +0000 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 05 Feb 2013 16:38:59 +0000 Date: 05 Feb 2013 16:38:59 +0000 From: Chris Thompson To: Florian Weimer Message-ID: In-Reply-To: <878v72hmo1.fsf@mid.deneb.enyo.de> References: <878v72hmo1.fsf@mid.deneb.enyo.de> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsext@ietf.org Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:39:02 -0000 On Feb 5 2013, Florian Weimer wrote: >* Phillip Hallam-Baker: > >> Over the years several people have proposed a record that would be used to >> specify a public suffix. For example: >> >> .com PUBLIC >> .co.uk PUBLIC >> .ac.uk PUBLIC >> .net PUBLIC > >ISC recommends a configuration for the BIND resolver which suppresses >such RRs in the COM and NET zones (and others), so it's not clear to >me if such records would make it to clients in practice. This refers (I assume) to the "delegation-only" and "root-delegation-only" options in BIND. None of that is turned on by default, so "recommends" may be a bit of an overstatement. The BIND ARM is pretty cautious about them. You could probably get ISC to exclude a new record type from being converted to NXDOMAIN by this facility, as (for example) DS records already are. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From ed.lewis@neustar.biz Tue Feb 5 12:18:30 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83C821F885B for ; Tue, 5 Feb 2013 12:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPUPF2QqSdNK for ; Tue, 5 Feb 2013 12:18:29 -0800 (PST) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8B21F846B for ; Tue, 5 Feb 2013 12:18:29 -0800 (PST) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130205201829.GOQD7113.eastrmfepo102.cox.net@eastrmimpo209> for ; Tue, 5 Feb 2013 15:18:29 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id wkJT1k00r3cuADQ01kJUyE; Tue, 05 Feb 2013 15:18:28 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.51116914.0163,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=d613OGfE c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=rUiQnFgtT6sA:10 a=hGBaWAWWAAAA:8 a=KDMechheWskA:10 a=BqEg4_3jAAAA:8 a=A1X0JdhQAAAA:8 a=48vgC7mUAAAA:8 a=Z0q1k5ZkA76D03vicSoA:9 a=QEXdDO2ut3YA:10 a=9k6G2--EmesA:10 a=mhd2NDuUijAA:10 a=lZB815dzVvQA:10 a=mpXYizHg--WqXZdu15UA:9 a=_W_S_7VecoQA:10 a=oRebSPDiU0Nh-XfX:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3512849B-81B9-4071-AC11-EAA8D85AB022" From: Edward Lewis In-Reply-To: Date: Tue, 5 Feb 2013 15:18:27 -0500 Message-Id: References: To: dnsextmailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:18:30 -0000 --Apple-Mail=_3512849B-81B9-4071-AC11-EAA8D85AB022 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > What if the empty non terminal is a wildcard? For example, > and query is y.x.example./A. What should be returned in this case? If I get the example right the only name in the zone that has a = corresponding NSEC3 record is the apex. So the response would have an = RCODE of NoError (meaning a name match happened) and the NSEC3 record = indicating that the rest of the zone is subject to opt-out. =46rom this = the validation should deduce that the name was hit, there was no data, = but there is no "security" for this because the source of synthesis is = an empty non-terminal. If there were records at the closest encloser, there would be an NSEC3 = there, if there were records at the source of synthesis there would be = an NSEC3 there (too). I'm not claiming that I like that, but it is how I read the intention of = the RFC+errata. (Personally I'd not drop the NSEC3's in signing, but = the horse has left the barn on that.) =20 I don't see a "problem." Or maybe I don't see the problem yet. Perhaps = the problem is in what the text says needs to be there? > Is this case included in the discussion that led to the errata? I Short answer no. But I don't see it as a special case. We know that wildcards and opt-out together will ruffle some feathers. = If I see a domain (using "domain" as the apex of a zone or a label down = in a zone that is the last point of NSEC3 in a descent towards a QNAME) = that declares it starts the beginning of an opt-out span, then any other = expected hash I am told is missing is an empty non-terminal with only NS = RRsets in sub-domains. In this case, with A NSEC3 A SOA NS ... - that tells me any other NSEC3 = I'm looking for "is not there." Therefore every thing in the zone is = subject to this RFC 5155 "special case." If there were any data records inside this, then we'd have NSEC3's as = needed - we know we don't have them though because of that first NSEC3. On Jan 31, 2013, at 23:55, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: > I have a question related to the recent errata for RFC5155 on > empty non terminal: > http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D3441 >=20 > What if the empty non terminal is a wildcard? For example, >=20 > example. ;; zone origin, has SOA, NS, matching NSEC3 etc > ;; x.example. ;; empty, covered by opt-out NSEC3 > ;; *.x.example. ;; empty and wildcard, covered by opt-out NSEC3 > child.*.x.example. IN NS ns.example.com. ;; insecure, no DS, opt-out >=20 > and query is y.x.example./A. What should be returned in this case? >=20 > Section 7.2.5 of RFC5155 states: >=20 > If there is a wildcard match for QNAME, but QTYPE is not present at > that name, the response MUST include a closest encloser proof for > QNAME and MUST include the NSEC3 RR that matches the wildcard. This > combination proves both that QNAME itself does not exist and that a > wildcard that matches QNAME does exist. Note that the closest > encloser to QNAME MUST be the immediate ancestor of the wildcard RR > (if this is not the case, then something has gone wrong). >=20 > In this case, the closest encloser proof is NSEC3 that matches > example. and NSEC3 that covers x.example (that would have Opt-Out). > But there's no "NSEC3 RR that matches the wildcard". Also, the > closest (provable) encloser to QNAME (=3D example.) is not the = immediate > ancestor of the wildcard (RR), which is x.example. >=20 > Is this case included in the discussion that led to the errata? I > re-read the dnsext archive but couldn't be sure (as far as I can see > the wildcard-related discussions at that time were about different > issues than this one). Or is this case excluded by some other rules? >=20 > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_3512849B-81B9-4071-AC11-EAA8D85AB022 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
What if the empty non terminal is = a wildcard?  For example,
and query is y.x.example./A.  What should be = returned in this case?

If I get the = example right the only name in the zone that has a corresponding NSEC3 = record is the apex.  So the response would have an RCODE of NoError = (meaning a name match happened) and the NSEC3 record indicating that the = rest of the zone is subject to opt-out.  =46rom this the validation = should deduce that the name was hit, there was no data, but there is no = "security" for this because the source of synthesis is an empty = non-terminal.

If there were records at the = closest encloser, there would be an NSEC3 there, if there were records = at the source of synthesis there would be an NSEC3 there = (too).

I'm not claiming that I like that, = but it is how I read the intention of the RFC+errata.  (Personally = I'd not drop the NSEC3's in signing, but the horse has left the barn on = that.)  

I don't see a "problem."  Or = maybe I don't see the problem yet.  Perhaps the problem is in what = the text says needs to be there?

Is this case included in the discussion that led to = the errata?  I

Short answer = no.  But I don't see it as a special = case.

We know that wildcards and opt-out = together will ruffle some feathers.  If I see a domain (using = "domain" as the apex of a zone or a label down in a zone that is the = last point of NSEC3 in a descent towards a QNAME) that declares it = starts the beginning of an opt-out span, then any other expected hash I = am told is missing is an empty non-terminal with only NS RRsets in = sub-domains.

In this case, with A NSEC3 A SOA = NS ... - that tells me any other NSEC3 I'm looking for "is not there." =  Therefore every thing in the zone is subject to this RFC 5155 = "special case."

If there were any data records = inside this, then we'd have NSEC3's as needed - we know we don't have = them though because of that first = NSEC3.

On Jan 31, 2013, at 23:55, JINMEI = Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote:

I = have a question related to the recent errata for RFC5155 on
empty non = terminal:
http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D3441=

What if the empty non terminal is a wildcard?  For = example,

example. ;; zone origin, has SOA, NS, matching NSEC3 = etc
;; x.example. ;; empty, covered by opt-out NSEC3
;; = *.x.example. ;; empty and wildcard, covered by opt-out = NSEC3
child.*.x.example. IN NS ns.example.com. ;; insecure, no DS, = opt-out

and query is y.x.example./A.  What should be = returned in this case?

Section 7.2.5 of RFC5155 states:

=   If there is a wildcard match for QNAME, but QTYPE is not = present at
  that name, the response MUST include a = closest encloser proof for
  QNAME and MUST include the = NSEC3 RR that matches the wildcard.  This
=   combination proves both that QNAME itself does not exist and = that a
  wildcard that matches QNAME does exist. =  Note that the closest
  encloser to QNAME MUST be = the immediate ancestor of the wildcard RR
  (if this is = not the case, then something has gone wrong).

In this case, the = closest encloser proof is NSEC3 that matches
example. and NSEC3 that = covers x.example (that would have Opt-Out).
But there's no "NSEC3 RR = that matches the wildcard".  Also, the
closest (provable) = encloser to QNAME (=3D example.) is not the immediate
ancestor of the = wildcard (RR), which is x.example.

Is this case included in the = discussion that led to the errata?  I
re-read the dnsext archive = but couldn't be sure (as far as I can see
the wildcard-related = discussions at that time were about different
issues than this one). =  Or is this case excluded by some other = rules?

---
JINMEI, Tatuya
Internet Systems Consortium, = Inc.
_______________________________________________
dnsext = mailing = list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Edward = Lewis             
NeuStar       = ;          =    You can leave a voice message at = +1-571-434-5468

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_3512849B-81B9-4071-AC11-EAA8D85AB022-- From matthijs@nlnetlabs.nl Tue Feb 5 14:20:08 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708AB21F8484 for ; Tue, 5 Feb 2013 14:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.55 X-Spam-Level: X-Spam-Status: No, score=-101.55 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_36=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuSPd0s7T0rq for ; Tue, 5 Feb 2013 14:20:07 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E05D921F847B for ; Tue, 5 Feb 2013 14:20:06 -0800 (PST) Received: from [IPv6:2001:981:19be:1:81c9:618c:300f:5908] ([IPv6:2001:981:19be:1:81c9:618c:300f:5908]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r15MK32D085643 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 23:20:04 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.4 open.nlnetlabs.nl r15MK32D085643 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1360102805; bh=k9zYUWwTP9gJwB0qEXdLoooD1jrmuwI9jdua18j4BN8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ArxGfRAXiQbLUswpjxFysbPXOCk5k8d9YEIzP5Hj9UnvPewFJbvmD5jETbpyfMR+M 1ffDHWMLfzZs2P1N8sDRn5RoLxL7edcF03KgcuEaoxuf3gcHtrbwL1Ke6cJhJmWHpi jRASc9OcHjy1Gw3+tbI6FiC35FpXaVGtmwaQjAaE= Message-ID: <51118591.7090008@nlnetlabs.nl> Date: Tue, 05 Feb 2013 23:20:01 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Edward Lewis References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 05 Feb 2013 23:20:04 +0100 (CET) Cc: dnsextmailing list Subject: Re: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 22:20:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/05/2013 09:18 PM, Edward Lewis wrote: >> What if the empty non terminal is a wildcard? For example, and >> query is y.x.example./A. What should be returned in this case? > > If I get the example right the only name in the zone that has a > corresponding NSEC3 record is the apex. So the response would have > an RCODE of NoError (meaning a name match happened) and the NSEC3 > record indicating that the rest of the zone is subject to opt-out. > From this the validation should deduce that the name was hit, there > was no data, but there is no "security" for this because the source > of synthesis is an empty non-terminal. > > If there were records at the closest encloser, there would be an > NSEC3 there, if there were records at the source of synthesis there > would be an NSEC3 there (too). > > I'm not claiming that I like that, but it is how I read the > intention of the RFC+errata. (Personally I'd not drop the NSEC3's > in signing, but the horse has left the barn on that.) > > I don't see a "problem." Or maybe I don't see the problem yet. > Perhaps the problem is in what the text says needs to be there? It is a different case, however very similar to the case described in Section 7.2.3 and 8.5 in RFC 5155. The case in Section 7.2.3 and 8.5 are about No Data Responses, QTYPE is not DS. The case that Jinmei is describing is the Wildcard No Data Responses, described in Section 7.2.5 and 8.7. These sections also lack the text that is in errata #3441. But the errata is solely about Section 7.2.3 and 8.5. > >> Is this case included in the discussion that led to the errata? >> I > > Short answer no. But I don't see it as a special case. Though it is described in RFC 5155 as a different case. However the problem logic is the similar: An NSEC3 is missing at the wildcard empty non-terminal because the empty non-terminal was derived from an insecure delegation. Best regards, Matthijs > > We know that wildcards and opt-out together will ruffle some > feathers. If I see a domain (using "domain" as the apex of a zone > or a label down in a zone that is the last point of NSEC3 in a > descent towards a QNAME) that declares it starts the beginning of > an opt-out span, then any other expected hash I am told is missing > is an empty non-terminal with only NS RRsets in sub-domains. > > In this case, with A NSEC3 A SOA NS ... - that tells me any other > NSEC3 I'm looking for "is not there." Therefore every thing in the > zone is subject to this RFC 5155 "special case." > > If there were any data records inside this, then we'd have NSEC3's > as needed - we know we don't have them though because of that first > NSEC3. > > On Jan 31, 2013, at 23:55, JINMEI Tatuya / 神明達哉 wrote: > >> I have a question related to the recent errata for RFC5155 on >> empty non terminal: >> http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441 >> >> What if the empty non terminal is a wildcard? For example, >> >> example. ;; zone origin, has SOA, NS, matching NSEC3 etc ;; >> x.example. ;; empty, covered by opt-out NSEC3 ;; *.x.example. ;; >> empty and wildcard, covered by opt-out NSEC3 child.*.x.example. >> IN NS ns.example.com. ;; insecure, no DS, opt-out >> >> and query is y.x.example./A. What should be returned in this >> case? >> >> Section 7.2.5 of RFC5155 states: >> >> If there is a wildcard match for QNAME, but QTYPE is not present >> at that name, the response MUST include a closest encloser proof >> for QNAME and MUST include the NSEC3 RR that matches the >> wildcard. This combination proves both that QNAME itself does >> not exist and that a wildcard that matches QNAME does exist. >> Note that the closest encloser to QNAME MUST be the immediate >> ancestor of the wildcard RR (if this is not the case, then >> something has gone wrong). >> >> In this case, the closest encloser proof is NSEC3 that matches >> example. and NSEC3 that covers x.example (that would have >> Opt-Out). But there's no "NSEC3 RR that matches the wildcard". >> Also, the closest (provable) encloser to QNAME (= example.) is >> not the immediate ancestor of the wildcard (RR), which is >> x.example. >> >> Is this case included in the discussion that led to the errata? >> I re-read the dnsext archive but couldn't be sure (as far as I >> can see the wildcard-related discussions at that time were about >> different issues than this one). Or is this case excluded by >> some other rules? >> >> --- JINMEI, Tatuya Internet Systems Consortium, Inc. >> _______________________________________________ dnsext mailing >> list dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > There are no answers - just tradeoffs, decisions, and responses. > > > > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJREYWNAAoJEA8yVCPsQCW5lZQH/1VepJUf0YV2hUdtmdNet5SO f0xj4gF8q1cKEqVL83P75Hk4gdiLINI+Xn8qlqadOydivpmFg8p5L2WWd4IoT8mr hLFjGR0FGJeMOcZSDR7R/63pXB5ySxi3jJ5l6cLtiM7MObLGlUSwW83v6a/RiKPB DrxNhUQBzJw9+yjpovlsJNUHKTNJ5KSHUnXUbj80VyejALij+PazDZo4paPDUqvY iiZ8sQUnB+HsUV5aYiAZdyxIFAIsEe3o8cJSSWM3z65qAusAwVbE5M0xRB9oM8F/ pCdqJHEKu2KRl97QDgA+0w/5aPvR9NrNGFJu+IC5N8zDCQ4dup3XPZz5ipmubtU= =zlKk -----END PGP SIGNATURE----- From marka@isc.org Tue Feb 5 15:23:41 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4670221F8939 for ; Tue, 5 Feb 2013 15:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh5x5MU9l+Yi for ; Tue, 5 Feb 2013 15:23:40 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5470321F8938 for ; Tue, 5 Feb 2013 15:23:40 -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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1C0CB5F98E9; Tue, 5 Feb 2013 23:23:25 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1360106618; bh=R0yFyIpIyodDdKJBQ32lBEv27Ud7aO3qi1wfZ39S/8Q=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=nlw2IvIbDIKETPcXHSs0u61/f79W45T4QHKbHhp7vWvn01YfCyH9HfsSrOY6OieIC AUgacaoPzYmqj9QsTVwAzOqPimdTbYON98NIL1dJgqhbYtFXpEygTTNRcNgNcktDPh gOnsWs+0GBlS+pqu4a5TypjYhT8pPKUBl1tvwNo0= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fd3c:4fc0:9596:e28a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 56857216C52; Tue, 5 Feb 2013 23:23:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8F1252F15C34; Wed, 6 Feb 2013 10:23:15 +1100 (EST) To: cet1@cam.ac.uk From: Mark Andrews References: <878v72hmo1.fsf@mid.deneb.enyo.de> In-reply-to: Your message of "05 Feb 2013 16:38:59 -0000." Date: Wed, 06 Feb 2013 10:23:15 +1100 Message-Id: <20130205232315.8F1252F15C34@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 23:23:41 -0000 In message , Chris Tho mpson writes: > On Feb 5 2013, Florian Weimer wrote: > > >* Phillip Hallam-Baker: > > > >> Over the years several people have proposed a record that would be used to > >> specify a public suffix. For example: > >> > >> .com PUBLIC > >> .co.uk PUBLIC > >> .ac.uk PUBLIC > >> .net PUBLIC > > > >ISC recommends a configuration for the BIND resolver which suppresses > >such RRs in the COM and NET zones (and others), so it's not clear to > >me if such records would make it to clients in practice. > > This refers (I assume) to the "delegation-only" and "root-delegation-only" > options in BIND. None of that is turned on by default, so "recommends" may > be a bit of an overstatement. The BIND ARM is pretty cautious about them. > > You could probably get ISC to exclude a new record type from being converted > to NXDOMAIN by this facility, as (for example) DS records already are. The delegation-only code does not care what is at the zone apex which deals with most zone for which people set delegation only. /* * Enforce delegations only zones like NET and COM. */ if (!ISFORWARDER(query->addrinfo) && dns_view_isdelegationonly(fctx->res->view, &fctx->domain) && !dns_name_equal(&fctx->domain, &fctx->name) && fix_mustbedelegationornxdomain(message, fctx)) { PUBLIC would also be added to the list of execptions for the case where the check gets past !dns_name_equal(&fctx->domain, &fctx->name) check. > -- > Chris Thompson University of Cambridge Computing Service, > Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, > Phone: +44 1223 334715 United Kingdom. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ed.lewis@neustar.biz Tue Feb 5 20:23:51 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA421F8900 for ; Tue, 5 Feb 2013 20:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-uJrL2-wbu9 for ; Tue, 5 Feb 2013 20:23:51 -0800 (PST) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ietfa.amsl.com (Postfix) with ESMTP id A6BFA21F8519 for ; Tue, 5 Feb 2013 20:23:50 -0800 (PST) Received: from eastrmimpo305 ([68.230.241.237]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130206042349.XWWU23841.eastrmfepo103.cox.net@eastrmimpo305> for ; Tue, 5 Feb 2013 23:23:49 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo305 with cox id wsPp1k0043cuADQ01sPphe; Tue, 05 Feb 2013 23:23:49 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.5111DAD5.00A5,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=e+KEuNV/ c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=rUiQnFgtT6sA:10 a=hGBaWAWWAAAA:8 a=KDMechheWskA:10 a=wozVhADmN87ZYblcYwUA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=reoQ2jxEgffhdhN__2wA:9 a=_W_S_7VecoQA:10 a=Rb45FpOCNEfWG4SU:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_16582CD2-C02D-4934-933C-711AE96B5EC1" From: Edward Lewis In-Reply-To: <51118591.7090008@nlnetlabs.nl> Date: Tue, 5 Feb 2013 23:23:49 -0500 Message-Id: <8BEB8CC1-625E-44F4-AB09-E71F1D15BBDC@neustar.biz> References: <51118591.7090008@nlnetlabs.nl> To: dnsextmailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 04:23:51 -0000 --Apple-Mail=_16582CD2-C02D-4934-933C-711AE96B5EC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 5, 2013, at 17:20, Matthijs Mekking wrote: > It is a different case, however very similar to the case described in > Section 7.2.3 and 8.5 in RFC 5155. The case in Section 7.2.3 and 8.5 > are about No Data Responses, QTYPE is not DS. The case that Jinmei is > describing is the Wildcard No Data Responses, described in Section > 7.2.5 and 8.7. These sections also lack the text that is in errata > #3441. But the errata is solely about Section 7.2.3 and 8.5. >=20 Ah, thanks, I got it now. I was staring too hard at what should be = returned and didn't pay attention to the section numbers. > Though it is described in RFC 5155 as a different case. However the > problem logic is the similar: An NSEC3 is missing at the wildcard > empty non-terminal because the empty non-terminal was derived from an > insecure delegation. Do you suggest another errata filing against the other sections (that = is, in addition to the previous errata) or do we need to scrap the = previous one and enter a whole new one? = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_16582CD2-C02D-4934-933C-711AE96B5EC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
It is = a different case, however very similar to the case described = in
Section 7.2.3 and 8.5 in RFC 5155. The case in Section 7.2.3 and = 8.5
are about No Data Responses, QTYPE is not DS. The case that = Jinmei is
describing is the Wildcard No Data Responses, described in = Section
7.2.5 and 8.7. These sections also lack the text that is in = errata
#3441. But the errata is solely about Section 7.2.3 and = 8.5.


Ah, thanks, I got it now. =  I was staring too hard at what should be returned and didn't pay = attention to the section numbers.

Though it is described in RFC 5155 as a different = case. However the
problem logic is the similar: An NSEC3 is missing = at the wildcard
empty non-terminal because the empty non-terminal was = derived from an
insecure = delegation.

Do you suggest another = errata filing against the other sections (that is, in addition to the = previous errata) or do we need to scrap the previous one and enter a = whole new one?

Edward = Lewis             
NeuStar       = ;          =    You can leave a voice message at = +1-571-434-5468

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_16582CD2-C02D-4934-933C-711AE96B5EC1-- From matthijs@nlnetlabs.nl Tue Feb 5 23:40:06 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9621F8971 for ; Tue, 5 Feb 2013 23:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.075 X-Spam-Level: X-Spam-Status: No, score=-102.075 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMvuOw0iHIKh for ; Tue, 5 Feb 2013 23:40:05 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D821F8958 for ; Tue, 5 Feb 2013 23:40:04 -0800 (PST) Received: from [IPv6:2001:981:19be:1:ad41:9dca:c7eb:6c55] ([IPv6:2001:981:19be:1:ad41:9dca:c7eb:6c55]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r167e1dZ014764 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 6 Feb 2013 08:40:01 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.4 open.nlnetlabs.nl r167e1dZ014764 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1360136403; bh=PZlz7r6sakygQtyfTO62DVcV+8+/2mMxCG3k8oWPgNM=; h=Date:From:To:Subject:References:In-Reply-To; b=U1u8FsAdtqkoE2EpWJ2WwLOpTLqwhGl8EndJTlCtVDjUC950V0+uKTiKO9AvGkao/ AP9k87s7vBvqMSFH4PrW3u7Fi5Jfo9M2OvUJiEdRFwg7nhyN6Y5NpX2UJnvIkduK4+ t2RaFZuoArdW9S2TK93RSP1hguwOa/7KvTywwz8E= Message-ID: <511208D0.7060505@nlnetlabs.nl> Date: Wed, 06 Feb 2013 08:40:00 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <51118591.7090008@nlnetlabs.nl> <8BEB8CC1-625E-44F4-AB09-E71F1D15BBDC@neustar.biz> In-Reply-To: <8BEB8CC1-625E-44F4-AB09-E71F1D15BBDC@neustar.biz> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 06 Feb 2013 08:40:02 +0100 (CET) Subject: Re: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 07:40:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/06/2013 05:23 AM, Edward Lewis wrote: > On Feb 5, 2013, at 17:20, Matthijs Mekking wrote: > >> It is a different case, however very similar to the case >> described in Section 7.2.3 and 8.5 in RFC 5155. The case in >> Section 7.2.3 and 8.5 are about No Data Responses, QTYPE is not >> DS. The case that Jinmei is describing is the Wildcard No Data >> Responses, described in Section 7.2.5 and 8.7. These sections >> also lack the text that is in errata #3441. But the errata is >> solely about Section 7.2.3 and 8.5. >> > > Ah, thanks, I got it now. I was staring too hard at what should > be returned and didn't pay attention to the section numbers. You are welcome. > >> Though it is described in RFC 5155 as a different case. However >> the problem logic is the similar: An NSEC3 is missing at the >> wildcard empty non-terminal because the empty non-terminal was >> derived from an insecure delegation. > > Do you suggest another errata filing against the other sections > (that is, in addition to the previous errata) or do we need to > scrap the previous one and enter a whole new one? Since the status of the errata is still on reported, perhaps its best to enter a whole new one. Best regards, Matthijs > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > There are no answers - just tradeoffs, decisions, and responses. > > > > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJREgjLAAoJEA8yVCPsQCW5KD4H/R+bUgCqWKaOPxtSKJXRcQAX V5GVdeVIun6gi/Ga58jKQpqxjOA91gihxdhJC9DjNs2TXhYJ7V+LuNHTH6yxUisU XTHxN4s1YpPbU9lzxj6niyE1syupv0bZskuJD5K+0ufJyREA/NqIZXjVayma0ow/ ++aSNPRm1flSWpwzmvjYPvCarT8rgOY1cu2D/6B0AZRTadVpWevbOHHzRTtj3R+/ rj+t+swYakl6NyHDAJr5g7bX4vT3PCGfwlC+bCSmsXkKV85UnIG+LLIAzWNuDXE0 /yE4YnxDKTVpLAFO96a2bXY2IE8OK+eo1PryAqr3bQKr9LX2XKSN8yjkaRVsG3U= =2+48 -----END PGP SIGNATURE----- From wwwrun@rfc-editor.org Thu Feb 7 13:51:03 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5821F87EE for ; Thu, 7 Feb 2013 13:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myzh38Waig06 for ; Thu, 7 Feb 2013 13:51:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 613EE21F86F5 for ; Thu, 7 Feb 2013 13:51:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 057D4B1E002; Thu, 7 Feb 2013 13:50:59 -0800 (PST) To: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com, rdroms.ietf@gmail.com, brian@innovationslab.net, ogud@ogud.com, ajs@anvilwalrusden.com From: RFC Errata System Message-Id: <20130207215059.057D4B1E002@rfc-editor.org> Date: Thu, 7 Feb 2013 13:50:59 -0800 (PST) X-Mailman-Approved-At: Fri, 08 Feb 2013 07:12:45 -0800 Cc: andy@arin.net, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC5155 (3479) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 21:51:04 -0000 The following errata report has been submitted for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3479 -------------------------------------- Type: Technical Reported by: Andy Newton Section: Apendix A Original Text ------------- The example in Appendix A has an NSEC3 next hashed owner name field with the non-base 32 characters 9, 0, and 1. Corrected Text -------------- The example should be changed so that the field in question is valid base 32. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5155 (draft-ietf-dnsext-nsec3-13) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From miekg@atoom.net Fri Feb 8 08:29:31 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0616521F8750 for ; Fri, 8 Feb 2013 08:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgq7lvVmiC9O for ; Fri, 8 Feb 2013 08:29:30 -0800 (PST) Received: from elektron.atoom.net (37-251-95-53.FTTH.ispfabriek.nl [37.251.95.53]) by ietfa.amsl.com (Postfix) with ESMTP id 60ED321F861B for ; Fri, 8 Feb 2013 08:29:29 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 845B63FFCB; Fri, 8 Feb 2013 17:29:27 +0100 (CET) Date: Fri, 8 Feb 2013 17:29:27 +0100 From: Miek Gieben To: RFC Errata System Message-ID: <20130208162927.GB23303@miek.nl> Mail-Followup-To: RFC Errata System , ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com, rdroms.ietf@gmail.com, brian@innovationslab.net, ogud@ogud.com, ajs@anvilwalrusden.com, andy@arin.net, dnsext@ietf.org References: <20130207215059.057D4B1E002@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <20130207215059.057D4B1E002@rfc-editor.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl X-Mailman-Approved-At: Fri, 08 Feb 2013 08:47:57 -0800 Cc: brian@innovationslab.net, geoff-s@panix.com, dnsext@ietf.org, andy@arin.net, rdroms.ietf@gmail.com, ogud@ogud.com Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (3479) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 16:29:31 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "[dnsext] [Technical Errata Report= ed..." ] > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D3479 >=20 > -------------------------------------- > Type: Technical > Reported by: Andy Newton >=20 > Section: Apendix A >=20 > Original Text > ------------- > The example in Appendix A has an NSEC3 next hashed owner name field with = the non-base 32 characters 9, 0, and 1. >=20 I think you missed (Section 1.3): when the hashed owner names are in base32, encoded with an Extended Hex Alphabet [RFC4648] grtz Miek --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlEVJ+cACgkQJYuFzziA0PaL5QCgy/AMTBcRTVsfsdYOBh6iK30a PW4An2B/kN/ni3WamXoBciN0AgDZ5/K9 =9RZq -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From andy@arin.net Fri Feb 8 08:45:56 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C8F21F8A94 for ; Fri, 8 Feb 2013 08:45:56 -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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wbz3uiNuc8K for ; Fri, 8 Feb 2013 08:45:55 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 1F31921F8976 for ; Fri, 8 Feb 2013 08:45:54 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 488BA165389; Fri, 8 Feb 2013 11:45:52 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id A4052165387; Fri, 8 Feb 2013 11:45:49 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 8 Feb 2013 11:45:11 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 8 Feb 2013 11:45:29 -0500 From: Andy Newton To: Miek Gieben , RFC Errata System Thread-Topic: [dnsext] [Technical Errata Reported] RFC5155 (3479) Thread-Index: AQHOBX7p4OV7GjSLTUuqMiQ/6sMHQJhwe8CA//+wBcs= Date: Fri, 8 Feb 2013 16:45:29 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEC251@CHAXCH01.corp.arin.net> References: <20130207215059.057D4B1E002@rfc-editor.org>, <20130208162927.GB23303@miek.nl> In-Reply-To: <20130208162927.GB23303@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.0.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 08 Feb 2013 08:47:58 -0800 Cc: "brian@innovationslab.net" , "geoff-s@panix.com" , "dnsext@ietf.org" , "rdroms.ietf@gmail.com" , "ogud@ogud.com" Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (3479) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 16:45:56 -0000 RFC 4648 explicitly says that base32hex should not be referred to as base32= . If the examples are correct, then the text is misleading in 5155. Section= s 1.3 and especially 3.3 should be changed to "base32hex" from base32.=0A= =0A= -andy=0A= =0A= ________________________________________=0A= From: Miek Gieben [miek@miek.nl]=0A= Sent: Friday, February 08, 2013 11:29 AM=0A= To: RFC Errata System=0A= Cc: ben@links.org; geoff-s@panix.com; roy@nominet.org.uk; davidb@verisign.c= om; rdroms.ietf@gmail.com; brian@innovationslab.net; ogud@ogud.com; ajs@anv= ilwalrusden.com; Andy Newton; dnsext@ietf.org=0A= Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (3479)=0A= =0A= [ Quoting in "[dnsext] [Technical Errata Report= ed..." ]=0A= > You may review the report below and at:=0A= > http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D3479=0A= >=0A= > --------------------------------------=0A= > Type: Technical=0A= > Reported by: Andy Newton =0A= >=0A= > Section: Apendix A=0A= >=0A= > Original Text=0A= > -------------=0A= > The example in Appendix A has an NSEC3 next hashed owner name field with = the non-base 32 characters 9, 0, and 1.=0A= >=0A= =0A= I think you missed (Section 1.3):=0A= =0A= when the hashed owner names are in base32, encoded with an Extended Hex= =0A= Alphabet [RFC4648]=0A= =0A= grtz Miek=0A= From hallam@gmail.com Sun Feb 10 09:15:44 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86AC21F861F for ; Sun, 10 Feb 2013 09:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=-2.735, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgjOQKHkNN+c for ; Sun, 10 Feb 2013 09:15:43 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5348D21F85B2 for ; Sun, 10 Feb 2013 09:15:43 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so2392951wib.2 for ; Sun, 10 Feb 2013 09:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BBjk1hFJTS4dLBr0pQvKVwUrZVDLNAimg1XGpTfiNZ4=; b=g72mkDZhmPMHBYSKwb2sNIn9D5oUsT4i/c9KL5147j3Ug3IejxpHYM48tHi/Je8Mf/ QpteI/CR4hvI4tWGCnwwoJ3s3eAkpSjHhzJ8dZfEClg6xlrWZSh57C58gs2c69Q6KJil 8VtK8U6/GBHcMSlJEN83pVBa8l4HEz42uKpHgnOhR/H98RXXkZa6/GeagVvdIlpupmWI T2tC2RhQCEZv9poKwZHTo8BYGV9MO1+QOo4b5xoj0KA3uNcbYjrKTsgwfe/B3k1cE3D2 wjjs7eW3WWNUB1zRFB9Cw/Ka5uLmaIwCXbg783brr4NJDQtcMUINrOmwQQLoHQUWzC+9 qGqQ== MIME-Version: 1.0 X-Received: by 10.194.158.165 with SMTP id wv5mr19367683wjb.45.1360516542514; Sun, 10 Feb 2013 09:15:42 -0800 (PST) Received: by 10.194.153.104 with HTTP; Sun, 10 Feb 2013 09:15:42 -0800 (PST) In-Reply-To: <510DB845.2090705@dougbarton.us> References: <50FA1596.6050803@dougbarton.us> <510DB845.2090705@dougbarton.us> Date: Sun, 10 Feb 2013 12:15:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Doug Barton Content-Type: multipart/alternative; boundary=089e0122ef883a47b504d561f17b Cc: dnsext@ietf.org Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 17:15:44 -0000 --089e0122ef883a47b504d561f17b Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 2, 2013 at 8:07 PM, Doug Barton wrote: > On 01/22/2013 06:21 AM, Phillip Hallam-Baker wrote: > >> OK so looks like the optional policy string is not a good idea. At least >> as far as the normal form goes. >> >> >> >> On Fri, Jan 18, 2013 at 10:40 PM, Doug Barton > > wrote: >> >> On 01/18/2013 09:35 AM, Phillip Hallam-Baker wrote: >> >> * SRV (does not work well for Web services) >> >> >> Can you elaborate, or provide a reference? >> >> Doug >> >> >> The problem with SRV and Web services is that a typical Web Server >> deployment supports multiple Web Services, some of which are only going >> to be called maybe five times a day, if that. So the Web Services >> actually make use of the stem part of the URI to identify the location >> on the Web Server. >> > > How would that change with the use of an SRV record? > > > So to use SRV to announce a Web Service you need some way to specify the >> location on the Web Server. >> > > Why? It is very common for a single Apache server to be supporting a dozen or more Web Services as applets. The Microsoft platforms now go even further providing what amounts to an operating system level treatment of Web Service locations as if they were TCP/IP port numbers complete with granular security privileges. SRV only allows for defining a DNS name and a port number, there is no provision for a service location which is why the 'well known' locations were originally proposed. But just like fixed port numbers, that is a pretty inflexible approach that gets in the way of development and test deployment. It is OK to have a requirement for the Web Service to be at /.well-known/foo for production, but most of us would want to bring up a new service by first deploying it on the target server somewhere else, testing it and then cutting over to the new one by changing the config. Which is why the URI proposal is a logical extension of the SRV idea. My original belief was that SRV would be sufficient and all we needed was to define a _wk space for SRV prefixes so that defining a .well-known prefix would automatically assign an SRV prefix just like a well known port used to when there were ports left. People in the apps area convinced me otherwise. URI would be a logical choice only it hasn't had wide uptake yet and does not support any mechanism to allow the client to make an informed choice between the services offered according to its own criteria or policy advice. > One approach is to specify a .well-known >> location for the service but that is rather less flexible than many >> deployments will accept and it stops a server having two different >> versions of the same protocol running in parallel - something you are >> very likely to want to do if you are witching between protocol versions >> or implementation versions. >> > > Sorry, I don't parse the above paragraph at all. > > In my (perhaps naive) view, the purpose of the SRV record is to allow the > end user system to find the right address and port to connect to for the > specified service. The things you're describing seem to me to be the > business of the web server once the end user is connected. If I have missed > something here, please clue me in. If you have multiple services on different hosts you need to make the choice before you connect to the server. Afterwards is too late. -- Website: http://hallambaker.com/ --089e0122ef883a47b504d561f17b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 2, 2013 at 8:07 PM, Doug Bar= ton <dougb@dougbarton.us> wrote:
On 01/22/2013 06:21 AM, Phillip Hallam-Baker wrote:
OK so looks like the optional policy string is not a good idea. At least as far as the normal form goes.



On Fri, Jan 18, 2013 at 10:40 PM, Doug Barton <dougb@dougbarton.us
<mailto:dougb@d= ougbarton.us>> wrote:

=A0 =A0 On 01/18/2013 09:35 AM, Phillip Hallam-Baker wrote:

=A0 =A0 =A0 =A0 * SRV (does not work well for Web services)


=A0 =A0 Can you elaborate, or provide a reference?

=A0 =A0 Doug


The problem with SRV and Web services is that a typical Web Server
deployment supports multiple Web Services, some of which are only going
to be called maybe five times a day, if that. So the Web Services
actually make use of the stem part of the URI to identify the location
on the Web Server.

How would that change with the use of an SRV record?


So to use SRV to announce a Web Service you need some way to specify the location on the Web Server.

Why?

It is very common for a single Apache = server to be supporting a dozen or more Web Services as applets. The Micros= oft platforms now go even further providing what amounts to an operating sy= stem level treatment of Web Service locations as if they were TCP/IP port n= umbers complete with granular security privileges.

SRV only allows for defining a DNS name and a port numb= er, there is no provision for a service location which is why the 'well= known' locations were originally proposed. But just like fixed port nu= mbers, that is a pretty inflexible approach that gets in the way of develop= ment and test deployment. It is OK to have a requirement for the Web Servic= e to be at /.well-known/foo for production, but most of us would want to br= ing up a new service by first deploying it on the target server somewhere e= lse, testing it and then cutting over to the new one by changing the config= .

Which is why the URI proposal is a logical extension of= the SRV idea.


My original belief w= as that SRV would be sufficient and all we needed was to define a _wk space= for SRV prefixes so that defining a .well-known prefix would automatically= assign an SRV prefix just like a well known port used to when there were p= orts left. People in the apps area convinced me otherwise.

URI would be a logical choice only it hasn't had wi= de uptake yet and does not support any mechanism to allow the client to mak= e an informed choice between the services offered according to its own crit= eria or policy advice.


=A0
=
One approach is to specify a .well-known
location for the service but that is rather less flexible than many
deployments will accept and it stops a server having two different
versions of the same protocol running in parallel - something you are
very likely to want to do if you are witching between protocol versions
or implementation versions.

Sorry, I don't parse the above paragraph at all.

In my (perhaps naive) view, the purpose of the SRV record is to allow the e= nd user system to find the right address and port to connect to for the spe= cified service. The things you're describing seem to me to be the busin= ess of the web server once the end user is connected. If I have missed some= thing here, please clue me in.

If you have multiple services on different hosts you ne= ed to make the choice before you connect to the server. Afterwards is too l= ate.


=A0

--
Website: http://hallambaker.com/=
--089e0122ef883a47b504d561f17b-- From hallam@gmail.com Sun Feb 10 11:01:56 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D150B21F8887 for ; Sun, 10 Feb 2013 11:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=-2.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP4ubnKYh3oL for ; Sun, 10 Feb 2013 11:01:56 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id AD8AA21F8694 for ; Sun, 10 Feb 2013 11:01:55 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn17so2470398wib.16 for ; Sun, 10 Feb 2013 11:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wo1myCO4+Hn1wH0EmauAh6U4xCKihOqM+v9K1TA1V5M=; b=JSBhkTRHQ4EiQIg+n5dnDpwSu0MEA51Y2Mla/brpkGNqVRDquDBv8xrXqsH4EXUoDi GU3w24wmwC4VgzZP8apXGfolm9dHW5WV3NCtgex10kQCMUZX2WMhugJlhjcigujWHcJf 4O80JAuATM8LlOPDWmoHxiJldtjFopPhdBFVEaJFuotFnkUN94z8+GB8dg364ya1pXh2 Gs+pPAlHj7aXfviCVHV1L2RnoNDYt5akXhWXw/GSTqse+nFDd4Q+pSZUE1J+5+C9gBkw BEcGOqNY6AzIWVQDoV6Yt5x9bEIgAcwHYB51OnXp3YFUB7YkXeqtCe2bNIkb2azJzuBS Qrbg== MIME-Version: 1.0 X-Received: by 10.180.81.164 with SMTP id b4mr12072912wiy.34.1360522914850; Sun, 10 Feb 2013 11:01:54 -0800 (PST) Received: by 10.194.153.104 with HTTP; Sun, 10 Feb 2013 11:01:54 -0800 (PST) In-Reply-To: <878v72hmo1.fsf@mid.deneb.enyo.de> References: <878v72hmo1.fsf@mid.deneb.enyo.de> Date: Sun, 10 Feb 2013 14:01:54 -0500 Message-ID: From: Phillip Hallam-Baker To: Florian Weimer Content-Type: multipart/alternative; boundary=14dae9cc9fbe0c667404d5636d0d Cc: dnsext@ietf.org Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 19:01:57 -0000 --14dae9cc9fbe0c667404d5636d0d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 9:15 AM, Florian Weimer wrote: > * Phillip Hallam-Baker: > > > Over the years several people have proposed a record that would be used > to > > specify a public suffix. For example: > > > > .com PUBLIC > > .co.uk PUBLIC > > .ac.uk PUBLIC > > .net PUBLIC > > ISC recommends a configuration for the BIND resolver which suppresses > such RRs in the COM and NET zones (and others), so it's not clear to > me if such records would make it to clients in practice. > That is irrelevant because 1) The proposal is designed to allow the parties who maintain public suffix lists a means of gathering the data rather than this being something clients would consume directly. It is not going to be practical for clients to consume this information directly for a long time. 2) ISC's advice on configuration does not determine the DNS standard. It is at any rate mutable. So even if it was an issue I would take it as indicating that ISC should be asked to change their config advice rather than anything more. -- Website: http://hallambaker.com/ --14dae9cc9fbe0c667404d5636d0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 5, 2013 at 9:15 AM, Florian = Weimer <fw@deneb.enyo.de> wrote:
* Phillip Hallam-Baker:

> Over the years several people have proposed a record that would be use= d to
> specify a public suffix. For example:
>
> =A0 =A0.com =A0 =A0PUBLIC
> =A0 =A0.co.uk =A0PUBLIC=
> =A0 =A0.ac.uk =A0PUBLIC=
> =A0 =A0.net =A0 =A0 PUBLIC

ISC recommends a configuration for the BIND resolver which suppresses=
such RRs in the COM and NET zones (and others), so it's not clear to me if such records would make it to clients in practice.

That is irrelevant because

1) The proposal is designed to allow the parties who mainta= in public suffix lists a means of gathering the data rather than this being= something clients would consume directly.

It is not going to be practical for clients to consume = this information directly for a long time.

2) ISC&= #39;s advice on configuration does not determine the DNS standard. It is at= any rate mutable. So even if it was an issue I would take it as indicating= that ISC should be asked to change their config advice rather than anythin= g more.



--
Website: http://hallambaker.com/
--14dae9cc9fbe0c667404d5636d0d-- From hallam@gmail.com Sun Feb 10 11:27:41 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77CB21F8319 for ; Sun, 10 Feb 2013 11:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.922 X-Spam-Level: X-Spam-Status: No, score=-4.922 tagged_above=-999 required=5 tests=[AWL=-2.564, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmAsmsoEZfqE for ; Sun, 10 Feb 2013 11:27:37 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9815F21F8203 for ; Sun, 10 Feb 2013 11:27:36 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so4140846wgb.1 for ; Sun, 10 Feb 2013 11:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uUSsEHSwtqSsIqInclKXKu6V+XZeH4BLaZyhkidQvrQ=; b=ILwD7WpjvlUEQ5jNGxe8WRAXzlYCZPm7fhdYMpWDrWw6x5oREVVgKYpB6kh757jFls gPQ1pVZkwTMey2X8baw98vyP4I3Mb4U9xDDI4XVh0k6KfR6HNWJGG+DZNwzPHYYFqvXR 3a8GfWMcjW0Eeg6msnmRFgX6ZngASz//NsdKheg7ZUwocFus2JOrQx5k5Jb8nivAphOL ujMDxB6lUaHjXb5kAUnTelBRUjl0BxYJwYEM4i+BOS9y7eMQyn92IOZ8W3DdBrZ50ZUR zjgP4wN8ZTyKLrg8bn0dXQRV0Wa7O4Hsydm8k282/oIJGH1S0GuOnUG9Mr0dDhfbrwch 1WnQ== MIME-Version: 1.0 X-Received: by 10.194.171.198 with SMTP id aw6mr19822322wjc.3.1360524453519; Sun, 10 Feb 2013 11:27:33 -0800 (PST) Received: by 10.194.153.104 with HTTP; Sun, 10 Feb 2013 11:27:33 -0800 (PST) In-Reply-To: <20130202070225.GB25364@mx1.yitter.info> References: <20130202070225.GB25364@mx1.yitter.info> Date: Sun, 10 Feb 2013 14:27:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e0122f58ec2a08c04d563c8da Cc: dnsext@ietf.org Subject: Re: [dnsext] Announcing public suffixes as a DNS record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 19:27:41 -0000 --089e0122f58ec2a08c04d563c8da Content-Type: text/plain; charset=ISO-8859-1 Yeah, I knew someone had raised it but could not remember who it was. On Sat, Feb 2, 2013 at 2:02 AM, Andrew Sullivan wrote: > In case it wasn't clear, no hat. > > On Fri, Feb 01, 2013 at 12:32:12PM -0500, Phillip Hallam-Baker wrote: > > Andrew's proposal is essentially the opposite of mine. Instead of > > assertions of the form 'this is a gap in the trust model', Andrew > proposes > > that the default is disconnected and trust is only established if there > is > > an explicit link. > > > > That is definitely the right way to do this particular feature for > > JavaScript if starting from scratch. (OK no the right way is not to do it > > at all but..) But I don't see a viable transition strategy from where we > > are to where we want to be. > > I don't see why. First, it seems to me that it is the only reasonable > security model at all. Moreover, the mechanism I propose fully > subsumes your proposal, because ICANN and others could make an > equivalent to the PUBLIC proposal you offer, just by publishing a > record that says nobody lives in the same administrative realm. (This > is the SOPA with root-target record.) Indeed, the reason I had a > default-don't-trust _plus_ a mechanism to state don't-trust explicitly > was exactly so that we could start out by making such don't-trust > statements; that way, you could "fail hard" on the root-target > statements and still play games guessing with domain names, until the > new mechanism can be adopted widely. Anyway, that's the intention, so > if it's not clear discussion is welcome. > I think it has to be two separate tracks. In the short term we need to do something to help the maintainers of the public suffix lists while ICANN is busy increasing the number of TLDs. The objective there is to get the new TLDs to do no harm and not make the problem worse. This is easiest to do when the TLD applicants are bidding to get names and most willing to agree to do things to get their name. As far as the CA business goes, what we need to know about are the public delegation points. The security concerns are significant but not quite the same as for Javascript. In fact the default permit/default deny are arguably reversed. Fixing the insane security model for Javascript and cookies would be good but I see that as secondary and something that will take quite a while to feed through. I was hoping to have that discussion on apps-discuss, mostly because > that's where the consumers of this data are, and previous attempts to > work out this stuff in the DNS community (and then present it to > consumers as finished) have failed. Maybe we could move this there? > Also, I'd be delighted to have a tag-team discussion of these two > competing proposals in Orlando, if you think it's worth pursuing. Yeah lets plan on doing that, I was not sure whether to go to Orlando but that would be a reason to do it. I think it is a DNS community discussion, not just apps area as the forcing function here is the introduction of the new TLDs that will call the sclability of the existing scheme into question. -- Website: http://hallambaker.com/ --089e0122f58ec2a08c04d563c8da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, I knew someone had raised it but could not remember who it was.
On Sat, Feb 2, 2013 at 2:02 AM, Andrew Sulliva= n <ajs@anvilwalrusden.com> wrote:
In case it wasn't clear, no hat.

On Fri, Feb 01, 2013 at 12:32:12PM -0500, Phillip Hallam-Baker wrote:
> Andrew's proposal is essentially the opposite of mine. Instead of<= br> > assertions of the form 'this is a gap in the trust model', And= rew proposes
> that the default is disconnected and trust is only established if ther= e is
> an explicit link.
>
> That is definitely the right way to do this particular feature for
> JavaScript if starting from scratch. (OK no the right way is not to do= it
> at all but..) But I don't see a viable transition strategy from wh= ere we
> are to where we want to be.

I don't see why. =A0First, it seems to me that it is the only rea= sonable
security model at all. =A0Moreover, the mechanism I propose fully
subsumes your proposal, because ICANN and others could make an
equivalent to the PUBLIC proposal you offer, just by publishing a
record that says nobody lives in the same administrative realm. =A0(This is the SOPA with root-target record.) =A0Indeed, the reason I had a
default-don't-trust _plus_ a mechanism to state don't-trust explici= tly
was exactly so that we could start out by making such don't-trust
statements; that way, you could "fail hard" on the root-target statements and still play games guessing with domain names, until the
new mechanism can be adopted widely. =A0Anyway, that's the intention, s= o
if it's not clear discussion is welcome.

I think it has to be two separate tracks. In the short term we need t= o do something to help the maintainers of the public suffix lists while ICA= NN is busy increasing the number of TLDs. The objective there is to get the= new TLDs to do no harm and not make the problem worse. This is easiest to = do when the TLD applicants are bidding to get names and most willing to agr= ee to do things to get their name.

As far as the CA business goes, what we need to know ab= out are the public delegation points. The security concerns are significant= but not quite the same as for Javascript. In fact the default permit/defau= lt deny are arguably reversed.=A0

Fixing the insane security model for Javascript and coo= kies would be good but I see that as secondary and something that will take= quite a while to feed through.=A0


I was hoping to have that discussion on apps-discuss, mostly because
that's where the consumers of this data are, and previous attempts to work out this stuff in the DNS community (and then present it to
consumers as finished) have failed. =A0Maybe we could move this there?
Also, I'd be delighted to have a tag-team discussion of these two
competing proposals in Orlando, if you think it's worth pursuing.

Yeah lets plan on doing that, I was not sure whe= ther to go to Orlando but that would be a reason to do it.=A0

I think it is a DNS community discussion, not just apps area= as the forcing function here is the introduction of the new TLDs that will= call the sclability of the existing scheme into question.



--
Website: http://hallambaker.com/
--089e0122f58ec2a08c04d563c8da-- From hallam@gmail.com Wed Feb 13 11:08:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9329F21F84B9 for ; Wed, 13 Feb 2013 11:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rlaeByv460r for ; Wed, 13 Feb 2013 11:08:12 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 503C221F84B6 for ; Wed, 13 Feb 2013 11:08:09 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t57so1320725wey.13 for ; Wed, 13 Feb 2013 11:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=L4cFR3JGINtQrC2vSe2Homr/aADdpoc4BiU2iT3B/II=; b=lXdz/UtF+S380zgKtDgzBMkVosr9yqlEyf6fnpjjGeZnRTJ40iRtjkEqoTqJk8lXJM IpPtW4bH/DCatzStm2FOd6pdVITGT/kx4V4OVgECGMUV3BFnKbFXIiOIkmeTGGtZja6H IwsZwOfCGAOdBchepOEM0mm0F/xFNisHLDxqV8dj4vfdUiEOsfV23aH/r13PBP3XwFcP bF0YD6lcHisJ+0HhadH4TXOT1zOuvqIkEodtJIxGDJJ5SVOfmotsNmb2Y2xZ8WkC7UYk 0NhYTL3mSRLqujgRO9x4JRqnRz+W9lqMRy+LGBEwKYnuU7uIhUS+9tg+Qe3kiDUvN7nk 7ViQ== MIME-Version: 1.0 X-Received: by 10.180.81.164 with SMTP id b4mr12182913wiy.34.1360782487336; Wed, 13 Feb 2013 11:08:07 -0800 (PST) Received: by 10.194.19.226 with HTTP; Wed, 13 Feb 2013 11:08:07 -0800 (PST) Date: Wed, 13 Feb 2013 14:08:07 -0500 Message-ID: From: Phillip Hallam-Baker To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=14dae9cc9fbec6371504d59fdc9b Subject: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:08:13 -0000 --14dae9cc9fbec6371504d59fdc9b Content-Type: text/plain; charset=ISO-8859-1 As mentioned earlier, I would like to use the URI scheme for discovery. But I need a little more information that the current format allows: http://tools.ietf.org/html/draft-faltstrom-uri-06 The URI of the target, enclosed in double-quote characters ('"'). Resolution of the URI is according to the definitions for the Scheme of the URI. The URI is encoded as one or more RFC1035 section 3.3 [RFC1035 ]. It occurred to me that since a URI must not contain a space character, it would be possible to add the optional parameters I would like to add for discovery by simply changing the format of the target field as follows: target = uri [ ' ' parameters] So a domain might be specified as follows: _foo._wk.example.com URI 10 10 URI "http://host1.example.com/" _foo._wk.example.com URI 10 10 URI "http://host2.example.com/ v=2.1" The first is a regular URI specification without any parameter. The second add in a version parameter to tell a client which version of the protocol that service supports. In most cases we only really need to know if the service supports a minimum version of the protocol. But there might be occasions where the service required clients support a minimum protocol version, particularly in the case of an incompatible protocol upgrade, this might be supported by a 'mv' parameter for minimum version: _foo._wk.example.com URI 10 10 URI "http://host3.example.com/ v=2.1 mv=2.0" The main advantage to this approach is that it allows the URI scheme to be used to express all the information relevant to a client discovery decision, either explicitly or by reference. I see two routes to achieving this functionality 1) Redefine URI as outlined above Pro: It is compatible, does not need new code for those already implementing URI in servers Con: It might be seen as breaking the principle that a change to the format Con: If there is implementation of the URI scheme, records with parameters could cause things to break 2) Define another record as outlined above Pro: Guarantees nothing breaks Con: Will need new code Con: Means there are 3 SRV like discovery schemes instead of just 2. -- Website: http://hallambaker.com/ --14dae9cc9fbec6371504d59fdc9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
As mentioned earlier, I would like to use the URI scheme for discovery=
. But I need a little more information that the current format allows:


http://tools.ietf.org/html/draft-faltstrom-uri-06=A0



The URI of the target, enclosed in double-quote charact=
ers ('"').
   Resolution of the URI is according to the definitions for the Scheme
   of the URI.

   The URI is encoded as one or more <character-string> RFC1035 section=A0
   3.3 [RFC1035].
It occurred to me that since a URI must not contain a space = character, it would be possible to add the optional parameters I would like= to add for discovery by simply changing the format of the target field as = follows:

target =3D uri [ ' ' parameters]

=
So a domain might be specified as follows:

<= div>_foo._wk.example.com =A0URI 10 10= URI "http://host1.example.com/<= /a>"

The first is a regular URI spec= ification without any parameter. The second add in a version parameter to t= ell a client which version of the protocol that service supports.

In most cases we only really need to know if the servic= e supports a minimum version of the protocol. But there might be occasions = where the service required clients support a minimum protocol version, part= icularly in the case of an incompatible protocol upgrade, this might be sup= ported by a 'mv' parameter for minimum version:



The main advantage to this approach is that it allows the URI scheme to be = used to express all the information relevant to a client discovery decision= , either explicitly or by reference.=A0

I see two = routes to achieving this functionality

1) Redefine URI as outlined above

<= div>Pro: It is compatible, does not need new code for those already impleme= nting URI in servers
Con: It might be seen as breaking the princi= ple that a change to the format
Con: If there is implementation of the URI scheme, records with parame= ters could cause things to break

2) Define another= record as outlined above

Pro: Guarantees nothing = breaks
Con: Will need new code
Con: Means there are 3 SRV like disc= overy schemes instead of just 2.

--
Website: http://hallambaker.com/
--14dae9cc9fbec6371504d59fdc9b-- From paf@frobbit.se Wed Feb 13 11:11:26 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0808E21F84C0 for ; Wed, 13 Feb 2013 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmNvb9I7+q3w for ; Wed, 13 Feb 2013 11:11:22 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1B21F84BF for ; Wed, 13 Feb 2013 11:11:21 -0800 (PST) Received: from [10.100.1.11] (unknown [192.0.44.0]) by mail.frobbit.se (Postfix) with ESMTPSA id A081921A9E; Wed, 13 Feb 2013 20:11:20 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_2805DD5F-2F1E-41AA-B5CB-A58DF5E0179F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 13 Feb 2013 14:11:18 -0500 Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: dnsext@ietf.org Subject: Re: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:11:26 -0000 --Apple-Mail=_2805DD5F-2F1E-41AA-B5CB-A58DF5E0179F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 13 feb 2013, at 14:08, Phillip Hallam-Baker wrote: > It occurred to me that since a URI must not contain a space character, = it would be possible to add the optional parameters I would like to add = for discovery by simply changing the format of the target field as = follows: >=20 > target =3D uri [ ' ' parameters] >=20 > So a domain might be specified as follows: >=20 > _foo._wk.example.com URI 10 10 URI "http://host1.example.com/" > _foo._wk.example.com URI 10 10 URI "http://host2.example.com/ v=3D2.1" If you go down this path, why not have multiple strings: _foo._wk.example.com URI 10 10 URI "http://host2.example.com/" "v=3D2.1" Patrik --Apple-Mail=_2805DD5F-2F1E-41AA-B5CB-A58DF5E0179F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 hallam@gmail.com> = wrote:
It = occurred to me that since a URI must not contain a space character, it = would be possible to add the optional parameters I would like to add for = discovery by simply changing the format of the target field as = follows:
target = =3D uri [ ' ' parameters]
So a = domain might be specified as follows:
wk.example.com  URI 10 10 URI "http://host1.example.com/"
_foo._wk.example.com  URI 10 10 URI "http://host2.example.com/ v=3D2.1"

If you go down this path, why not have multiple = strings:

_foo._wk.example.com  URI 10 10 = URI "http://host2.example.com/" "v=3D= 2.1"

  =  Patrik

= --Apple-Mail=_2805DD5F-2F1E-41AA-B5CB-A58DF5E0179F-- From brian.peter.dickson@gmail.com Wed Feb 13 12:31:01 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48EC21E804C for ; Wed, 13 Feb 2013 12:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRfhyn+RqXNB for ; Wed, 13 Feb 2013 12:31:01 -0800 (PST) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1071B21E803D for ; Wed, 13 Feb 2013 12:31:01 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so1633958iae.11 for ; Wed, 13 Feb 2013 12:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TavPzsCtnJdaKsR7gCal6PY6c6r6YBYULFBXcdfCZGk=; b=s/oiPUdcafRcdhqcOCYLorVlX61kKpD4LGPSuN4ECSmnJ6/PcQ1RfaU1utL+NggnuU gGJPn9niuLoNlqYQDtSG6RZ3Ft0f7Uu/i/UBhl4mP1t/4jpcOq9kFn4XV27VCVYC7tQ2 BDteMNH0MtOZR/qkxcTpV3EPDbKoTn7HnA/Unl96V1enaYcyivxLIeLQN8C2vVcu68A9 4ya5bYtPyP1oaxB55Xfcmz4BJSgm6Hc0mr5wLDBr/74kPHg6dn9q+e/+LJbR5XfI+17o TsUazUjiF7V3Xr99ENdDIJjnIre1txPDSYathOYeRDtaWLOaxMZyxqNLLwbGAb75fNrI K27A== MIME-Version: 1.0 X-Received: by 10.50.194.164 with SMTP id hx4mr13393181igc.35.1360787460630; Wed, 13 Feb 2013 12:31:00 -0800 (PST) Received: by 10.64.40.234 with HTTP; Wed, 13 Feb 2013 12:31:00 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 15:31:00 -0500 Message-ID: From: Brian Dickson To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=14dae9340de134a9bb04d5a1057b Cc: dnsext@ietf.org Subject: Re: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:31:01 -0000 --14dae9340de134a9bb04d5a1057b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Clever hack: Since the (current) wire format is URI without double quotes, this can be extended to multiple strings by using double-quote character(s) on-the-wire to delimit the individual strings. "foo" "bar" <=3D> foo"bar (And the current trick of extra-long strings being broken at every 255th character into separate objects also works.) Just suggesting technical tricks. Brian On Wed, Feb 13, 2013 at 2:11 PM, Patrik F=E4ltstr=F6m wrot= e: > > On 13 feb 2013, at 14:08, Phillip Hallam-Baker wrote: > > It occurred to me that since a URI must not contain a space character, it > would be possible to add the optional parameters I would like to add for > discovery by simply changing the format of the target field as follows: > > target =3D uri [ ' ' parameters] > > So a domain might be specified as follows: > > _foo._wk.example.com URI 10 10 URI "http://host1.example.com/" > _foo._wk.example.com URI 10 10 URI "http://host2.example.com/ v=3D2.1" > > > If you go down this path, why not have multiple strings: > > _foo._wk.example.com URI 10 10 URI "http://host2.example.com/" "v=3D2.1" > > Patrik > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > --14dae9340de134a9bb04d5a1057b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Clever hack:

Since the (current) wire format is URI with= out double quotes, this can be extended to multiple strings by using double= -quote character(s) on-the-wire to delimit the individual strings.
"foo" "bar" <=3D> foo"bar
(An= d the current trick of extra-long strings being broken at every 255th chara= cter into separate <string> objects also works.)

Just suggesting technical tricks.

Brian
On Wed, Feb 13, 2013 at 2:11 PM, Patrik F=E4lt= str=F6m <paf@frobbit.se> wrote:

On 13 feb 2013, at 14:08, Phillip Hallam-Baker <= hallam@gmail.com&= gt; wrote:

It occurred to me that since a URI must not contain a space character, it w= ould be possible to add the optional parameters I would like to add for dis= covery by simply changing the format of the target field as follows:

target =3D uri [ ' ' parameters]

So a domain might be specified as follows:


If you go down this path, why not have multiple string= s:

_foo._wk.example.com=A0=A0URI 10 10 URI &q= uot;http://host2.ex= ample.com/"=A0"v=3D2.1"

<= div>=A0 =A0Patrik


_____________= __________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext


--14dae9340de134a9bb04d5a1057b-- From paf@frobbit.se Wed Feb 13 12:34:24 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25321E804C for ; Wed, 13 Feb 2013 12:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM-QzwsrBT49 for ; Wed, 13 Feb 2013 12:34:24 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 08F0721E803D for ; Wed, 13 Feb 2013 12:34:24 -0800 (PST) Received: from [10.100.1.11] (unknown [192.0.44.0]) by mail.frobbit.se (Postfix) with ESMTPSA id 701FD21AE5; Wed, 13 Feb 2013 21:34:22 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_B17859E2-C609-4905-900A-6FD818E7D596" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 13 Feb 2013 15:34:20 -0500 Message-Id: References: To: Brian Dickson X-Mailer: Apple Mail (2.1499) Cc: dnsext@ietf.org Subject: Re: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:34:24 -0000 --Apple-Mail=_B17859E2-C609-4905-900A-6FD818E7D596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 13 feb 2013, at 15:31, Brian Dickson = wrote: > Since the (current) wire format is URI without double quotes, this can = be extended to multiple strings by using double-quote character(s) = on-the-wire to delimit the individual strings. I was just suggesting imitating the syntax of the TXT format. Patrik --Apple-Mail=_B17859E2-C609-4905-900A-6FD818E7D596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 brian.peter.dickson@gmail.co= m> wrote:
Since = the (current) wire format is URI without double quotes, this can be = extended to multiple strings by using double-quote character(s) = on-the-wire to delimit the individual = strings.

I was just suggesting = imitating the syntax of the TXT format.

  =  Patrik

= --Apple-Mail=_B17859E2-C609-4905-900A-6FD818E7D596-- From hallam@gmail.com Wed Feb 13 12:59:54 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAF421F874C for ; Wed, 13 Feb 2013 12:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=-2.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofJ4oo6DMkx8 for ; Wed, 13 Feb 2013 12:59:53 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 768EB21F873B for ; Wed, 13 Feb 2013 12:59:53 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l13so6263033wie.8 for ; Wed, 13 Feb 2013 12:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gA1WCUNOXqTTXDPJEmJlzvl7PUp1MhK0oA71a/yAbGg=; b=YhuCTcYsqmssf+IICt551kipz9MU5sH5jv681k4Lg24fjGGRATFkTkm6u79+FMy+oQ ioiN4Ja9Cux1a9KzJivY6sGI1QRUmUoeEifPKGPxktdhmTc0xT8oBa1VdXcVmP5DDsTQ Y3y5DaooWKTgZvzRB/z0ZTgfrEm9izxa4i2SAwRnNfGnWLxkzu7s7a7sDlf5fbWzA1ae 6lvsDBsupIBxn0J7YJV0c1UE4y8VO0a3jyjHjx8mRkVAa1mUsXF8wVCYlnFIUh2qWRzf SUiglZBMZW7mGUoxGmhuoM9lX8njYX32uCs0bmWvW999k9Qx4sjVzjE73wKvhx0yeNaC zH3w== MIME-Version: 1.0 X-Received: by 10.194.158.165 with SMTP id wv5mr40705832wjb.45.1360789192625; Wed, 13 Feb 2013 12:59:52 -0800 (PST) Received: by 10.194.19.226 with HTTP; Wed, 13 Feb 2013 12:59:52 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 15:59:52 -0500 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=089e0122ef8870ce7404d5a16c5a Cc: dnsext@ietf.org Subject: Re: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:59:54 -0000 --089e0122ef8870ce7404d5a16c5a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 2:11 PM, Patrik F=E4ltstr=F6m wrot= e: > > On 13 feb 2013, at 14:08, Phillip Hallam-Baker wrote: > > It occurred to me that since a URI must not contain a space character, it > would be possible to add the optional parameters I would like to add for > discovery by simply changing the format of the target field as follows: > > target =3D uri [ ' ' parameters] > > So a domain might be specified as follows: > > _foo._wk.example.com URI 10 10 URI "http://host1.example.com/" > _foo._wk.example.com URI 10 10 URI "http://host2.example.com/ v=3D2.1" > > > If you go down this path, why not have multiple strings: > > _foo._wk.example.com URI 10 10 URI "http://host2.example.com/" "v=3D2.1" > > Patrik > > The URI record as currently specified permits multiple strings but does not explicitly state what having more than one string means. I am quite happy to use multiple strings for the same effect. In fact that ends up with a scheme that looks essentially the same as my proposal for an optional extra string. Question then would be whether multiple parameters would require separate strings or could be space separated in one string. The syntax does not worry me. All that I care about is to find the shortest path from where we are to a DNS record that allows discovery 'with parameters'. One other question that should be addressed in the URI spec (unless I missed it) is what the discovery process should be if there is an SRV record and a URI record. The drift of the spec was that the protocol designer should choose. I don't think that is the way to go. If we have a 'service discovery API' that we ask questions like 'how should I connect to service X at DNS name Y', we should factor out as much of the 'special case handling' from the scheme as possible. URI offers a superset of the A, AAAA, and SRV discovery capabilities. It makes sense to make a URI record take precedence over all others if it is present because that means we can use the URI parameters to tell an aware discovery API that there may be a 'better' choice for its needs than they would have chosen through round robin A records. So lets imagine we want to advertise support for the new version of the HTTP protocol but only for one of the two servers deployed. Our DNS file might look like this: ; A records to be used by legacy hosts www.example.com A 10.1.1.1 www.example.com A 10.1.1.2 host1.example.com A 10.1.1.1 host2.example.com A 10.1.1.2 ; URI records, can be used by aware clients only host2 supports HTTP/2.0 _http._tcp.www.example.com URI 10 10 "http://host1.example.com/" _http._tcp.www.example.com URI 10 10 "http://host2.example.com/" "v=3D2.0" OK, so you might think that looks a silly way to encode a host name for a web server. But look what else you could do: _http._tcp.legacy.example.com 10 10 "http://archive.example.com/legacy/" We have just created a way of specifying a site level http redirect in the DNS at no extra cost. You might argue as to whether that is a desirable approach. But it is clean and it is consistent. I think that shows it is the right path at the very least. --=20 Website: http://hallambaker.com/ --089e0122ef8870ce7404d5a16c5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 13, 2013 at 2:11 PM, Patrik = F=E4ltstr=F6m <paf@frobbit.se> wrote:

On 13 f= eb 2013, at 14:08, Phillip Hallam-Baker <hallam@gmail.com> wrote:

It occurred to me that since a URI must not contain a space character, it w= ould be possible to add the optional parameters I would like to add for dis= covery by simply changing the format of the target field as follows:

target =3D uri [ ' ' parameters]

So a domain might be specified as follows:


If you go down this path, why not have multiple string= s:

_foo._wk.example.com=A0=A0URI 10 10 URI &q= uot;http://host2.ex= ample.com/"=A0"v=3D2.1"

<= div>=A0 =A0Patrik


The URI record as currently specified permits multiple strings but do= es not explicitly state what having more than one string means.

I am quite happy to use multiple strings for the same effect= . In fact that ends up with a scheme that looks essentially the same as my = proposal for an optional extra string.

Question th= en would be whether multiple parameters would require separate strings or c= ould be space separated in one string.


The syntax does not worry me. All that I= care about is to find the shortest path from where we are to a DNS record = that allows discovery 'with parameters'.


One other question that should be addressed in th= e URI spec (unless I missed it) is what the discovery process should be if = there is an SRV record and a URI record. The drift of the spec was that the= protocol designer should choose. I don't think that is the way to go.<= /div>

If we have a 'service discovery API' that we as= k questions like 'how should I connect to service X at DNS name Y',= we should factor out as much of the 'special case handling' from t= he scheme as possible.

URI offers a superset of the A, AAAA, and SRV discovery= capabilities. It makes sense to make a URI record take precedence over all= others if it is present because that means we can use the URI parameters t= o tell an aware discovery API that there may be a 'better' choice f= or its needs than they would have chosen through round robin A records.


So lets imagine we want to advertise sup= port for the new version of the HTTP protocol but only for one of the two s= ervers deployed. Our DNS file might look like this:

; A records to be used by legacy hosts
www.example.com =A0 A 10.1.1.1
www.example.com =A0 A 10.1.1.2

<= div>
host1.example.com =A0 A 10.1.= 1.1
host2.example.com = =A0 A 10.1.1.2

; URI records, can be used by= aware clients only host2 supports HTTP/2.0

_http._tcp.www.example.com URI 10 10 "http://host2.example.com/" "v=3D2.0"

OK, so you might think that looks a silly way to encode= a host name for a web server. But look what else you could do:
<= br>

We have just created a way of specifying a site level h= ttp redirect in the DNS at no extra cost.


You might argue as to whether that is a desirable approach. But it i= s clean and it is consistent. I think that shows it is the right path at th= e very least.


--
Website: http://hallambaker.com/
--089e0122ef8870ce7404d5a16c5a-- From niall.oreilly@ucd.ie Thu Feb 14 02:25:42 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9D421F8915 for ; Thu, 14 Feb 2013 02:25:42 -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=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJKyUf14NJ0M for ; Thu, 14 Feb 2013 02:25:42 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C105E21F871D for ; Thu, 14 Feb 2013 02:25:38 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so1774034wer.11 for ; Thu, 14 Feb 2013 02:25:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9DUuLg1TxIPvFzlEPgbnheS8eF/dsA8AZcfp4wRmlJM=; b=mPZw2Rgc9ZeyEtmOP+v/GrXm6u4ygOCqIN9d+Kln89L6YcbkL36oqRLJNqksie3Hea /kjBEQCow5DPj2NA0sZ008ltdp4lsvk08XuKo88iLx/5uS2qBwLlWW/bG44yYVZhbFx1 3OG4H99r5UZ29jF6i7suXA9De/kgm7gheFZ4kPWfbjPlxm2sAyAflQ8uaiIRAZaRdVA0 RNQM2qAl5uGf8tDtDEnnJOLQev0cvIQ768/ppl23hibZOeEvtBo4R1GZc7JZh3pnKDew Cezt400QBZ5M5uCJYOZjtL9uCATv3WTQDoRlUSLQFat4tFK+2soHEW8nerW71CZLlEfz g5ug== X-Received: by 10.180.75.177 with SMTP id d17mr15924009wiw.16.1360837531076; Thu, 14 Feb 2013 02:25:31 -0800 (PST) Received: from ?IPv6:2001:770:98:202:5ab0:35ff:fea8:d1fa? ([2001:770:98:202:5ab0:35ff:fea8:d1fa]) by mx.google.com with ESMTPS id n10sm51256260wia.0.2013.02.14.02.25.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 02:25:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: "Niall O'Reilly" In-Reply-To: Date: Thu, 14 Feb 2013 10:25:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <05C33394-F1F9-4DF3-A323-0D929C8897BE@ucd.ie> References: To: dnsext@ietf.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmwh4nBaDktioODX8qWnjihksC0TQT8pW5bWtwLlq4bV3wGooRbWLRqychVu7hWlwBcXJS0 Subject: Re: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:25:42 -0000 On 13 Feb 2013, at 20:31, Brian Dickson wrote: > Since the (current) wire format is URI without double quotes, this can = be extended to multiple strings by using double-quote character(s) = on-the-wire to delimit the individual strings. > "foo" "bar" <=3D> foo"bar > (And the current trick of extra-long strings being broken at every = 255th character into separate objects also works.) >=20 > Just suggesting technical tricks. Please, no! I feel this notation is sure to cause confusion because people = are used to recognizing the qouble quote as a balanced encloser and not = as a separator. I thnk this is a practical, and not just an = aesthetic point. Consider (for example) "foo" "bar" "mumble" <=3D> = foo"bar"mumble. /Niall From jim@rfc1035.com Thu Feb 14 03:00:21 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC88521F8765 for ; Thu, 14 Feb 2013 03:00:21 -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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGkXdcSfGv43 for ; Thu, 14 Feb 2013 03:00:21 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2F221F8415 for ; Thu, 14 Feb 2013 03:00:10 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id A93A1CBC41D; Thu, 14 Feb 2013 11:00:09 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jim Reid In-Reply-To: <05C33394-F1F9-4DF3-A323-0D929C8897BE@ucd.ie> Date: Thu, 14 Feb 2013 11:00:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <958315F6-C357-4D53-8BEB-3AB7FEC87323@rfc1035.com> References: <05C33394-F1F9-4DF3-A323-0D929C8897BE@ucd.ie> To: "Niall O'Reilly" X-Mailer: Apple Mail (2.1499) Cc: dnsext@ietf.org Subject: Re: [dnsext] New approach to URI scheme parameters X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 11:00:22 -0000 On 14 Feb 2013, at 10:25, "Niall O'Reilly" wrote: > I feel this notation is sure to cause confusion because people are = used > to recognizing the qouble quote as a balanced encloser and not as a > separator. I thnk this is a practical, and not just an aesthetic = point. +1 Using the doublequote character as a separator is a very bad idea. Don't = do it. From wwwrun@rfc-editor.org Thu Feb 21 09:33:47 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADAF21F8EA5; Thu, 21 Feb 2013 09:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRV1nUkzQUX4; Thu, 21 Feb 2013 09:33:47 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 02D1621F8E71; Thu, 21 Feb 2013 09:33:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CD87972F4B8; Thu, 21 Feb 2013 09:32:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130221173252.CD87972F4B8@rfc-editor.org> Date: Thu, 21 Feb 2013 09:32:52 -0800 (PST) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] RFC 6840 on Clarifications and Implementation Notes for DNS Security (DNSSEC) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:33:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6840 Title: Clarifications and Implementation Notes for DNS Security (DNSSEC) Author: S. Weiler, Ed., D. Blacka, Ed. Status: Standards Track Stream: IETF Date: February 2012 Mailbox: weiler@tislabs.com, davidb@verisign.com Pages: 21 Characters: 47283 Updates: RFC4033, RFC4034, RFC4035, RFC5155 I-D Tag: draft-ietf-dnsext-dnssec-bis-updates-20.txt URL: http://www.rfc-editor.org/rfc/rfc6840.txt This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC