Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt) Date: Wed, 3 Nov 2004 15:04:49 +0100 Organization: RIPE NCC Lines: 91 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 15:21:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: James Snell <jasnell@gmail.com> In-Reply-To: <2bcdc7c404102513103b6b1891@mail.gmail.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.172480 / -5.9 X-RIPE-Signature: 0cba5f0e5794ca24e4328f35964c33bf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello James and Andrew, I have been reading your draft. Having very little experience with the web-services architecture there are a few things that I cannot get my finger behind. The first question I have is on EPR. It is triggered by having possible redirection ( WDSL URL or an XML RR), why not simply always redirect to a WSDL document describing the service? It may make life much easier if the web service descriptions are dynamic in nature. You will not need to bother with caching and other DNS data propagation effects such as secondary DNS servers not updating in time. I do not feel comfortable with the XML RR. It has more or less the same properties as the TXT RR. It has no limitations and may cause people to put all kinds of things in the XML RR, such as internet-draft XML source (interesting idea :-) ). If there is a possibility for redirection I do not understand why the XML RR would be needed, what is the perceived benefit? I also have a more detailed questions and remarks about the RRs. 1. I think that some of the EPR RDATA elements can be split into their functional parts. For instance the PortType QNAME (confusing name for a data element in the context of DNS :-) ) could be encoded as: |length|namespace-uri|length|localpart 2. It is not clear to me why the separator "_ws" is needed in the proposed owner names of EPR records {name}._ws.{domain}. Both client and server will know which part of the name is intended to be the domain part and which part will be the name part. Dropping _ws could introduce an ambiguity (If there exists both a "inquire.uddi" and a "inquire" service and the "inquire.uddi" service has been implemented for the "example.com" domain and the "inquire" service has been implemented for the "uddi.example.com" domain.) But that ambiguity one could solve by adding a simple counter in the RDATA that tells us at which label the split between name and domain occurs. The DNSSIG RR uses a similar mechanism to indicate to indicate which part of a domain name has been synthesized. 3. Section 2.3.1. "DNS implementations MUST send the XML data using the encoding specified by the encoding byte flag". DNS implementations will send binary RDATA, they will never look at the content of the RDATA before putting information on the wire. The encoding flag can only be used as an indicator to the client interpreting the RDATA on what the binary RDATA is representing. Most of the MUSTs in this paragraphs are not enforcable and probably should be SHOULDs. (most of them relate to language that enforces implementers to strip the XML cruft before putting it into the RDATA). 4. Editing nit: most of your example RRs span multiple lines, you should use brackets to indicate this mystock._ws.example.com XML 0 <EndpointReference ( xmlns="..." .... </EndpointReference> ) Olaf Kolkman namedropper (no hats) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Wildcard Clarify 4 Date: Wed, 3 Nov 2004 16:39:55 +0100 Organization: RIPE NCC Lines: 850 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 16:58:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.500000 / -1.0 X-RIPE-Signature: b27956e900b50eef81638c80ab192347 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, For some reason wcard-clarify-04 did not make it into the repository. We think it is important to base discussions next week on the latest version, so here it is. (Note that on the agenda we refer to version 3, but it is version 4 that will be discussed.). --Olaf DNSEXT Co-Chair. --------- DNSEXT Working Group E. Lewis INTERNET DRAFT NeuStar Expiration Date: April 25, 2005 October 2004 Clarifying the Role of Wild Card Domains in the Domain Name System draft-ietf-dnsext-wcard-clarify-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and not to significantly alter the spirit or intent of that definition. 1 Introduction In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis of answers from special records called wildcards. The original definitions are incomplete. This document clarifies and describes the wildcard synthesis by adding to the discussion and making limited modifications. Modifications are made only where necessary to close inconsistencies that have led to interoperability issues. 1.1 Motivation Over time many implementations have diverged in different ways from the original definition, or at from least what had been intended. Although there is clearly a need to clarify the original documents in light of this, the impetus for this document lay in the engineering of the DNS security extensions [RFC TBD]. With an unclear definition of wildcards the design of authenticated denial became entangled. Although this document is motivated by DNSSEC and the need to have a separate document passed for the sake of DNSSEC, other motivations have arisen. The renewed understanding of wildcards gained is worthy of being documented. 1.2 The Original Definition This document is intended to make just one change, based on implementation experience, and to remain as close to the original document as possible. To reinforce this, relevant sections of RFC 1034 are repeated verbatim to help compare the old and new text. There are a few passages which are changed. This may seem to contradict the goal of not changing the original specification, but the changes herein are required because of inconsistencies with the wording in RFC 1034. The beginning of the discussion ought to start with the definition of the term "wildcard" as it appears in RFC 1034, section 4.3.3. # In the previous algorithm, special treatment was given to RRs with owner # names starting with the label "*". Such RRs are called wildcards. # Wildcard RRs can be thought of as instructions for synthesizing RRs. # When the appropriate conditions are met, the name server creates RRs # with an owner name equal to the query name and contents taken from the # wildcard RRs. This passage appears after the algorithm in which they are used is presented. The terminology is not consistent, the word "wildcard" is clearly defined to be a resource record. Wildcard has also been used to refer to domain names whose first (i.e., left most or least significant) label consists of an asterisk. 1.3 The Clarification The clarification effort can be divided into three sections: o The introduction of new terminology for clarity of the discussion o Changes to the wording of passages of RFC 1034 prompted by discoveries of conflicting concepts o Descriptions of special resource record types in the context of wildcards. 1.3.1 New Terms The term "wildcard" has become so overloaded it is virtually useless as a description. A few new terms will be introduced to be more descriptive. The new terms that will be introduced are: Asterisk Label - a label consisting of an asterisk ("*") and no other characters. Wild Card Domain Name - a domain name whose least significant label (first when reading left to right) is an asterisk label. Other labels might also be asterisk labels. Source of Synthesis - a wild card domain name when it is consulted in the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm. Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which the last match was possible in step 3, part c. This is the longest sequence of exactly matching labels from the root downward in both the query name (QNAME) and in the zone being examined. Label Match - two labels are equivalent if the label type and label length are both the same and if the labels are case-independent equivalent strings. Pattern matching is not involved. These terms will be more fully described as needed later. These terms will be used to describe a few changes to the words in RFC 1034. A summary of the changes appear next and will be fully covered in later sections. Note that labels other than the asterisk label which contain asterisks have no special significance or terminology in this document; thus the fact that a domain names starts with an asterisk is also of no special significance (and has no special terminology) unless its first label is the asterisk label, e.g., "*foo.example." has no special significance). 1.3.2 Changed Text The definition of "existence" is changed, superficially, to exclude empty domains that have no subdomains with resource records. This change will not be apparent to implementations; it is needed to make descriptions more concise. In RFC 1034, there is text that seems to prohibit having two asterisk labels in a wild card domain name. There is no further discussion, no prescribed error handling, nor enforcement described. With this document implementations will have to account for such a name's use. The actions when a source of synthesis owns a CNAME RR are changed to mirror the actions if an exact match name owns a CNAME RR. This is an addition to the words in RFC 1034, section 4.3.2, step 3, part c. 1.3.3 Considerations with Special Types This clarification will describe in some detail the semantics of wildcard CNAME RRSets, wildcard NS RRSets, wildcard SOA RRSets, wildcard DNAME RRSets [RFC 2672], and empty non-terminal wildcards. Understanding these types in the context of wildcards has been clouded because these types incur special processing if they are the result of an exact match. By the definition in RFC 1034, there can be no empty non-terminal "wildcards" ("RRs are called wildcards"). However, in the algorithm, it is possible that an empty non-terminal is sought as the potential owner of a "wildcard." This is one example of why the ordering of the discussion in RFC 1034 is confusing. 1.4 Standards Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in the document entitled "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] Quotations of RFC 1034 (as has already been done once above) are denoted by a '#' in the leftmost column. 2 "Wildcard" The context of the wildcard concept involves the algorithm by which a name server prepares a response (in RFC 1034's section 4.3.2) and the way in which a resource record (set) is identified as being a source of synthetic data (section 4.3.3). Tackling the latter first, there are two objectives in defining a means to identify a resource record set as a source of synthesis. First, to simplify implementations, one objective is to encode synthesis rules into the domain tree, i.e., avoiding a special data store for synthesis is desirable. The second objective impacts interoperability, that is a master server of one implementation has to be able to send the synthesis instructions to the slaves. Although there are alternatives to the use of zone transfers via port 53, a truly interoperable record synthesis approach has to be able to insert the synthesis instructions into a zone transfer. The objectives in describing the synthesis of records in the context of the name server algorithm include knowing when to employ the process of synthesis and how the synthesis is carried out. 2.1 Identifying a wildcard To provide a more accurate description of "wildcards", the definition has to start with a discussion of the domain names that appear as owners. 2.1.1 Wild Card Domain Name and Asterisk Label A "wild card domain name" is defined by having its initial (i.e., left-most or least significant) label be, in binary format: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) This is "*" in presentation format. The first octet is the normal label type and length for a 1 octet long label, the second octet is the ASCII representation [RFC 20] for the '*' character. In RFC 1034, ASCII encoding is assumed to be the character encoding. A descriptive name of a label equaling that value is an "asterisk label." RFC 1034's definition of wildcard would be "a resource record owned by a wild card domain name." This is mentioned to help maintain some orientation between this clarification and RFC 1034. Keep in mind, that in "Clarifications to the DNS Specification" [RFC 2181] the name of the basic unit of DNS data became the resource record set (RRSet) and not the resource record. 2.1.2 Variations on Wild Card Domain Names Labels other than the asterisk label which contain the ASCII representation of the asterisk (0x2a) have no significance for the purposes of this document. RFC 1034 and RFC 1035 do not explicitly mention the case in which a domain name might be something like "the*.example." The interpretation is that this domain name in a zone would only match queries for "the*.example." and not have any other role. An asterisk ('*') occurring other than as the sole character in a label is simply a character forming part of the label and has no special meaning. This is not an asterisk label, simply a label an asterisk in it. The same is true for "**.example." and "*the.example." The interpretation of a wild card domain specification which is not a leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example., is not discussed, not barred. In wanting to minimize changes from the original specification, such names are permitted. Although "sub.*.example." is not a wild card domain name, "*.example." is. RRSets used to synthesize records can be owned by a wild card domain name that has subdomains. 2.1.3 Non-terminal Wild Card Domain Names In section 4.3.3, the following is stated: # .......................... The owner name of the wildcard RRs is of # the form "*.<anydomain>", where <anydomain> is any domain name. # <anydomain> should not contain other * labels...................... This covers names like "*.foo.*.example." The pre-RFC2119 wording uses "should not" which has an ambiguous meaning. The specification does not proscribe actions upon seeing such a name, such as whether or not a zone containing the name should fail to be served. What if a dynamic update (RFC2136) requested to add the name to the zone? The failure semantics are not defined. The recommendation is that implementations ought to anticipate the appearance of such names but generally discourage their use in operations. No standards statement, such as "MUST NOT" nor "SHOULD NOT" is made here. The interpretation of this is, when seeking a wild card domain name for the purposes of record synthesis, an implementation need not to check the domain name for subdomains. It is possible that a wild card domain name is an empty non-terminal. (See the upcoming sections on empty non-terminals.) In this case, the lookup will terminate as would any empty non-terminal match. 2.2 Existence Rules The notion that a domain name 'exists' arises numerous times in discussions about the wildcard concept. RFC 1034 raises the issue of existence in a number of places, usually in reference to non-existence and in reference to processing involving wildcards. RFC 1034 contains algorithms that describe how domain names impact the preparation of an answer and does define wildcards as a means of synthesizing answers. Because of this a discussion on wildcards needs to cover a definition of existence. To help clarify the topic of wild cards, a positive definition of existence is needed. Complicating matters, though, is the realization that existence is relative. To an authoritative server, a domain name exists if the domain name plays a role following the algorithms of preparing a response. To a resolver, a domain name exists if there is any data available corresponding to the name. The difference between the two is the synthesis of records according to a wildcard. For the purposes of this document, the point of view of an authoritative server is more interesting. A domain name is said to exist if it plays a role in the execution of the algorithms in RFC 1034. 2.2.1. An Example To illustrate what is meant by existence consider this complete zone: $ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "this is a wild card" *.example. 3600 MX 10 host1.example. host1.example. 3600 A 192.0.4.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net. A look at the domain names in a tree structure is helpful: | -------------example------------ / / \ \ / / \ \ / / \ \ * host1 host2 subdel | | | | _tcp _tcp | | | | _ssh _ssh The following queries would be synthesized from one of the wildcards: QNAME=host3.example. QTYPE=MX, QCLASS=IN the answer will be a "host3.example. IN MX ..." QNAME=host3.example. QTYPE=A, QCLASS=IN the answer will reflect "no error, but no data" because there is no A RR set at '*.example.' QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN the answer will be "foo.bar.example. IN TXT ..." because bar.example. does not exist, but the wildcard does. The following queries would not be synthesized from any of the wildcards: QNAME=host1.example., QTYPE=MX, QCLASS=IN because host1.example. exists QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN because *.example. exists QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN because _tcp.host1.example. exists (without data) QNAME=host.subdel.example., QTYPE=A, QCLASS=IN because subdel.example. exists (and is a zone cut) To the server, all of the domains in the tree exist. The resolver will get answers to some names off the tree, thanks to synthesis. 2.2.2 Empty Non-terminals Empty non-terminals are domain names that own no resource records but have subdomains that do. This is defined in section 3.1 of RFC 1034: # The domain name space is a tree structure. Each node and leaf on the # tree corresponds to a resource set (which may be empty). The domain # system makes no distinctions between the uses of the interior nodes and # leaves, and this memo uses the term "node" to refer to both. The parenthesized "which may be empty" specifies that empty non- terminals are explicitly recognized. According to the definition of existence in this document, empty non-terminals do exist at the server. Pedantically reading the above paragraph can lead to an interpretation that all possible domains exist - up to the suggested limit of 255 octets for a domain name [RFC 1035]. For example, www.example. may have an A RR, and as far as is practically concerned, is a leaf of the domain tree. But the definition can be taken to mean that sub.www.example. also exists, albeit with no data. By extension, all possible domains exist, from the root on down. As RFC 1034 also defines "an authoritative name error indicating that the name does not exist" in section 4.3.1, this is not the intent of the original document. 2.2.3 Yet Another Definition of Existence RFC1034's wording is clarified by the following paragraph: A node is considered to have an impact on the algorithms of 4.3.2 if it is a leaf node with any resource sets or an interior node (with or without a resource set) that has a subdomain that is a leaf node with a resource set. A QNAME and QCLASS matching an existing node never results in a response code of authoritative name error (RCODE==3). The terminology in the above paragraph is chosen to remain as close to that in the original document. The term "with" is a alternate form for "owning" in this case, hence "a leaf node owning resources sets, or an interior node, owning or not owning any resource set, that has a leaf node owning a resource set as a subdomain," is the proper interpretation of the middle sentence. The phrase "resource set" appears in the original text of RFC 1034, this would now be replaced by "RRSet." As an aside, an "authoritative name error", response code (RCODE) 3, has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned to such an error by at least one implementation of DNS. Summarizing the discussion on existence in non-RFC1034 words: An authoritative server is to treat a domain name as existing during the execution of the algorithms in RFC 1034 when the domain name conforms to the following definition. A domain name is defined to exist if the domain name is on the domain tree and either owns data or has a subdomain that exists. Note that at a zone boundary, the domain name owns data, including the NS RR set. At the delegating server, the NS RR set is not authoritative, but that is of no consequence here. The domain name owns data, therefore, it exists. 2.3 When does a Wild Card Domain Name not own a wildcard (record) When a wild card domain name appears in a message's query section, no special processing occurs. An asterisk label in a query name only (label) matches an asterisk label in the existing zone tree when the 4.3.2 algorithm is being followed. When a wild card domain name appears in the resource data of a record, no special processing occurs. An asterisk label in that context literally means just an asterisk. 3. Impact of a Wild Card Domain On a Response The description of how wild cards impact response generation is in RFC 1034, section 4.3.2. That passage contains the algorithm followed by a server in constructing a response. Within that algorithm, step 3, part 'c' defines the behavior of the wild card. The algorithm is directly quoted in lines that begin with a '#' sign. Commentary is interleaved. There is a documentation issue deserving some explanation. The algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo code, i.e., its steps are not intended to be followed in strict order. The "algorithm" is a suggestion. As such, in step 3, parts a, b, and c, do not have to be implemented in that order. Another issue needing explanation is that RFC 1034 is a full standard. There is another RFC, RFC 2672, which makes, or proposes an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME RR. RFC 2672 is a proposed standard. The dilemma in writing these clarifications is knowing which document is the one being clarified. Fortunately, the difference between RFC 1034 and RFC 2672 is not significant with respect to wild card synthesis, so this document will continue to state that it is clarifying RFC 1034. If RFC 2672 progresses along the standards track, it will need to refer to modifying RFC 1034's algorithm as amended here. 3.1 Step 2 Step 2 of the RFC 1034's section 4.3.2 reads: # 2. Search the available zones for the zone which is the nearest # ancestor to QNAME. If such a zone is found, go to step 3, # otherwise step 4. In this step, the most appropriate zone for the response is chosen. The significance of this step is that it means all of Step 3 is being performed within one zone. This has significance when considering whether or not an SOA RR can be ever be used for synthesis. If an implementation were to attempt to synthesize zones, this would be the step to do this. Note though that each name server listed in the NS RRSet for the synthesized zone would have to coherently synthesize the zone. 3.2 Step 3 Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. But the beginning of the Step is important and needs explanation. # 3. Start matching down, label by label, in the zone. The # matching process can terminate several ways: The word 'matching' refers to label matching. The concept is based in the view of the zone as the tree of existing names. The query name is considered to be an ordered sequence of labels - as if the name were a path from the root to the owner of the desired data. (Which it is.) The process of label matching a query name ends in exactly one of three choices, the parts 'a', 'b', and 'c'. Once one of the parts is chosen, the other parts are not considered. (E.g., do not execute part 'c' and then change the execution path to finish in part 'b'.) The process of label matching is also done independent of the Query Type. Parts 'a' and 'b' are not an issue for this clarification as they do not relate to record synthesis. Part 'a' generally covers a situation in which all of the labels in the query name have a (label) match in the tree. Part 'b' generally covers a situation in which any label in the query name (label) matches a tree label and the tree label has a NS RRSet. 3.3 Part 'c' The context of part 'c' is that the process of label matching the labels of the query name has resulted in a situation in which there is no corresponding label in the tree. It is as if the lookup has "fallen off the tree." # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if a # the "*" label exists. To help describe the process of looking 'to see if a [sic] the "*" label exists' a term has been coined to describe the last label matched. The term is "closest encloser." 3.3.1 Closest Encloser and the Source of Synthesis The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward). Each match is a "label match" and the order of the labels is the same. The closest encloser is, by definition, an existing name in the zone. The closest encloser might be an empty non-terminal or even be a wild card domain name itself. In no circumstances is the closest encloser the used to synthesize records for the current query. The source of synthesis is defined in the context of a query process as that wild card domain name immediately descending from the closest encloser, provided that this wild card domain name exists. "Immediately descending" means that the source of synthesis has a name of the form <asterisk label>.<closest encloser>. A source of synthesis does not guarantee having a RRSet to use for synthesis. The source of synthesis could be an empty non-terminal. If the source of synthesis does not exist (not on the domain tree), there will be no wildcard synthesis. There is no search for an alternate. The important concept is that for any given lookup process, there is at most one place at which wildcard synthetic records can be obtained. If the source of synthesis does not exist, the lookup terminates, the lookup does not look for other wildcard records. Other terms have been coined on the mailing list in the past. E.g., it has been said that existing names block the application of wildcard records. This is still an appropriate viewpoint, but replacing this notion with the closest encloser and source of synthesis terminology depicts the wildcard process is more clearly. 3.3.2 Closest Encloser and Source of Synthesis Examples To illustrate, using the example zone in section 2.2.1 of this document, the following chart shows QNAMEs and the closest enclosers. QNAME Closest Encloser Source of Synthesis host3.example. example. *.example. _telnet._tcp.host1.example. _tcp.host1.example. no source _telnet._tcp.host2.example. host2.example. no source _telnet._tcp.host3.example. example. *.example. _chat._udp.host3.example. example. *.example. 3.3.3 Non-existent Source of Synthesis In RFC 1034: # If the "*" label does not exist, check whether the name # we are looking for is the original QNAME in the query # or a name we have followed due to a CNAME. If the name # is original, set an authoritative name error in the # response and exit. Otherwise just exit. The above passage is clear, evidenced by the lack of discussion and mis-implementation of it over the years. It is included for completeness only. (No attempt is made to re-interpret it lest a mistake in editing leads to confusion.) 3.3.4 Type Matching RFC 1034 concludes part 'c' with this: # If the "*" label does exist, match RRs at that node # against QTYPE. If any match, copy them into the answer # section, but set the owner of the RR to be QNAME, and # not the node with the "*" label. Go to step 6. This final paragraph covers the role of the QTYPE in the lookup process. Based on implementation feedback and similarities between step 'a' and step 'c' a change to this passage a change has been made. The change is to add the following text: If the data at the source of synthesis is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response changing the owner name to the QNAME, change QNAME to the canonical name in the CNAME RR, and go back to step 1. This is essentially the same text in step a covering the processing of CNAME RRSets. 4. Considerations with Special Types Five types of RRSets owned by a wild card domain name have caused confusion. Four explicit types causing confusion are SOA, NS, CNAME, DNAME, and the fifth type - "none." 4.1. SOA RRSet at a Wild Card Domain Name A wild card domain name owning an SOA RRSet means that the domain is at the root of the zone (apex). The domain can not be a source of synthesis because that is, by definition, a descendent node (of the closest encloser) and a zone apex is at the top of the zone. Although a wild card domain name owning an SOA RRSet can never be a source of synthesis, there is no reason to forbid the ownership of an SOA RRSet. E.g., if *.example. has an SOA record, then only a query like QNAME=*.example., QTYPE=A, QCLASS=IN would see it. A query like QNAME=foo.example., QTYPE=A, QCLASS=IN would not see it - a different zone would have been picked in Step 2. A QNAME of www.*.example. would result in a query referencing the *.example zone. 4.2. NS RRSet at a Wild Card Domain Name The semantics of a wild card domain name's ownership of a NS RRSet has been unclear. Looking through RFC 1034, the recommendation is to have the NS RRSet act the same a any non-special type, e.g., like an A RRSet. If the NS RRSet in question is at the top of the zone, i.e., the name also owns an SOA RRSet, the QNAME equals the zone name. This would trigger part 'a' of Step 3. In any other case, the wild card domain name owned NS RRSet would be the only RRSet (prior to changes instituted by DNSSEC) at the node by DNS rules. If the QNAME equals the wild card domain name or is a subdomain of it, then the node would be considered in part 'b' of Step 3. [should dnssec be left out of this?] Note that there is no synthesis of records in the authority section because part 'b' does not specify synthesis. The referral returned would have the wild card domain name in the authority section unchanged. If the QNAME is not the same as the wild card domain name nor a subdomain of it, then part 'c' of Step 3 has been triggered. Once part 'c' is entered, there is no reverting to part 'b' - i.e., once an NS RRSet is synthesized it does not mean that the server has to consider the name delegated away. I.e., the server is not synthesizing a record (the NS RRSet) that means the server does not have the right to synthesize. (Only an authoritative server can perform synthesis. By synthesizing an NS RRSet, it appears that the authority for the name has been delegated to another authority.) In summation, an NS RRSet at a wild card domain name will not result in the generation of referral messages for non-existent domains. 4.3. CNAME RRSet at a Wild Card Domain Name The issue of a CNAME RRSet owned by wild card domain names has prompted a suggested change to the last paragraph of step 3c of the algorithm in 4.3.2. The changed text appears in section 3.3.4 of this document. 4.4. DNAME RRSet at a Wild Card Domain Name The specification of the DNAME RR, which is at the proposed level of standardization, is not as mature as the full standard in RFC 1034. Because of this, or the reason for this is, there appears to be a a number of issues with that definition and it's rewrite of the algorithm in 4.3.2. For the time being, when it comes to wild card processing issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME at a wild card domain name is effectively the same as a CNAME at a wild card domain name. 4.5 Empty Non-terminal Wild Card Domain Name If a source of synthesis is an empty non-terminal, then the response will be one of no error in the return code and no RRSet in the answer section. 5. Security Considerations This document is refining the specifications to make it more likely that security can be added to DNS. No functional additions are being made, just refining what is considered proper to allow the DNS, security of the DNS, and extending the DNS to be more predictable. 6. References Normative References [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, Nov-01-1987 [RFC 1035] Domain Names - Implementation and Specification, P.V Mockapetris, Nov-01-1987 [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S Bradner, March 1997 [RFC 2181] Clarifications to the DNS Specification, R. Elz and R. Bush, July 1997. Informative References [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 7. Others Contributing to This Document Others who have been editors of this document: Bob Halley. Others who have directly caused text to appear in the document: Alex Bligh, Robert Elz, Paul Vixie and Olaf Kolkman. Many others have indirect influences on the content. 8. Editor Name: Edward Lewis Affiliation: NeuStar Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US Phone: +1-571-434-5468 Email: Ed.Lewis@neustar.biz Comments on this document can be sent to the editor or the mailing list for the DNSEXT WG, namedroppers@ops.ietf.org. 9. Trailing Boilerplate Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expiration This document expires on or about 25 April 2005. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: James Snell <jasnell@gmail.com> Subject: Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt) Date: Wed, 3 Nov 2004 08:13:14 -0800 Lines: 159 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> <20041103150449.2285e598.olaf@ripe.net> Reply-To: James Snell <jasnell@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 17:24:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=c4W/I/WlhjCJZm8EfkvhBvHqE63TCnGqbOg5SYW5HAo5YDGbPkloPQLGduab85VClj9suJ1GEWhtCUSSq6nBtoIGZbGfR4Xo4XHFb0akNRgUvrmhO0wYWcq1riwH06WYvuCHaKftiScO+k47jfyCDqhJDvIw2FTYcF7cXXTRPBY= To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20041103150449.2285e598.olaf@ripe.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello Olaf, Thanks for taking a look at the spec. Comments below. On Wed, 3 Nov 2004 15:04:49 +0100, Olaf M. Kolkman <olaf@ripe.net> wrote: > > > Hello James and Andrew, > > I have been reading your draft. Having very little experience with the > web-services architecture there are a few things that I cannot get my > finger behind. > > The first question I have is on EPR. It is triggered by having > possible redirection ( WDSL URL or an XML RR), why not simply always > redirect to a WSDL document describing the service? It may make life > much easier if the web service descriptions are dynamic in nature. You > will not need to bother with caching and other DNS data propagation > effects such as secondary DNS servers not updating in time. > At the most basic level, a Web service client needs to know three pieces of information in order to contact with a service endpoint: a) The URL of the service, b) the protocol binding to use (HTTP, etc), and c) the QName of the WSDL defined portType implemented by the service. The portType tells clients what message exchanges the service is capable of supporting. Some portType QNames will be well known, others will not. In the case that a portType is well known, a redirection to a WSDL document is entirely optional and is only needed if additional policy and binding information is required to enable the interaction. Further, we are specifically targeting DNS-EPD towards use with relatively static infrastructure level Web services whose descriptions remain fairly stable over time. More dynamic business level services are better served by high level discovery mechanisms such as UDDI, or possibly LDAP or SLP. For example, if a company deploys UDDI services within their Intranet environment to support some business critical processes, the WSDL description of that service is going to remain static over time. > I do not feel comfortable with the XML RR. It has more or less the > same properties as the TXT RR. It has no limitations and may cause > people to put all kinds of things in the XML RR, such as > internet-draft XML source (interesting idea :-) ). > :-) I quite expected folks to be uncomfortable with this, it will definitely be something that we need to have further discussion about. I will prepare a separate note with specific discussion about the XML RR and why it is needed and post that a bit later today. > If there is a possibility for redirection I do not understand why the > XML RR would be needed, what is the perceived benefit? > > I also have a more detailed questions and remarks about the RRs. > > 1. I think that some of the EPR RDATA elements can be split into > their functional parts. For instance the PortType QNAME (confusing > name for a data element in the context of DNS :-) ) could be > encoded as: > > |length|namespace-uri|length|localpart > Yeah, I thought of this after rereading the published draft and already had it marked in my notes as a potential change. This encoding would be more natural from a DNS standpoint and would save a byte of information. The original {uri}localname syntax was selected mostly as a default because it is the syntax used by the standard Java implementation of the QName datatype. (No language bias here ;-) .....). I'll make the change. > 2. It is not clear to me why the separator "_ws" is needed in the > proposed owner names of EPR records {name}._ws.{domain}. Both > client and server will know which part of the name is intended to > be the domain part and which part will be the name part. > > Dropping _ws could introduce an ambiguity (If there exists both a > "inquire.uddi" and a "inquire" service and the "inquire.uddi" > service has been implemented for the "example.com" domain and the > "inquire" service has been implemented for the "uddi.example.com" > domain.) But that ambiguity one could solve by adding a simple > counter in the RDATA that tells us at which label the split between > name and domain occurs. The DNSSIG RR uses a similar mechanism to > indicate to indicate which part of a domain name has been > synthesized. > The _ws separater was selected specifically to allow DNS-EPD records to be segregated and organized by distinct, unambiguous domains. We expect various name fragments to become somewhat well known in the industry, such as inquire.uddi._ws and publish.uddi._ws, in much the same way www has become ubiquitous. A service with the label inquire._ws in the domain uddi.example.com may be significantly different than a service with the label inquire.uddi._ws in the domain example.com. Exactly as you point out, elimating the _ws tag would make this too ambiguous. Another advantage of the _ws tag is that it allows DNS-EPD records to be split out completely and delegated as a set to a different DNS server so that they may be managed separately. In some of our use case models, for instance, Dynamic DNS Update is used to update EPR resource records. If I understand current DNS management best practices correctly, it is ideal is isolate such records to a dedicated DNS server that separates them from more mission critical static records. The _ws label allows us to delegate all DNS-EPD records as a whole. Now, I'll be the first to admit that I am not a DNS management expert and may be completely off base here so if I'm wrong about this, please correct me, but be gentle ;-) ;-) > 3. Section 2.3.1. > > "DNS implementations MUST send the XML data using the encoding > specified by the encoding byte flag". > > DNS implementations will send binary RDATA, they will never look at > the content of the RDATA before putting information on the > wire. The encoding flag can only be used as an indicator to the > client interpreting the RDATA on what the binary RDATA is > representing. > > Most of the MUSTs in this paragraphs are not enforcable and > probably should be SHOULDs. (most of them relate to language that > enforces implementers to strip the XML cruft before putting it into the > RDATA). Ok, I had suspected that this might be a problem. I will deal with this in my separate email focusing specifically on the XML resource record. > > 4. Editing nit: most of your example RRs span multiple lines, you > should use brackets to indicate this > > mystock._ws.example.com XML 0 <EndpointReference ( > xmlns="..." > .... > </EndpointReference> ) > Thanks, I'll make the change. > Olaf Kolkman > > namedropper (no hats) > -- - James Snell IBM, Emerging Technologies jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Wed, 03 Nov 2004 16:21:54 +0000 Lines: 60 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 17:36:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0410291610461.25617@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > On Fri, 29 Oct 2004, Ben Laurie wrote: > > >>If opt-in is dropped, then (from memory), the only remaining point >>is whether hashing is done per-label or over the whole name. > > > In San Diego, I did presentation comparing the two NSEC++ proposals, > but I don't think a summary ever made it to the list (sorry about > that). The slides are in the meeting proceedings: > > http://www.ietf.org/proceedings/04aug/slides/dnsext-7.pdf > > To summarize, in addition to the choice of whether hashing is > per-label or not [1], the two proposals had three "options": opt-in, > allowing hash iterations, and defining a null hash function. I think > we can pick and choose among these, and I think both the iteration > option and the null hash option are pretty trivial, but I don't recall > us making any decisions about them. > > In my presentation, I also faulted both proposals for not describing > how to change hash functions or salts (or number of iterations) I didn't understand this criticism at the time, and I still don't. > and > for not going into enough detail about wildcard processing. Both of > those need to be addressed. I also worried about hash collisions, > though people keep trying to convince me that the probabilities of a > collision can be made vanishingly small. I'd rather see a mechanism > for rolling (or allowing for coexistence of multiple) hashs and/or > salts, but I'm willing to drop the collision concern. The current draft of NSEC2 does allow for coexistence, since the salt and iterations are included in each record. I can't remember if that is a change. > [1] The choice of whether to do per-label or whole-name hashing could > require the introduction of an EXIST RR and other changes to wildcard > processing rules. Each choice also reveals different information > about the zone: whole-name hashing (NSEC2) exposes the names of empty > non-terminals (via the EXIST RR); per-label hashing (DNSNR/NSEC3) > exposes the structure of the zone but not the names. Good point. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Wed, 3 Nov 2004 22:40:03 -0500 (EST) Lines: 42 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 04:50:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418905A2.1050107@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Nov 2004, Ben Laurie wrote: > > In my presentation, I also faulted both proposals for not describing > > how to change hash functions or salts (or number of iterations) > > I didn't understand this criticism at the time, and I still don't. ... > > .... I'd rather see a mechanism > > for rolling (or allowing for coexistence of multiple) hashs and/or > > salts .... > > The current draft of NSEC2 does allow for coexistence, since the salt > and iterations are included in each record. I can't remember if that is > a change. I'm talking about the same thing in these two sentences. The proposals need to describe what is required to change salt/hash function/iterations, even if that is expected to be a rare or disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) occurence. Is that clearer? Allowing for coexistence makes it much easier, assuming coexistence works. DNSNR section 2.1.3 specifically excluded coexistence of multiple salts and implicitly excluded multiple hashes: "The Salt field value must be the same for every DNSNR generated in the zone." I can't find a current NSEC2 draft (was it ever in the i-d repository?), but I don't think it specifically said "yes, you may have multiple salts, etc.", nor did it discuss why that would always work. A previous version had salt and hash functions as zone properties (in the NSECINFO RR). The draft I have (-01, May '04) still mentions NSECINFO in section 4. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 14:37:59 +0000 Lines: 87 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 15:50:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411032227130.622@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > On Wed, 3 Nov 2004, Ben Laurie wrote: > > >>>In my presentation, I also faulted both proposals for not describing >>>how to change hash functions or salts (or number of iterations) >> >>I didn't understand this criticism at the time, and I still don't. > > ... > >>>.... I'd rather see a mechanism >>>for rolling (or allowing for coexistence of multiple) hashs and/or >>>salts .... >> >>The current draft of NSEC2 does allow for coexistence, since the salt >>and iterations are included in each record. I can't remember if that is >>a change. > > > I'm talking about the same thing in these two sentences. The > proposals need to describe what is required to change salt/hash > function/iterations, even if that is expected to be a rare or > disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) > occurence. Is that clearer? OK, I understand what you are saying, but not why you are saying it. If you want to change them, you just change them. > Allowing for coexistence makes it much easier, assuming coexistence > works. DNSNR section 2.1.3 specifically excluded coexistence of > multiple salts and implicitly excluded multiple hashes: > > "The Salt field value must be the same for every DNSNR > generated in the zone." Roy has tried to persuade me that there's some reason this _must_ be true, but I can't currently recreate the logic[1]. > I can't find a current NSEC2 draft (was it ever in the i-d > repository?), Hmm. There was some mixup with boilerplates, it may never have made it. > but I don't think it specifically said "yes, you may > have multiple salts, etc.", nor did it discuss why that would always > work. A previous version had salt and hash functions as zone > properties (in the NSECINFO RR). The draft I have (-01, May '04) > still mentions NSECINFO in section 4. You can find it here: http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-02.txt Pending rediscussing with Roy why he thought this didn't work, I don't intend to update this document as you suggest. I can't see a particular problem with it, but I'd note that allowing extra salts does not solve the collision problem. In any case, until we have reached some kind of consensus on the requirements stuff, I do not consider this to be anything more than a currently superfluous proposal. Should it become relevant, I will update it and get it properly submitted as an I-D. Cheers, Ben. [1] I may be confused. Certainly its the case that for each salt/number of iterations/hash function, one must hash every name in the zone in order to find the correct (minimal) enclosing pair. But this is not a barrier to having multiple coexisting salts (etc.). It may be that this is what I discussed with Roy. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 17:08:15 +0100 Lines: 47 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 17:22:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 40 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:wEV7cKTA2x6btH/yzgv8VH4DG6Y= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: >>>The current draft of NSEC2 does allow for coexistence, since the salt >>>and iterations are included in each record. I can't remember if that is >>>a change. >> I'm talking about the same thing in these two sentences. The >> proposals need to describe what is required to change salt/hash >> function/iterations, even if that is expected to be a rare or >> disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) >> occurence. Is that clearer? > > OK, I understand what you are saying, but not why you are saying it. If > you want to change them, you just change them. For what its worth, I also do not understand why this is needed. At one point I thought the motivation was a miss-guided attempt to mimic other security standards (i.e., signature algorithms). For such algorithms, it make sense to be support multiple hash algorithms, if one hash algorithm is broken. It might have lead people to think that multiple hash algorithms must always be supported. However, as far as I understand, the hashed-NSEC idea does not require a cryptographic strong hash function. I suspect the idea would work just as well with CRC-128. So if my understanding is correct, supporting arbitrary hash algorithms (possibly via an IANA registry) would not serve any purpose, except to decrease interoperability. The properties we need from the hash function (large enough output set to make it possible to avoid collisions by changing the salt) can be verified empirically. I invite people to think about the hashed-NSEC idea with CRC-128 as the "hash" function. I have not analyzed it, or even thought about it, in any significant detail. I may be wrong, but proving me wrong on this, would contribute to a better understanding of the hash requirements in the hashed-NSEC idea. And give the satisfaction of proving me wrong. ;) Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 17:10:35 +0100 (CET) Lines: 41 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 17:28:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418A3EC7.4050302@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Ben Laurie wrote: > > Allowing for coexistence makes it much easier, assuming coexistence > > works. DNSNR section 2.1.3 specifically excluded coexistence of > > multiple salts and implicitly excluded multiple hashes: > > > > "The Salt field value must be the same for every DNSNR > > generated in the zone." > > Roy has tried to persuade me that there's some reason this _must_ be > true, but I can't currently recreate the logic[1]. > > [1] I may be confused. Certainly its the case that for each salt/number > of iterations/hash function, one must hash every name in the zone in > order to find the correct (minimal) enclosing pair. > > But this is not a > barrier to having multiple coexisting salts (etc.). It may be that this > is what I discussed with Roy. This is exactly what we discussed. In San Diego, I was talking about salting requirements, Ben was talking about multiple salt possibilities, hence the confusion between us at the time. We agreed that multiple salts are possible, as long as the salting requirement (every name MUST be salted with each salt) was satisfied. Therefor, the relevant section in the DNSNR draft needs to be updated, since I did not anticipate having multiple salts. Multiple salts are no problem, as long as every name is salted with each salt. For every salt there will exist an NSEC-chain. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 17:49:04 +0100 Lines: 29 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 17:58:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 22 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:l10F0ua1nBiofYZvAvYyCIg2iQs= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > Multiple salts are no problem, as long as every name is salted with each > salt. For every salt there will exist an NSEC-chain. Could you expand on the justification of this requirement? In particular, what will break if one of the chains do not cover all names? Of course, there must be some applicable NSEC record for each question-tuple. But do they also have to be part of a full chain? To me, it seems the interesting property should be that clients should be able to verify the returned NSECbis record. Whether or not the NSECbis records involved form a complete chain or not does not seem to be critical to me. One situation where having partial hashed-NSEC chains may be with dynamic update. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 17:08:07 +0000 Lines: 66 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 18:36:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluactxy4uo.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>>>The current draft of NSEC2 does allow for coexistence, since the salt >>>>and iterations are included in each record. I can't remember if that is >>>>a change. >>> >>>I'm talking about the same thing in these two sentences. The >>>proposals need to describe what is required to change salt/hash >>>function/iterations, even if that is expected to be a rare or >>>disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) >>>occurence. Is that clearer? >> >>OK, I understand what you are saying, but not why you are saying it. If >>you want to change them, you just change them. > > > For what its worth, I also do not understand why this is needed. > > At one point I thought the motivation was a miss-guided attempt to > mimic other security standards (i.e., signature algorithms). For such > algorithms, it make sense to be support multiple hash algorithms, if > one hash algorithm is broken. It might have lead people to think that > multiple hash algorithms must always be supported. > > However, as far as I understand, the hashed-NSEC idea does not require > a cryptographic strong hash function. It does require preimage resistance, though, which is not a property you find much in non-cryptographic hash functions. > I suspect the idea would work > just as well with CRC-128. So if my understanding is correct, > supporting arbitrary hash algorithms (possibly via an IANA registry) > would not serve any purpose, except to decrease interoperability. The > properties we need from the hash function (large enough output set to > make it possible to avoid collisions by changing the salt) can be > verified empirically. > > I invite people to think about the hashed-NSEC idea with CRC-128 as > the "hash" function. I have not analyzed it, or even thought about > it, in any significant detail. I may be wrong, but proving me wrong > on this, would contribute to a better understanding of the hash > requirements in the hashed-NSEC idea. And give the satisfaction of > proving me wrong. ;) See above. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 18:52:21 +0100 Lines: 66 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 19:05:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 59 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:QDJtXDzcT5Uq+NNjS27EoPsVuZc= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: > It does require preimage resistance, though, which is not a property you > find much in non-cryptographic hash functions. Could you explain when the preimage resistance property required, to prevent an attack? I'm trying to work out a complete example (although simplified): Let's say a client query for ("foo.example",IN,A). Let's say CRC128(foo.example) = 42. Server realize "foo.example" doesn't exist, and return the NSECbis RR that has a range that include 42: 17 NSECbis ... 96 ... 17 RRSIG ... NSECbis ... The client verify the signature, and notices that 42 is in range, and return a "domain does not exist" error, or whatever. Since CRC-128 is not preimage resistant, an attacker can find many domain names that produce 17, 42, 96, or any other CRC-128 value, as the output. What does he gain by doing so? Perhaps the problem is when NSECbis is used to prove non-existence of types on existing names? I.e., client query for ("foo.example",IN,A) but now only TXT records exists. Again, CRC128(foo.example) = 42. The server returns: 42 NSECbis ... TXT ... 50 42 RRSIG ... NSECbis... The client verify the signature, compare CRC128(foo.example) with the owner name of the returned NSECbis RR, and realize A is not mentioned as an existing type on the list (only TXT is). Here, again the attacker can compute strings that produce 42 and 50 as output, but what does he gain? Admittedly, one could claim that there is a wart in the design. Attackers can construct query names that produce the same output as existing names. That follow immediately from the lack of preimage resistance. For example, the attacker might determine a query name "gazonk.example" such that CRC128(gazonk.example) = 42, thereby (using the last example above) implicitly proving that TXT records exists for "gazonk.example". Is this wart the only consequence you see? If so, I don't understand how this become anything but a denial-of-service attack, which the attacker can do anyway. The client presumably wouldn't ask for gazonk.example, right? If the attacker control what the client queries for, it seems the attacker might as well point the client to the attackers own zone, which the attacker control. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 13:47:02 -0500 (EST) Lines: 55 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 20:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0411032227130.622@filbert> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [I wrote the below message last night before seeing this morning's very interesting exchange. Sorry for some redundancy.] Yesterday, I said: > Allowing for coexistence [of different salts/hashes] makes [changing > salts/hashes] much easier, assuming coexistence works. I think I've been looking at "coexistence" too naively -- there's more subtlety here than I first realized, and probably more than I realize now. First, the term "coexistence" is overloaded, at least the way I was looking at it. One form of "coexistence" is "multiple hashes/salts[1] are in use in a zone at one time". Or: "some NSEC records in a zone can use hash/salt X, while some use Y". Or even: "each NSEC record may have its own unique salt". As I was imagining it, that doesn't work. Unless someone beats me to it, I can more about that in a later message. I'll keep using the word "coexistence" for this, since it's about what data is actually in the zone file. The other thing I was describing with that label was "a client, having seen (and cached) an NSEC record from a zone then seeing another NSEC using a different hash/salt will behave as expected". This doesn't necessarily mean that both hashes/salts are "in use" at the same time -- perhaps the zone entirely changed hashes/salts, but some NSECs with the old hash/salt are still cached in upstream caches. I suspect this just works, but I think we haven't thought about it enough (nor implemented enough code and tested it enough). If not, it MAY be easy to make work. In any case, "coexistence" is a bad label for this. For want of a better term, I'll call it "non-interference (of multiple hashes/salts from the same zone)", since it refers more to client behavior than zone contents. To summarize using these new labels: as NSEC2/DNSNR are defined, multiple hashes/salts MAY be non-interfering. "Coexistence" as described above, does not work. [Addendum, as of Thursday morning: since last night, Roy and Ben have talked about why. Simon's question suggests that more explanation is needed.] -- Sam [1] Throughout this message, I use "salt/hash" to mean "salt and/or hash function and/or number of hash iterations", since changing either is approximately equivalent. Changing hash functions is actually a bigger problem than changing salts or number of iterations, for reasons to be talked about later. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 13:55:36 -0500 (EST) Lines: 41 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 20:07:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu654ly2yn.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Multiple salts are no problem, as long as every name is salted with each > > salt. For every salt there will exist an NSEC-chain. > > Could you expand on the justification of this requirement? In > particular, what will break if one of the chains do not cover all > names? > > Of course, there must be some applicable NSEC record for each > question-tuple. But do they also have to be part of a full chain? I'm having a hard time coming up with simple examples, so let's see if questions are enough: If there is not a complete chain, how do you ensure that you'll have a NSEC covering each possible Q-tuple? And that no NSEC covers existing names (except during the NSEC TTL or RRSIG lifetime after adding a new name)? Or: how do you know what to put in the 'next name' field of an NSEC? For the owner name, it's easy: you use the hash of the 'natural' owner name. But you can't use the hash of the lexically next name in the 'next name' field. With NSEC++, we discard the 'natural' lexical ordering: we instead hash all of the names, sort the hashes, and insert the lexically next hash. The lexically next hash should have no relationship with the lexicaly next name. > One situation where having partial hashed-NSEC chains may be with > dynamic update. Expand on this some idea more. Are you imagining one NSEC chain of the "permanent" names and another of the updated names? If so, one chain can be used to spoof away names in the other chain. If you're imagining incomplete chains, see the questions above. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 14:07:37 -0500 (EST) Lines: 44 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 20:24:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418A3EC7.4050302@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I'm talking about the same thing in these two sentences. The > > proposals need to describe what is required to change salt/hash > > function/iterations, even if that is expected to be a rare or > > disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) > > occurence. Is that clearer? > > OK, I understand what you are saying, but not why you are saying it. If > you want to change them, you just change them. Caching and resolver state. What happens when an NSEC using one hash/salt/etc. is cached, then a different one is seen? Or what happens when one answer contains two NSECs from the same zone based on different parameters (ie. the NSEC proving no exact match and the NSEC proving no wildcard match have different parameters)? A resolver must already have logic to find and distinguish between the two NSECs. With this kind of answer, it would have to do BOTH hashes on both the exact name and wildcard name to distinguish them. Then, too, you should never see such an NSEC constructed by a cache -- if auth servers use consistent parameters throughout, it gets simpler. But if you want to allow inconsistency at the auth servers (and within one answer), resolvers need to be explicitly told what logic to use. In any case, resolvers need to be told to expect inconsistent parameters from zones, and I think some serious testing of that would be needed. If you want to allow inconsistency at the auth servers, even more testing will be needed. Or maybe I'm just being too paranoid. > In any case, until we have reached some kind of consensus on the > requirements stuff, I do not consider this to be anything more than a > currently superfluous proposal. Should it become relevant, I will update > it and get it properly submitted as an I-D. Fair enough. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST) Lines: 47 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 22:08:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: dee3@pothole.com In-Reply-To: <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 12 Oct 2004 dee3@pothole.com wrote: > Please post any comments on these two drafts. I gave brief presentations > on them at the last IETF and plan to do so again next month. If there are > no substantial comments, I will ask that they be working group Last Called > right after the upcoming meeting. I've only read parts of draft-ietf-dnsext-ecc-key-05. Here are some comments on the bits I have read: This document needs to take into account the type code roll (RFC3755). Examples: Section 1 refers to SIG, which has been largely, but not entirely, deprecated. Section 2 says "key RRs", then cites DNSSECbis-records. See RFC3755 IANA considerations, section 4.2. Be much more explicit about which of DNSKEY and/or KEY you mean here. Section 2, second paragraph: "with signatures..." is confusing. Just say RRSIGs. Also: "key validity may not be in the RR with the key...". First, just say KEY or DNSKEY. Also: I see no key validity field in this RR -- why have the equivolcal phrasing with a "may"? IANA section: Should comment on whether any algorithm numbers need to be assigned (and, if not, where they are assigned). See 3755 section 4.2. It looks like a new registry is being established. This text is likely insufficient for that task. See draft-narten-iana-considerations-rfc2434bis-01.txt Nits: Section 5 (Performance Considerations), second paragraph, third line: s/ and and/, and/ Status of this memo: "This draft is intended to be become a Proposed Standard RFC." is not allowed, per http://www.ietf.org/ietf/1id-guidelines.txt Boilerplate looks incomplete (Acceptance of section 3 of 3667 is missing). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST) Lines: 46 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 04:59:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: dee3@pothole.com In-Reply-To: <Pine.GSO.4.55.0411041546200.16737@filbert> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Samuel Weiler wrote: > Be much more explicit about which of DNSKEY and/or KEY ... Further comments after some more reflection. First, I'd like to thank Donald for his efforts to put this document (and the HMAC SHA TSIG doc) together. There are very few people with both the ability to follow the current crypto research and the willingness to bring that knowledge back to the IETF in a useful form. We should applaud Donald for his willingness to do that. I'd also like to say that I'm not particularly averse to storing random data in the DNS. That said, it's not clear to me why we're trying to store ECC keys in the DNS nor, given that uncertainty, what RR type we might want to use to store them. Of late, we've been choosing to separate data into new type codes based on the use of the data, not the content or format of the data. For cryptographic keys, in particular, we've tried to reuse key storage formats (we reused the 2536 and 3110 formats in DNSKEY and IPSECKEY), but we've allocated new RR types for different data users. See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt section 2.6 (now at RFC-Editor). Since we're not defining a SIG nor RRSIG format for ECC, it would appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and RFC3755. Who are they useful for? (Does anyone really want to store ECC keys in the DNS?) And what does that suggest about what RR type(s) they should be stored in? This all feeds into the IANA section questions I posted earlier today. Looking further ahead, I also wonder if this record format's flexibility might be dangerous. Can we imagine users of data that can't effectively use all of the different types of eliptic curve keys that can be stored in this RR? If so, we may be creating another subtyping problem. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 09:02:03 +0100 (CET) Lines: 27 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:14:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu654ly2yn.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Simon Josefsson wrote: > Roy Arends <roy@dnss.ec> writes: > > > Multiple salts are no problem, as long as every name is salted with each > > salt. For every salt there will exist an NSEC-chain. > > Could you expand on the justification of this requirement? In > particular, what will break if one of the chains do not cover all > names? Sure, you must have at least one entire NSEC-chain. A second set of NSEC's does not have to cover every name. But the second set of NSEC's has to be complete before the first set is deteriorated. Sidenote: the NSEC's from the incomplete set of names MUST NOT form a complete chain. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 08:44:58 +0000 Lines: 58 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:52:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluactxy4uo.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 04 November 2004 17:08 +0100 Simon Josefsson <jas@extundo.com> wrote: > However, as far as I understand, the hashed-NSEC idea does not require > a cryptographic strong hash function. Depends which hash property you are talking about. What you don't want is inversion (i.e. you know H(x), can you discover x?). It requires some cryptographically strong properties to prevent this (or rather make the problem computationally infeasible). > I suspect the idea would work > just as well with CRC-128. So if my understanding is correct, > supporting arbitrary hash algorithms (possibly via an IANA registry) > would not serve any purpose, except to decrease interoperability. I may be partly responsible for this confusion. I jumped on the proposal to support alternative hash algorithms for various reasons: a) When we were back discussing the possibilities of hash collisions (i.e. H(a)=H(b) where a != b), I pointed out these only happen because (most) hash functions are not guaranteed to be injective (in fact the ones we consider are guaranteed not to be injective, i.e. we know collisions will exist, they are just infinitesimally rare and don't know where they are). However, for those who are really worried about such things and don't care about enumeration, but did want to use NSEC2 for something else (opt-in being discussed at the time), they could use the identity function as a hash (i.e. H(x)=x) which clearly never collides. b) Shorter hashes may be useful for those not overly worried about enumeration who are worried about size of zone file / amount of on-wire data etc. / computational resources. For all but the latter, truncated hashes are just as good. I think (b) is the only really significant reason to support alternative hashes, though if you are doing this, you might as well support the identity hash, just as a debugging tool (may be a "reverse the order of the octets in each label" hash too). If one is truncating, one could imagine a zone signing thing which automagically sized the hash sensibly (for minimal chance of collision for incremental update but also minimizing zone file size). The interoperability concerns come down to which hashes you make mandatory to support. I would suggest if we are going this way, we chose one (long) hash, and the identity hash (as mandatory), reserve all other codes (rather than go the IANA route), and have another field which is the number of octets to truncate each hash to. I cannot see a reason to support multiple hashes for the same record. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 08:48:36 +0000 Lines: 18 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:53:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluvfclwlgq.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 04 November 2004 18:52 +0100 Simon Josefsson <jas@extundo.com> wrote: > Since CRC-128 is not preimage resistant, an attacker can find many > domain names that produce 17, 42, 96, or any other CRC-128 value, as > the output. What does he gain by doing so? If it's not preimage resistant, these can then be sifted by (for instance) only looking at ones which match /[a-zA-Z-]+/. Unless I'm missing something. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 09:51:59 +0100 (CET) Lines: 69 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:58:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluvfclwlgq.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > > It does require preimage resistance, though, which is not a property you > > find much in non-cryptographic hash functions. > > Could you explain when the preimage resistance property required, to > prevent an attack? I came to a similar question when writing the DNSNR/NSEC3 draft (section 3.2.2/3.2.3). The following analysis applies to the second-preimage resistance property. All in all my conclusion was that since the need for preimage requirement is low, truncation of hashes can be used. Ofcourse, using the exact same analysis, the use CRC-128 can be defended. Roy 3.2.2 Second Preimage Requirement Analysis A collision resistant hash function has a second-preimage resistance property. The second-preimage resistance property means that it is computationally infeasible to find another message with the same hash value as a given message, i.e, given x, to find a second-preimage X' <> X such that hash(X) = hash(X'). The probability of finding a second preimage is 1 in 2^160 for SHA-1 on average. To mount an attack using an existing DNSNR RR, an adversary needs to find a second preimage. Assuming an adversary is capable of mounting such an extreme, the actual damage is that a response message can be generated which claims that a certain QNAME (i.e. the second pre-image) does exist, while in reality QNAME does not exist (aka false positive), which will either cause a security aware resolver to re-query for the non-existent name, or to fail the initial query. Note that the adversary can't mount this attack on an existing name, solely on a name that the adversary can't choose and does not yet exist. 3.2.3 Possible Hash Value Truncation Method The previous sections outlined the low probability and low impact of a second-preimage attack. When impact and probability are low, while space in a DNS message is costly, truncation is tempting. Truncation might be considered to allow for shorter ownernames and rdata in case of labels with hash values. The author seeks comfirmation on the assumption that truncation decreases resilliance on colliding hash values though the overall security model does not significantly deteriorate. An extreme hash value truncation would be truncating to the shortest possible unique label value. Considering that hash values are presented in base32, which represents 5 bits per label character, truncation must be done on a 5 bit boundary. Though the mentioned truncation can be maximised to a certain extreme, the probability of collision increases exponentially for every truncated bit. Given the low impact of hash value collisions and limited space in DNS messages, the balance between truncation profit and collision damage may be determined by local policy (but see first paragraph where 'the author seeks'). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:22:32 +0100 Lines: 41 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 10:31:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 34 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:TGqYUxkpcSBs5BaSPkkpe7FyepQ= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> writes: > --On 04 November 2004 17:08 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> However, as far as I understand, the hashed-NSEC idea does not require >> a cryptographic strong hash function. > > Depends which hash property you are talking about. What you don't > want is inversion (i.e. you know H(x), can you discover x?). It > requires some cryptographically strong properties to prevent this > (or rather make the problem computationally infeasible). Ah, right. This should be mentioned as the primary requirement on the chosen hash. CRC-128 is fully invertible for input strings < 16 bytes, because of the linearity. However, if we assume the salt is 16 bytes (as in NSEC2), or longer, it is no longer possible to invert it. > --On 04 November 2004 18:52 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> Since CRC-128 is not preimage resistant, an attacker can find many >> domain names that produce 17, 42, 96, or any other CRC-128 value, as >> the output. What does he gain by doing so? > > If it's not preimage resistant, these can then be sifted by (for instance) > only looking at ones which match /[a-zA-Z-]+/. Unless I'm missing something. I don't understand. Are you saying that th attacker finds domain names /[a-zA-Z-]+/ that "hash" to 17, 42, or 96? That's possible. But then what does he do with does names? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:39:20 +0100 Lines: 73 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411050930150.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 10:45:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 66 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:qzYSxpjW4unWpGHmLvJNa8T5Y7w= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > On Thu, 4 Nov 2004, Simon Josefsson wrote: > >> Ben Laurie <ben@algroup.co.uk> writes: >> >> > It does require preimage resistance, though, which is not a property you >> > find much in non-cryptographic hash functions. >> >> Could you explain when the preimage resistance property required, to >> prevent an attack? > > I came to a similar question when writing the DNSNR/NSEC3 draft (section > 3.2.2/3.2.3). The following analysis applies to the second-preimage > resistance property. That was a useful section. I believe it, and similar sections on other properties (like non-invertible and preimage resistance), should go into a document based on the hashed-NSEC idea. Some specific comment: > A collision resistant hash function has a second-preimage resistance > property. If you want, you may add a reference to this excellent paper for the background: http://www.cs.ucdavis.edu/~rogaway/papers/relates.html > The probability of finding a > second preimage is 1 in 2^160 for SHA-1 on average. This is only conjectured, right? > Assuming an adversary is capable of mounting such an extreme, the > actual damage is that a response message can be generated which > claims that a certain QNAME (i.e. the second pre-image) does exist, > while in reality QNAME does not exist (aka false positive), which > will either cause a security aware resolver to re-query for the > non-existent name, or to fail the initial query. Note that the > adversary can't mount this attack on an existing name, solely on a > name that the adversary can't choose and does not yet exist. One might make it explicit that this result in a Denial-Of-Service attack. Something which is possible anyway. > 3.2.3 Possible Hash Value Truncation Method > > The previous sections outlined the low probability and low impact of > a second-preimage attack. When impact and probability are low, while > space in a DNS message is costly, truncation is tempting. Truncation > might be considered to allow for shorter ownernames and rdata in case > of labels with hash values. The author seeks comfirmation on the > assumption that truncation decreases resilliance on colliding hash > values though the overall security model does not significantly > deteriorate. For what it's worth, I cannot prove that truncation is safe, so I also encourage more investigation into truncation. In an earlier version of the NO draft, it was suggested that truncation should be done to the closest unique prefix. Obviously, that didn't work, but it took me a week to realize it. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:01:12 +0000 Lines: 44 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:06:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Thu, 4 Nov 2004, Simon Josefsson wrote: > > >>Roy Arends <roy@dnss.ec> writes: >> >> >>>Multiple salts are no problem, as long as every name is salted with each >>>salt. For every salt there will exist an NSEC-chain. >> >>Could you expand on the justification of this requirement? In >>particular, what will break if one of the chains do not cover all >>names? > > > Sure, you must have at least one entire NSEC-chain. A second set of NSEC's > does not have to cover every name. But the second set of NSEC's has to be > complete before the first set is deteriorated. > > Sidenote: the NSEC's from the incomplete set of names MUST NOT form a > complete chain. Because you can't predict the order of the hashes, although this requirement is theoretically believable, it is practically impossible to generate a partial NSEC chain without hashing all names first, in which case you may as well generate a complete one. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 11:03:00 +0100 Lines: 43 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:07:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 36 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:oR0cclODhOJHWmHfWb4+ptePcLU= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > On Thu, 4 Nov 2004, Simon Josefsson wrote: > >> Roy Arends <roy@dnss.ec> writes: >> >> > Multiple salts are no problem, as long as every name is salted with each >> > salt. For every salt there will exist an NSEC-chain. >> >> Could you expand on the justification of this requirement? In >> particular, what will break if one of the chains do not cover all >> names? > > Sure, you must have at least one entire NSEC-chain. A second set of NSEC's > does not have to cover every name. But the second set of NSEC's has to be > complete before the first set is deteriorated. > > Sidenote: the NSEC's from the incomplete set of names MUST NOT form a > complete chain. How do this statement match your earlier (quoted above)? I read your first post as suggesting that multiple salts would work, if you create a complete chain using each salt. Now you are saying the opposite? I.e., multiple salts work, but there must only be one complete chain? FWIW, I would agree with your last message. One chain with one salt is how you typically would start out, and later you can introduce new salts, and there is no requirement to produce a complete chain with the new salt. I'm not sure I understand why the new salt cannot be used to build a complete chain, though. Perhaps I misunderstood your first post, hence my question above. Thanks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:01:36 +0000 Lines: 38 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:07:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu654ly2yn.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Roy Arends <roy@dnss.ec> writes: > > >>Multiple salts are no problem, as long as every name is salted with each >>salt. For every salt there will exist an NSEC-chain. > > > Could you expand on the justification of this requirement? In > particular, what will break if one of the chains do not cover all > names? > > Of course, there must be some applicable NSEC record for each > question-tuple. But do they also have to be part of a full chain? > > To me, it seems the interesting property should be that clients should > be able to verify the returned NSECbis record. Whether or not the > NSECbis records involved form a complete chain or not does not seem to > be critical to me. > > One situation where having partial hashed-NSEC chains may be with > dynamic update. A partial chain will deny records that exist. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:03:06 +0000 Lines: 49 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:08:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluvfclwlgq.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>It does require preimage resistance, though, which is not a property you >>find much in non-cryptographic hash functions. > > > Could you explain when the preimage resistance property required, to > prevent an attack? > > I'm trying to work out a complete example (although simplified): > > Let's say a client query for ("foo.example",IN,A). Let's say > CRC128(foo.example) = 42. > > Server realize "foo.example" doesn't exist, and return the NSECbis RR > that has a range that include 42: > > 17 NSECbis ... 96 ... > 17 RRSIG ... NSECbis ... > > The client verify the signature, and notices that 42 is in range, and > return a "domain does not exist" error, or whatever. > > Since CRC-128 is not preimage resistant, an attacker can find many > domain names that produce 17, 42, 96, or any other CRC-128 value, as > the output. What does he gain by doing so? A filtered list of domains to query for existence - i.e. a very cheap brute force attack. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:04:25 +0000 Lines: 36 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <EDBA1D3C2161047C978E7937@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:08:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <EDBA1D3C2161047C978E7937@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > > > --On 04 November 2004 18:52 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> Since CRC-128 is not preimage resistant, an attacker can find many >> domain names that produce 17, 42, 96, or any other CRC-128 value, as >> the output. What does he gain by doing so? > > > If it's not preimage resistant, these can then be sifted by (for instance) > only looking at ones which match /[a-zA-Z-]+/. Unless I'm missing > something. There is no requirement to recognise the form of the name. If you can invert the hash function (even if the inverse is multi-valued) then you get a list of names that might exist that is very much smaller than the exhaustive list. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:06:21 +0000 Lines: 44 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:13:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <A558EB4247020EDB1980A8FB@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > > > --On 04 November 2004 17:08 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> However, as far as I understand, the hashed-NSEC idea does not require >> a cryptographic strong hash function. > > > Depends which hash property you are talking about. What you don't > want is inversion (i.e. you know H(x), can you discover x?). It > requires some cryptographically strong properties to prevent this > (or rather make the problem computationally infeasible). > >> I suspect the idea would work >> just as well with CRC-128. So if my understanding is correct, >> supporting arbitrary hash algorithms (possibly via an IANA registry) >> would not serve any purpose, except to decrease interoperability. > > > I may be partly responsible for this confusion. I jumped on the proposal > to support alternative hash algorithms for various reasons: > > a) When we were back discussing the possibilities of hash collisions (i.e. > H(a)=H(b) where a != b), I pointed out these only happen because (most) > hash functions are not guaranteed to be injective (in fact the ones we > consider are guaranteed not to be injective, i.e. we know collisions will > exist, they are just infinitesimally rare and don't know where they are). All fixed-length hash functions have this property (obviously). -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:20:09 +0000 Lines: 90 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <Pine.GSO.4.55.0411041343510.12330@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:30:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411041343510.12330@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > [I wrote the below message last night before seeing this morning's > very interesting exchange. Sorry for some redundancy.] > > Yesterday, I said: > > >>Allowing for coexistence [of different salts/hashes] makes [changing >>salts/hashes] much easier, assuming coexistence works. > > > I think I've been looking at "coexistence" too naively -- there's more > subtlety here than I first realized, and probably more than I realize > now. > > First, the term "coexistence" is overloaded, at least the way I was > looking at it. > > One form of "coexistence" is "multiple hashes/salts[1] are in use in a > zone at one time". Or: "some NSEC records in a zone can use hash/salt > X, while some use Y". Or even: "each NSEC record may have its own > unique salt". As I was imagining it, that doesn't work. Its clear that doesn't work in practice, though there isn't anything theoretically wrong - the issue is that finding a set of salts that covers the zone would be hard. > Unless > someone beats me to it, I can more about that in a later message. > I'll keep using the word "coexistence" for this, since it's about > what data is actually in the zone file. > > The other thing I was describing with that label was "a client, having > seen (and cached) an NSEC record from a zone then seeing another NSEC > using a different hash/salt will behave as expected". This doesn't > necessarily mean that both hashes/salts are "in use" at the same time > -- perhaps the zone entirely changed hashes/salts, but some NSECs with > the old hash/salt are still cached in upstream caches. I suspect this > just works, but I think we haven't thought about it enough (nor > implemented enough code and tested it enough). You may not have thought about it enough, but it seems to me quite obvious it works. The reason being that an NSEC record denies an interval, and that interval is defined entirely by the NSEC record alone, so the age of it is immaterial (except, of course, that new records may now exist in the interval, but that is a TTL issue, not a hashing/salting issue). > If not, it MAY be easy > to make work. In any case, "coexistence" is a bad label for this. > For want of a better term, I'll call it "non-interference (of multiple > hashes/salts from the same zone)", since it refers more to client > behavior than zone contents. > > To summarize using these new labels: as NSEC2/DNSNR are defined, > multiple hashes/salts MAY be non-interfering. "Coexistence" as > described above, does not work. [Addendum, as of Thursday morning: > since last night, Roy and Ben have talked about why. Simon's question > suggests that more explanation is needed.] Which question? > > -- Sam > > [1] Throughout this message, I use "salt/hash" to mean "salt and/or > hash function and/or number of hash iterations", since changing either > is approximately equivalent. Changing hash functions is actually a > bigger problem than changing salts or number of iterations, for > reasons to be talked about later. I don't buy this. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 11:28:35 +0100 Lines: 34 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:35:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 27 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:hWu2TJSk8nL6MCKtb8lG7XLCVTs= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: >> Since CRC-128 is not preimage resistant, an attacker can find many >> domain names that produce 17, 42, 96, or any other CRC-128 value, as >> the output. What does he gain by doing so? > > A filtered list of domains to query for existence - i.e. a very cheap > brute force attack. Ah, I understand now. However, the traditional "preimage resistance" property is how difficult it is to find ONE input that hash to a known value. Even if that is possible, it seems it could still be computationally infeasible to derivate a list of such names, containing enough entries to be useful in a dictionary or brute force attack. So preimage resistance seem to be a stronger property than what is needed to guard for this attack. Perhaps we could define "enumerated preimage resistance" to be the property applicable here. To clarify my position: Hashed-NSEC should ideally use the strongest known hash function, to be on the safe side. But considering how the hashed-NSEC idea fail given various "bad" hashes is a good exercise in understanding the assumptions. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 11:33:49 +0100 (CET) Lines: 81 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:41:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluu0s4fwa3.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Simon Josefsson wrote: > Roy Arends <roy@dnss.ec> writes: > > > On Thu, 4 Nov 2004, Simon Josefsson wrote: > > > >> Roy Arends <roy@dnss.ec> writes: > >> > >> > Multiple salts are no problem, as long as every name is salted with each > >> > salt. For every salt there will exist an NSEC-chain. > >> > >> Could you expand on the justification of this requirement? In > >> particular, what will break if one of the chains do not cover all > >> names? > > > > Sure, you must have at least one entire NSEC-chain. A second set of NSEC's > > does not have to cover every name. But the second set of NSEC's has to be > > complete before the first set is deteriorated. > > > > Sidenote: the NSEC's from the incomplete set of names MUST NOT form a > > complete chain. > > How do this statement match your earlier (quoted above)? > > I read your first post as suggesting that multiple salts would work, > if you create a complete chain using each salt. CHAIN is the keyword. My statement should have been: Multiple CHAINS are no problem, as long as every name is salted with each salt. For every salt there will exist an NSEC-chain. With NSEC chain I mean an ordered circulair linked list of optionally hashed ownernames. > Now you are saying > the opposite? I.e., multiple salts work, but there must only be one > complete chain? No. multiple salts work, but there must at least be one complete chain. > FWIW, I would agree with your last message. One chain with one salt > is how you typically would start out, and later you can introduce new > salts, and there is no requirement to produce a complete chain with > the new salt. As long as the 'old' chain is complete. > I'm not sure I understand why the new salt cannot be used to build a > complete chain, though. It can, no problem. This is what I ment: given four names (a,b,c,d) and salt X, you'd start out with 1 2 3 4 H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) This is a circular ordered list (assume H(name,salt)=name). Now we introduce salt Y for two names (b, c) but not for (a,d) We are able to create the NSEC: H(b,Y)-H(c,Y) But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) Since H(c,Y)-H(b,Y) would deny existence of d. The new salt can be used to form NSEC records, but to be able to form a _complete_chain_, all names must be included in the chain. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 12:10:29 +0100 (CET) Lines: 33 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411050930150.2709@trinitario.schlyter.se> <ilu4qk4hbxz.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 12:19:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu4qk4hbxz.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Simon Josefsson wrote: > Some specific comment: > > > A collision resistant hash function has a second-preimage resistance > > property. > > If you want, you may add a reference to this excellent paper for the > background: > > http://www.cs.ucdavis.edu/~rogaway/papers/relates.html Thanks, great paper. > > The probability of finding a > > second preimage is 1 in 2^160 for SHA-1 on average. > > This is only conjectured, right? Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas non caperet. :-) Yes, this is only conjectured. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 11:49:30 +0000 Lines: 39 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 12:55:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > This is what I ment: > > given four names (a,b,c,d) and salt X, you'd start out with > > 1 2 3 4 > H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) > > > This is a circular ordered list (assume H(name,salt)=name). > > Now we introduce salt Y for two names (b, c) but not for (a,d) > > We are able to create the NSEC: H(b,Y)-H(c,Y) > But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) > Since H(c,Y)-H(b,Y) would deny existence of d. This is incorrect, since we do not have a H(a) < H(b). That is, we don't know whether H(a) or H(d) falls between H(b) and H(c) or not. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 12:52:53 +0100 (CET) Lines: 33 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 12:58:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418B68CA.1060308@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Ben Laurie wrote: > Roy Arends wrote: > > This is what I ment: > > > > given four names (a,b,c,d) and salt X, you'd start out with > > > > 1 2 3 4 > > H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) > > > > > > This is a circular ordered list (assume H(name,salt)=name). > > > > Now we introduce salt Y for two names (b, c) but not for (a,d) > > > > We are able to create the NSEC: H(b,Y)-H(c,Y) > > But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) > > Since H(c,Y)-H(b,Y) would deny existence of d. > > This is incorrect, since we do not have a H(a) < H(b). assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. > That is, we don't know whether H(a) or H(d) falls between H(b) and H(c) > or not. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 12:07:06 +0000 Lines: 54 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 13:14:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilumzxwfv3g.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>>Since CRC-128 is not preimage resistant, an attacker can find many >>>domain names that produce 17, 42, 96, or any other CRC-128 value, as >>>the output. What does he gain by doing so? >> >>A filtered list of domains to query for existence - i.e. a very cheap >>brute force attack. > > > Ah, I understand now. > > However, the traditional "preimage resistance" property is how > difficult it is to find ONE input that hash to a known value. This is second preimage resistance, surely? > Even if > that is possible, it seems it could still be computationally > infeasible to derivate a list of such names, containing enough entries > to be useful in a dictionary or brute force attack. So preimage > resistance seem to be a stronger property than what is needed to guard > for this attack. Perhaps we could define "enumerated preimage > resistance" to be the property applicable here. We don't care whether a list is available or just a single preimage, surely, so long as the actual name hashed is in the list. > To clarify my position: Hashed-NSEC should ideally use the strongest > known hash function, to be on the safe side. But considering how the > hashed-NSEC idea fail given various "bad" hashes is a good exercise in > understanding the assumptions. Indeed. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Requirements Matrix updated Date: Fri, 05 Nov 2004 12:15:37 +0000 Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 13:21:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: DNSEXT WG <namedroppers@ops.ietf.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have updated the requirements matrix: http://www.links.org/dnssec/requirements-matrix-3.htm I have added rows for the proposals on the table which I perceive as having noticable support. Feel free to point out others. These are: NSEC2/NSEC3 with modifications that are obvious from discussion but may not be in the I-Ds yet, NSEC2/NSEC3 as above but with banning of wildcards, and synthesized NSEC records. Not surprisingly, these proposals are pretty much orthogonal (that is, the sets of requirements they do not satisfy are disjoint). I hope this is helpful. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 13:27:22 +0100 Lines: 68 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 13:41:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> X-Hashcash: 1:22:041105:ben@algroup.co.uk::7vdQC8gKgEiaWjq1:000000000000000000000000000000000000000000000JYX X-Hashcash: 1:22:041105:namedroppers@ops.ietf.org::uW8uZgHXtsVeFLZI:0000000000000000000000000000000000004H8/ In-Reply-To: <418B6CEA.1040002@algroup.co.uk> (Ben Laurie's message of "Fri, 05 Nov 2004 12:07:06 +0000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on yxa-iv X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: > Simon Josefsson wrote: >> Ben Laurie <ben@algroup.co.uk> writes: >> >>>>Since CRC-128 is not preimage resistant, an attacker can find many >>>>domain names that produce 17, 42, 96, or any other CRC-128 value, as >>>>the output. What does he gain by doing so? >>> >>> A filtered list of domains to query for existence - i.e. a very >>> cheap brute force attack. >> Ah, I understand now. >> However, the traditional "preimage resistance" property is how >> difficult it is to find ONE input that hash to a known value. > > This is second preimage resistance, surely? I think it depends on which of the hash value you are interested in. You only know the input to the hash function for H(x) = 42, in my example it was x = "foo.example", but for H(x) = 17, H(x) = 96 or any other output, you don't a priori know x. So for H(x) = 42, the x is known, so it is the second preimage resistance property that applies. But for H(x) != 42, the x is not known, so it is the preimage resistance property that applies. That is unless I have misunderstood hash function properties, somehow. There is a nice graphical explanation at the bottom of: http://www.unixwiz.net/techtips/iguide-crypto-hashes.html >> Even if >> that is possible, it seems it could still be computationally >> infeasible to derivate a list of such names, containing enough entries >> to be useful in a dictionary or brute force attack. So preimage >> resistance seem to be a stronger property than what is needed to guard >> for this attack. Perhaps we could define "enumerated preimage >> resistance" to be the property applicable here. > > We don't care whether a list is available or just a single preimage, > surely, so long as the actual name hashed is in the list. There could be many preimages, and only one of them (i.e., the original existing name that hash to the known value) give any information to the attacker. So even if an attacker is able to break the preimage resistance property, it might not help unless he can create many such preimages, and use them as input to a dictionary or brute force attack, to discover the real name that hash to that particular value. Perhaps this is just the non-invertible property, after all, with a special oracle. What I mean is: The attacker is able to invert the hash function, if she can break the (enumerated) preimage resistance and has access to a oracle that knows which names exists (i.e., online query to DNS itself). Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 13:17:02 +0000 Lines: 101 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> <iluis8kfplh.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 14:24:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluis8kfplh.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>Simon Josefsson wrote: >> >>>Ben Laurie <ben@algroup.co.uk> writes: >>> >>> >>>>>Since CRC-128 is not preimage resistant, an attacker can find many >>>>>domain names that produce 17, 42, 96, or any other CRC-128 value, as >>>>>the output. What does he gain by doing so? >>>> >>>>A filtered list of domains to query for existence - i.e. a very >>>>cheap brute force attack. >>> >>>Ah, I understand now. >>>However, the traditional "preimage resistance" property is how >>>difficult it is to find ONE input that hash to a known value. >> >>This is second preimage resistance, surely? > > I think it depends on which of the hash value you are interested in. > > You only know the input to the hash function for H(x) = 42, in my > example it was x = "foo.example", but for H(x) = 17, H(x) = 96 or any > other output, you don't a priori know x. > > So for H(x) = 42, the x is known, so it is the second preimage > resistance property that applies. > > But for H(x) != 42, the x is not known, so it is the preimage > resistance property that applies. > > That is unless I have misunderstood hash function properties, somehow. > There is a nice graphical explanation at the bottom of: > > http://www.unixwiz.net/techtips/iguide-crypto-hashes.html > > >>>Even if >>>that is possible, it seems it could still be computationally >>>infeasible to derivate a list of such names, containing enough entries >>>to be useful in a dictionary or brute force attack. So preimage >>>resistance seem to be a stronger property than what is needed to guard >>>for this attack. Perhaps we could define "enumerated preimage >>>resistance" to be the property applicable here. >> >>We don't care whether a list is available or just a single preimage, >>surely, so long as the actual name hashed is in the list. > > > There could be many preimages, and only one of them (i.e., the > original existing name that hash to the known value) give any > information to the attacker. > > So even if an attacker is able to break the preimage resistance > property, it might not help unless he can create many such preimages, > and use them as input to a dictionary or brute force attack, to > discover the real name that hash to that particular value. > > Perhaps this is just the non-invertible property, after all, with a > special oracle. What I mean is: The attacker is able to invert the > hash function, if she can break the (enumerated) preimage resistance > and has access to a oracle that knows which names exists (i.e., online > query to DNS itself). On reflection, I believe the property we are after is not a standard one for cryptographic hashes, which is probably why we're arguing about which of the standard properties it is! As you say, what we want is that the hash should not be invertible - or, more strictly, that we shouldn't be able to produce a list of inputs amongst which the actual input is guaranteed (or even likely) to be. Of course, any hash with that does not have this property will not be preimage or second preimage resistant (the latter if the list is always longer than one element), but a hash which was OK for our use might not be cryptographically strong. For example, if it were possible to produce a list of inputs for a particular output which was guaranteed to _not_ include the original input, this would work for us, but not as a cryptographic hash. Its trivial to produce artificial examples of this, but I can't think of a real hash function with the property. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 14:15:21 +0000 Lines: 42 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 15:22:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Fri, 5 Nov 2004, Ben Laurie wrote: > > >>Roy Arends wrote: >> >>>This is what I ment: >>> >>>given four names (a,b,c,d) and salt X, you'd start out with >>> >>> 1 2 3 4 >>>H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) >>> >>> >>>This is a circular ordered list (assume H(name,salt)=name). >>> >>>Now we introduce salt Y for two names (b, c) but not for (a,d) >>> >>>We are able to create the NSEC: H(b,Y)-H(c,Y) >>>But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) >>>Since H(c,Y)-H(b,Y) would deny existence of d. >> >>This is incorrect, since we do not have a H(a) < H(b). > > > assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. Choosing things for clarity that aren't true is not usually a great idea! -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: dee3@pothole.com Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 5 Nov 2004 09:31:54 -0500 (EST) Lines: 79 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Donald.Eastlake@motorola.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 15:45:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: dee3@localhost.localdomain To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411042242340.27766@filbert> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam, Thanks for all your comments. I'll review them more closely and respond at greater length but here are a couple of intial comments: I believe that the format of DNS keys should be defined independently of RR codes. As long as it works technically, I don't see why you would want to prohibit using a particular key format in a particular RR type. The original versions of this draft did include a signature format. Years ago, the DNSEXT chair made the removal of this a condition for accepting the draft as a WG draft. Although some have always had feelings against ECC due to the patent thicket that has surrounded much of it, I have always thought that the compact nature of ECC keys and signatures, at least in comparison with RSA, was a good fit for UDP DNS and there should be defined formats for interoperability for those who want to use it. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 4 Nov 2004, Samuel Weiler wrote: > Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST) > From: Samuel Weiler <weiler@tislabs.com> > To: dee3@pothole.com > Cc: namedroppers@ops.ietf.org > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > On Thu, 4 Nov 2004, Samuel Weiler wrote: > >> Be much more explicit about which of DNSKEY and/or KEY ... > > Further comments after some more reflection. > > First, I'd like to thank Donald for his efforts to put this document > (and the HMAC SHA TSIG doc) together. There are very few people with > both the ability to follow the current crypto research and the > willingness to bring that knowledge back to the IETF in a useful form. > We should applaud Donald for his willingness to do that. > > I'd also like to say that I'm not particularly averse to storing > random data in the DNS. > > That said, it's not clear to me why we're trying to store ECC keys in > the DNS nor, given that uncertainty, what RR type we might want to use > to store them. Of late, we've been choosing to separate data into new > type codes based on the use of the data, not the content or format of > the data. For cryptographic keys, in particular, we've tried to reuse > key storage formats (we reused the 2536 and 3110 formats in DNSKEY and > IPSECKEY), but we've allocated new RR types for different data users. > See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt > section 2.6 (now at RFC-Editor). > > Since we're not defining a SIG nor RRSIG format for ECC, it would > appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) > nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and > RFC3755. Who are they useful for? (Does anyone really want to store > ECC keys in the DNS?) And what does that suggest about what RR > type(s) they should be stored in? This all feeds into the IANA > section questions I posted earlier today. > > Looking further ahead, I also wonder if this record format's > flexibility might be dangerous. Can we imagine users of data that > can't effectively use all of the different types of eliptic curve keys > that can be stored in this RR? If so, we may be creating another > subtyping problem. > > -- Sam > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 15:54:15 +0100 (CET) Lines: 77 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:01:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418B8AF9.6010800@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Ben Laurie wrote: > Roy Arends wrote: > > On Fri, 5 Nov 2004, Ben Laurie wrote: > > > > > >>Roy Arends wrote: > >> > >>>This is what I ment: > >>> > >>>given four names (a,b,c,d) and salt X, you'd start out with > >>> > >>> 1 2 3 4 > >>>H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) > >>> > >>> > >>>This is a circular ordered list (assume H(name,salt)=name). > >>> > >>>Now we introduce salt Y for two names (b, c) but not for (a,d) > >>> > >>>We are able to create the NSEC: H(b,Y)-H(c,Y) > >>>But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) > >>>Since H(c,Y)-H(b,Y) would deny existence of d. > >> > >>This is incorrect, since we do not have a H(a) < H(b). > > > > assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. > > Choosing things for clarity that aren't true is not usually a great idea! What is not true about the statement H(name,salt)=name ? I chose that to make sure the ordered hash-chain is linear to the original name-chain. Is it that unthinkable that one implements a NULL hash function ? It is even in the DNSNR draft to have none-hashed values for the DNSNR/NSEC3 owner name. But, lets do the excersize without linearity. Lets NOT assume H(name,salt)=name, and go with a real hash function H(name,salt)=hash. given four names (a,b,c,d) and salt X, you'd start out with H(a,X)=g H(b,X)=z H(c,X)=l H(d,X)=q You'd get: 1 2 3 4 H(a,X)-H(c,X)-H(d,X)-H(b,X)-H(a,X) or, maybe more clear: g - l - q - z - g This is a circular ordered list. Now we introduce salt Y for two names (b, c) but not for (a,d), where H(b,Y)=s H(c,Y)=p We are able to create the NSEC: H(c,Y)-H(b,Y) or [p - s] But not the NSEC chain: H(c,Y)-H(b,Y)-H(c,Y) Since H(b,Y)-H(c,Y) would deny existence of H(d,Y) which is not H(b,Y) nor H(c,Y). Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Scott Rose" <scottr@nist.gov> Subject: question on draft-josefsson-rfc2538bis-00 Date: Fri, 5 Nov 2004 10:18:55 -0500 Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:25:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "DNSEXT WG" <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Reading over the drafts on the DNSEXT agenda for next week, I have a question on the algorithm field of the CERT RDATA: Section 2 says that if the algorithm of the key in the CERT RR is not defined in DNSSEC, to use RESERVED (0). I was wondering why this choice was made and not the PRIVATEDNS code (253)? There is a private code defined for the certificate type field. Scott **************************************** Scott Rose Adv. Network Tech. Div., NIST +1 301-975-8439 http://www-x.antd.nist.gov/dnssec/ **************************************** -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 05 Nov 2004 16:31:06 +0100 Lines: 27 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:40:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 20 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:fC9sYKFVI6x1muSblYZWvPKAo88= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler <weiler@tislabs.com> writes: > Since we're not defining a SIG nor RRSIG format for ECC, it would > appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) > nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and > RFC3755. Who are they useful for? (Does anyone really want to store > ECC keys in the DNS?) If I remember correctly, RFC 2538 uses the same IANA name space as the rest of DNSSEC for the key algorithms. Perhaps someone is using ECC for X.509 or OpenPGP data. So a specification for ECC, and an entry in the IANA DNSKEY key algorithm registry, seem useful. I believe it would be a too radical change to alter this now, if we want RFC 2538bis to move forward as a DRAFT STANDARD. Even if that isn't a consideration, I'm not convinced there is a strong motivation for changing this now. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: question on draft-josefsson-rfc2538bis-00 Date: Fri, 05 Nov 2004 16:49:35 +0100 Lines: 34 References: <ANECIHCPCBDLLEJLCOPGIEFADBAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:59:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 27 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:JzqIDz1ZI3fsMX1tBnggqRRhscg= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" <scottr@nist.gov> writes: > Reading over the drafts on the DNSEXT agenda for next week, I have a > question on the algorithm field of the CERT RDATA: > > Section 2 says that if the algorithm of the key in the CERT RR is not > defined in DNSSEC, to use RESERVED (0). I was wondering why this choice was > made and not the PRIVATEDNS code (253)? There is a private code defined > for the certificate type field. I don't know more than what's in RFC 2538. Donald? Olafur? PRIVATEDNS does not seem appropriate, draft-ietf-dnsext-dnssec-records: Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encoded domain name, which MUST NOT be compressed. That doesn't match the RRDATA specified in RFC 2538. However, using PRIVATEOID (254) might be appropriate for the X.509 certificate and CRLs, since they are prefixed with an OID. However that would not be compatible with RFC 2538. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 16:09:57 +0000 Lines: 100 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 17:19:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Fri, 5 Nov 2004, Ben Laurie wrote: > > >>Roy Arends wrote: >> >>>On Fri, 5 Nov 2004, Ben Laurie wrote: >>> >>> >>> >>>>Roy Arends wrote: >>>> >>>> >>>>>This is what I ment: >>>>> >>>>>given four names (a,b,c,d) and salt X, you'd start out with >>>>> >>>>> 1 2 3 4 >>>>>H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) >>>>> >>>>> >>>>>This is a circular ordered list (assume H(name,salt)=name). >>>>> >>>>>Now we introduce salt Y for two names (b, c) but not for (a,d) >>>>> >>>>>We are able to create the NSEC: H(b,Y)-H(c,Y) >>>>>But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) >>>>>Since H(c,Y)-H(b,Y) would deny existence of d. >>>> >>>>This is incorrect, since we do not have a H(a) < H(b). >>> >>>assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. >> >>Choosing things for clarity that aren't true is not usually a great idea! > > > What is not true about the statement H(name,salt)=name ? I chose that to > make sure the ordered hash-chain is linear to the original name-chain. Is > it that unthinkable that one implements a NULL hash function ? It is certainly not unthinkable, but non-NULL hash functions do not behave like NULL ones. What is not true about H(name,salt)=name is that it does not apply to all hash functions. > It is even > in the DNSNR draft to have none-hashed values for the DNSNR/NSEC3 owner > name. > > But, lets do the excersize without linearity. > > Lets NOT assume H(name,salt)=name, and go with a real hash function > H(name,salt)=hash. given four names (a,b,c,d) and salt X, you'd start out > with > > H(a,X)=g > H(b,X)=z > H(c,X)=l > H(d,X)=q > > You'd get: > > 1 2 3 4 > H(a,X)-H(c,X)-H(d,X)-H(b,X)-H(a,X) > > or, maybe more clear: > > g - l - q - z - g > > This is a circular ordered list. > > Now we introduce salt Y for two names (b, c) but not for (a,d), where > > H(b,Y)=s > H(c,Y)=p > > We are able to create the NSEC: H(c,Y)-H(b,Y) or [p - s] > But not the NSEC chain: H(c,Y)-H(b,Y)-H(c,Y) > Since H(b,Y)-H(c,Y) would deny existence of H(d,Y) which is not H(b,Y) > nor H(c,Y). The problem is that, for example, H(a,Y) might be q, so H(c,Y)-H(b,Y) denies (incorrectly) the existence of a. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 17:16:21 +0100 (CET) Lines: 14 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> <418BA5D5.90108@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 17:22:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418BA5D5.90108@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Ben Laurie wrote: > The problem is that, for example, H(a,Y) might be q, so H(c,Y)-H(b,Y) > denies (incorrectly) the existence of a. I totally agree. This means every name has to be hashed for each salt. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 16:23:11 +0000 Lines: 25 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> <418BA5D5.90108@algroup.co.uk> <Pine.BSO.4.56.0411051711430.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 17:30:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051711430.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Fri, 5 Nov 2004, Ben Laurie wrote: > >>The problem is that, for example, H(a,Y) might be q, so H(c,Y)-H(b,Y) >>denies (incorrectly) the existence of a. > > > I totally agree. This means every name has to be hashed for each salt. Right. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 17:28:32 +0000 Lines: 23 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <EDBA1D3C2161047C978E7937@[192.168.100.25]> <418B5029.4060207@algroup.co.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 18:34:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418B5029.4060207@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 05 November 2004 10:04 +0000 Ben Laurie <ben@algroup.co.uk> wrote: >> If it's not preimage resistant, these can then be sifted by (for >> instance) only looking at ones which match /[a-zA-Z-]+/. Unless I'm >> missing something. > > There is no requirement to recognise the form of the name. If you can > invert the hash function (even if the inverse is multi-valued) then you > get a list of names that might exist that is very much smaller than the > exhaustive list. My point is knowing what likely domain names look like means you are able to sift such a list very fast (without a query). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 17:27:31 +0000 Lines: 53 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> <iluactwhcpz.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 18:34:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluactwhcpz.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon, >>> However, as far as I understand, the hashed-NSEC idea does not require >>> a cryptographic strong hash function. >> >> Depends which hash property you are talking about. What you don't >> want is inversion (i.e. you know H(x), can you discover x?). It >> requires some cryptographically strong properties to prevent this >> (or rather make the problem computationally infeasible). > > Ah, right. This should be mentioned as the primary requirement on the > chosen hash. > > CRC-128 is fully invertible for input strings < 16 bytes, because of > the linearity. However, if we assume the salt is 16 bytes (as in > NSEC2), or longer, it is no longer possible to invert it. I am not a cryptographer, but many functions that munge things together losely called hash functions are not invertible for some values, and are trivially invertible for others. CRC-128 being an example if what you've said are correct. Hash functions may be overkill, but at least they provably do the job. >>> Since CRC-128 is not preimage resistant, an attacker can find many >>> domain names that produce 17, 42, 96, or any other CRC-128 value, as >>> the output. What does he gain by doing so? >> >> If it's not preimage resistant, these can then be sifted by (for >> instance) only looking at ones which match /[a-zA-Z-]+/. Unless I'm >> missing something. > > I don't understand. Are you saying that th attacker finds domain > names /[a-zA-Z-]+/ that "hash" to 17, 42, or 96? That's possible. > But then what does he do with does names? I mean if you have Y=H(x) to a small set of possibles x1, x2, ... for which H(x(n))=Y (i.e. they all have the same hash value), then you can reasonably trivially eliminate most of the set by looking at characteristics. For instance, if the hash function was "take the octet value as a number, and take it modulo a large prime", then you could sequentially add the large prime to H(x) and see when all octets fall match the regexp above. That would allow you to sift through the names very quickly. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 17:36:11 +0000 Lines: 22 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> <iluis8kfplh.fsf@latte.josefsson.org> <418B7D4E.7040501@algroup.co.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 18:44:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com> In-Reply-To: <418B7D4E.7040501@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 05 November 2004 13:17 +0000 Ben Laurie <ben@algroup.co.uk> wrote: > On reflection, I believe the property we are after is not a standard one > for cryptographic hashes, which is probably why we're arguing about which > of the standard properties it is! Seems to me that second preimage resistance is a sufficient but (perhaps) not a necessary condition (though I am not sure we've proved it's not necessary). As such, I'd have thought the obvious thing to do was to go for a function with the property, then truncate to appropriate length. I cannot see any *disadvantage* in doing that, unless someone can show there is a faster algorithm which is not invertible. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 18:30:43 +0000 Lines: 52 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> <iluis8kfplh.fsf@latte.josefsson.org> <418B7D4E.7040501@algroup.co.uk> <931BD0B0747AAEBA63339E5B@[192.168.0.4]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 19:42:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com> In-Reply-To: <931BD0B0747AAEBA63339E5B@[192.168.0.4]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben / Simon, --On 05 November 2004 17:36 +0000 Alex Bligh <alex@alex.org.uk> wrote: > Seems to me that second preimage resistance is a sufficient but (perhaps) > not a necessary condition (though I am not sure we've proved it's not > necessary). Actually, on further thought, and a quick look at the following URL to check my terminology is right: http://www.bletchleypark.net/cryptology/Hash_Functions.pdf I think if we assume (in deployment terms) the size of a domain is of comparable size to the size of a distributed attack network (or at least is not orders of magnitude larger), then the property we want is that knowing H(x) does not help us find x. This isn't quite second pre-image resistance - it's one-way or (first) pre-image resistance. I believe that this is a weaker requirement than second pre-image resistance as in second preimage resistance you are given an extra piece of information: some (other) value that hashes to the same number. So I think what we need is first-preimage resistance (and that is both necessary and sufficient) FOR THE PURPOSE OF PREVENTING ENUMERATION. However, we've also decided that people being able to find things that collide (i.e. knowing x, H(x), find a y such that H(y)=H(x)), is a bad thing (see archives). If we have first preimage resistance but not second preimage resistance, then it's going to be (by definition) computationally feasible to create collisions. Therefore, I think to be safe both from enumerations, and deliberate collisions, assuming a distributed attack, both first and second preimage resistance is both necessary and sufficient. What I do not think is necessary is strong collision resistance, but as far as I know it comes for free with all sensible hash functions. I'd have thought truncated SHA-256 would be a sensible choice. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 5 Nov 2004 14:35:10 -0500 (EST) Lines: 22 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 20:44:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluzn1we2it.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If I remember correctly, RFC 2538 uses the same IANA name space as the > rest of DNSSEC for the key algorithms. Perhaps someone is using ECC > for X.509 or OpenPGP data. So a specification for ECC, and an entry > in the IANA DNSKEY key algorithm registry, seem useful. I'm surprised that no one caught this when we were bickering over the RFC3755 IANA registry format. I don't have any problems with CERT reusing the registry, but as you're working on 2538bis, you might want to check the IANA considerations section in 3755 and the registry itself to see if any changes are needed. 2538bis might want to cite 3755, too. In any case, I think it would be good to add a note in the registry mentioning that CERT uses these numbers, also: http://www.iana.org/assignments/dns-sec-alg-numbers -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 23:47:55 +0100 Lines: 57 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> <iluactwhcpz.fsf@latte.josefsson.org> <1B7D12F383042E33099EA626@[192.168.0.4]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 23:57:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 50 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Sz63UeSwHycK6N5JE8yixaE0xwA= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> writes: >>> Depends which hash property you are talking about. What you don't >>> want is inversion (i.e. you know H(x), can you discover x?). It >>> requires some cryptographically strong properties to prevent this >>> (or rather make the problem computationally infeasible). >> >> Ah, right. This should be mentioned as the primary requirement on the >> chosen hash. >> >> CRC-128 is fully invertible for input strings < 16 bytes, because of >> the linearity. However, if we assume the salt is 16 bytes (as in >> NSEC2), or longer, it is no longer possible to invert it. > > I am not a cryptographer, but many functions that munge things together > losely called hash functions are not invertible for some values, > and are trivially invertible for others. CRC-128 being an example > if what you've said are correct. Hash functions may be overkill, > but at least they provably do the job. Of course. My goal with introducing CRC-128 is to make it a vehicle for discussing exactly what properties are required of the hash function. I'm not seriously proposing to use CRC-128, but thought it might be a useful function for discussion, since it is one of the simplest and most well known function that behave like a hash function but is not cryptographically strong. If we only use (presumed) good functions like SHA-1 in discussion and examples, intuition about that specific function might fool you wrt to which properties are required, and which attacks are possible if some properties do not hold. > I mean if you have Y=H(x) to a small set of possibles x1, x2, ... > for which H(x(n))=Y (i.e. they all have the same hash value), then > you can reasonably trivially eliminate most of the set by looking > at characteristics. Yes, I understand it now. You don't even have to rely on characteristics, you can ask DNS directly, if the set x_i is not too large. But being able to compute the set x_i is not a well-known hash property. Preimage resistance is the property of computing one _single_ element of that set. And as Ben said, if the hash function is designed so that the set x1, x2, ... that can be feasible computed include all candidates _except_ the real existing name, then the hash function would still be usable for the hashed-NSEC idea, but would not have the preimage resistance property. So preimage resistance is not sufficient. Preimage resistance may be necessary, but that is not obvious to me at this point. Thanks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 05 Nov 2004 23:59:52 +0100 Lines: 48 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Nov 06 00:07:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 41 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WziShMJn1fJUO35TB6wkdHPdrTw= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler <weiler@tislabs.com> writes: >> If I remember correctly, RFC 2538 uses the same IANA name space as the >> rest of DNSSEC for the key algorithms. Perhaps someone is using ECC >> for X.509 or OpenPGP data. So a specification for ECC, and an entry >> in the IANA DNSKEY key algorithm registry, seem useful. > > I'm surprised that no one caught this when we were bickering over the > RFC3755 IANA registry format. I don't have any problems with CERT > reusing the registry, but as you're working on 2538bis, you might want > to check the IANA considerations section in 3755 and the registry > itself to see if any changes are needed. It seems one new column, to specify applicability for CERT records would have to be added. I can add this as a IANA consideration of 2538bis. One could argue that this new IANA consideration in RFC 2538bis would make it incompatible with RFC 2538, thus preventing it from progressing to DRAFT STANDARD. On the other hand, the incompatibility is due to the changes introduced by RFC 3755, not the original specification nor the original DNSSEC specification. I would appreciate input on this issue, from people more familiar with procedural issues. > 2538bis might want to cite 3755, too. Won't DNSSECbis obsolete 3755? I'd rather reference DNSSECbis. > In any case, I think it would be good to add a note in the registry > mentioning that CERT uses these numbers, also: > > http://www.iana.org/assignments/dns-sec-alg-numbers I agree. How can we make that happen? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 09:12:10 -0500 Lines: 27 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Nov 06 01:49:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> X-OriginalArrivalTime: 06 Nov 2004 00:38:24.0881 (UTC) FILETIME=[ECD16E10:01C4C398] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >In San Diego, I was talking about salting requirements, Ben was talking >about multiple salt possibilities, hence the confusion between us at the >time. We agreed that multiple salts are possible, as long as the >salting requirement (every name MUST be salted with each salt) was >satisfied. > >Therefor, the relevant section in the DNSNR draft needs to be updated, >since I did not anticipate having multiple salts. > >Multiple salts are no problem, as long as every name is salted with each >salt. For every salt there will exist an NSEC-chain. > > I am lost, can you provide a summary of the arguments that lead to this conclussion? --Olaf namedropper -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Sat, 06 Nov 2004 14:37:04 +0000 Lines: 42 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> <iluactwhcpz.fsf@latte.josefsson.org> <1B7D12F383042E33099EA626@[192.168.0.4]> <ilu7jozewv8.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Nov 06 15:49:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <ilu7jozewv8.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 05 November 2004 23:47 +0100 Simon Josefsson <jas@extundo.com> wrote: > Yes, I understand it now. You don't even have to rely on > characteristics, you can ask DNS directly, if the set x_i is not too > large. The point is that elimination by property occupies a few CPU cycles, DNS involves several milliseconds. For a leaf label of length 8 octets, there are 256^8 possible values, of which only 63^8 are fall within the regexp (yes I know it's less than that if you don't have '-' at start and end, and far fewer if DNS records are stored in consistent case). That in effect reduces the time taken to find which of the set corresponds by a factor of 75,000. Let's call it 10^6 for simplicity. So if your set was of size (say) 10^12, without sifting, you'd have to make 10^12 DNS queries, which at (say) 1ms each, running 1000 in parallel, would, take 10^6 seconds or 11 days per name. However, with sifting, you instead take 1/75000th that time as you need to make far fewer queries - 13 seconds per name - 2 years to enumerate co.uk without spreading the load between machines. > But being able to compute the set x_i is not a well-known hash > property. Preimage resistance is the property of computing one > _single_ element of that set. First preimage resistance is the property of finding ANY single element of the set, not the entire set. That is true and I'd missed that. However, you don't need to find the entire set to have a good stab at enumerability. However, clearly if first preimage resistance is a sufficient (but not necessary) property for the "set" preimage resistance you describe; see other message for why I think you need second preimage resistance anyway. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: James Snell <jasnell@gmail.com> Subject: XML Resource Record [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Mon, 8 Nov 2004 08:46:36 -0500 Lines: 125 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> <20041103150449.2285e598.olaf@ripe.net> Reply-To: James Snell <jasnell@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 08 14:59:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GJUzTJwaJ1ZsOb+cLrmHaIGHL9E8Fn7hYWUlgdmpyDKEvdudlFo3TcapYbvAunInK65muHDkS1cQzZjdeSAxKi1Kbpvm724O1ZMTzocwGaOHtAx+CJWVUl2sCzK8kmyf4875ftZhcxNnMFQ+pjh0Z4hEaen5vdbtorFF3PSGgLw= To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20041103150449.2285e598.olaf@ripe.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Regarding the XML Resource Record that we have included in this spec, I too have my reservations about it. Yes, as currently defined it does suffer from a lot of the same ambiguity problems as the TXT record with the one exception that the XML data is at least self describing. The reasons for having the XML RR in the first place are fairly simple: 1. Many very important Web service descriptors are going to be in various XML formats (WS-Policy, WS-Addressing, etc), some of which will be digitally signed. The goal is to allow clients to query for this information in one location, preferrably with the XML in tact. Redirection is possible, but we'd rather avoid redirecting for everything. The EPR record will be adequate for the majority of cases, but we need to be able to support the edge cases as well. 2. The XML descriptors are continuing to evolve and more may emerge over time. This is an area that is much more fluid and dynamic than what DNS typically handles therefore it is important to have a record type that is some what malleable to avoid having to change an RR or come up with a new one every time a new WS spec comes out. That said, however, there are definitely some things we can do to limit the scope of the record, thereby reducing the potential for abuse: First, we can limit the use of the XML record strictly to Web service related information. Initially this limit would cover things like WS-Policy and WS-Addressing. Second, we can limit the amount of data that goes into the record. Regarding the encoding field in the XML RR, thanks for the tip. I was unclear as to what extent DNS implementations were allowed to muck around with things based on the content of the RDATA. Changing the various MUSTs to SHOULDs should not be a problem. On Wed, 3 Nov 2004 15:04:49 +0100, Olaf M. Kolkman <olaf@ripe.net> wrote: > > > Hello James and Andrew, > > I have been reading your draft. Having very little experience with the > web-services architecture there are a few things that I cannot get my > finger behind. > > The first question I have is on EPR. It is triggered by having > possible redirection ( WDSL URL or an XML RR), why not simply always > redirect to a WSDL document describing the service? It may make life > much easier if the web service descriptions are dynamic in nature. You > will not need to bother with caching and other DNS data propagation > effects such as secondary DNS servers not updating in time. > > I do not feel comfortable with the XML RR. It has more or less the > same properties as the TXT RR. It has no limitations and may cause > people to put all kinds of things in the XML RR, such as > internet-draft XML source (interesting idea :-) ). > > If there is a possibility for redirection I do not understand why the > XML RR would be needed, what is the perceived benefit? > > I also have a more detailed questions and remarks about the RRs. > > 1. I think that some of the EPR RDATA elements can be split into > their functional parts. For instance the PortType QNAME (confusing > name for a data element in the context of DNS :-) ) could be > encoded as: > > |length|namespace-uri|length|localpart > > 2. It is not clear to me why the separator "_ws" is needed in the > proposed owner names of EPR records {name}._ws.{domain}. Both > client and server will know which part of the name is intended to > be the domain part and which part will be the name part. > > Dropping _ws could introduce an ambiguity (If there exists both a > "inquire.uddi" and a "inquire" service and the "inquire.uddi" > service has been implemented for the "example.com" domain and the > "inquire" service has been implemented for the "uddi.example.com" > domain.) But that ambiguity one could solve by adding a simple > counter in the RDATA that tells us at which label the split between > name and domain occurs. The DNSSIG RR uses a similar mechanism to > indicate to indicate which part of a domain name has been > synthesized. > > 3. Section 2.3.1. > > "DNS implementations MUST send the XML data using the encoding > specified by the encoding byte flag". > > DNS implementations will send binary RDATA, they will never look at > the content of the RDATA before putting information on the > wire. The encoding flag can only be used as an indicator to the > client interpreting the RDATA on what the binary RDATA is > representing. > > Most of the MUSTs in this paragraphs are not enforcable and > probably should be SHOULDs. (most of them relate to language that > enforces implementers to strip the XML cruft before putting it into the > RDATA). > > 4. Editing nit: most of your example RRs span multiple lines, you > should use brackets to indicate this > > mystock._ws.example.com XML 0 <EndpointReference ( > xmlns="..." > .... > </EndpointReference> ) > > Olaf Kolkman > > namedropper (no hats) > -- - James Snell IBM, Emerging Technologies jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: online signing draft Date: Mon, 8 Nov 2004 18:28:08 -0500 (EST) Lines: 281 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Nov 09 00:48:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments invited. -- Sam Internet-Draft S. Weiler SPARTA, Inc. J. Ihren Autonomica 30 October 2004 Minimally Covering NSEC Records and DNSSEC On-line Signing draft-weiler-dnsext-dnssec-online-signing-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on 30 April 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by [-records]. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. Introduction and Terminology With DNSSEC [-records], an NSEC record lists the next instantiated name in its zone, proving that no names exist in the "span" between the NSEC's owner name and the name in the "next name" field. In this document, an NSEC record is said to "cover" the names between its owner name and next name. Through repeated queries that return NSEC records, it is possible to retrieve all of the names in the zone, a process commonly called "walking" the zone. Some zones have policies forbidding zone transfers by arbitrary clients; this side-effect of the NSEC architecture subverts those policies. This document presents a way to prevent zone walking by constructing NSEC records that cover fewer names. These records can make zone walking take approximately as many queries as simply asking for all possible names in a zone, making zone walking impractical. Some of these records must be created and signed on demand, which requires on-line private keys. Anyone contemplating use of this technique is strongly encouraged to review the discussion of the risks of on-line signing in section [Security Considerations]. The technique presented here may be useful to a zone that wants to use DNSSEC, is concerned about exposure of its zone contents via zone walking, and is willing to bear the costs of on-line signing. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119]. Minimally Covering NSEC Records This mechanism involves both changes to NSEC records for instantiated names, which can still be generated and signed in advance, as well as the on-demand generation and signing of new NSEC records whenever a name must be proven not to exist. In the 'next name' field of instantiated names' NSEC records, rather than list the next instantiated name in the zone, list any name that falls lexically after the NSEC's owner name and before the next instantiated name in the zone, according to the ordering function in [-records] section 6.2. These NSEC records are returned whenever proving something specifically about the owner name (e.g. that no resource records of a given type appear at that name). Whenever an NSEC record is needed to prove the non-existence of a name, a new NSEC record is produced and signed. The new NSEC record has an owner name lexically before the QNAME but lexically following any existing name and a "next name" lexically following the QNAME but before any existing name. The functions to generate the lexically following and proceeding names need not be perfect nor consistent, but the generated NSEC records must not cover any existing names. Furthermore, this technique works better when the generated NSEC records cover very little of the zone's namespace. For example, a query for the non-instantiated name example.com might produce the following NSEC record: exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) Before answering a query with this record, an authoritative server must test for the existence of names between these endpoints. If the generated NSEC would cover existing names (e.g. exampldd.com), a better increment or decrement function may be used or the covered name closest to the QNAME could be used as the NSEC owner name or next name, as appropriate. If an existing name is used as the NSEC owner name, that name's real NSEC record MUST be returned. Using the same example, assuming an exampldd.com delegation exists, this record might be returned from the parent: exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) Like every authoritative record in the zone, each generated NSEC record MUST have corresponding RRSIGs generated using each algorithm (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as described in [-protocol] section 2.2. To minimize the number of signatures that must be generated, a zone may wish to limit the number of algorithms in its DNSKEY RRset. Better Increment & Decrement Functions Section 6.2 of [-records] defines a strict ordering of DNS names. Working backwards from that definition, it should be possible to define increment and decrement functions that generate the immediately following and preceeding names, respectively. This document does not define such functions. Instead, this section presents functions that come reasonably close to the perfect ones. As described above, an authoritative server MUST ensure than no generated NSEC covers any existing name. To increment a name, add a leading label with a single null octet. To decrement a name, decrement the last character of the leftmost label, then fill that label to a length of 63 octets with octets of value 255. To decrement a null octet, remove the octet -- if an empty label is left, remove the label. Defining this function numerically: fill the left-most label to its maximum length with zeros (numeric, not ASCII zeros) and subtract one. In response to a query for the non-existent name foo.example.com, these functions produce an NSEC record of: fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) Both of these functions are imperfect: they don't take into account constraints on number of labels in a name nor total length of a name. IANA Considerations This document has no IANA Actions. Security Considerations This approach requires on demand generation of RRSIG records. This creates several new vulnerabilities. First, on demand signing requires that a zone's authoritative servers have access to its private keys. Storing private keys on well-known internet-accessible servers may make them more vulnerable to unintended disclosure. Second, since generation of public key signatures tends to be computationally demanding, the requirement for on demand signing makes authoritative servers vulnerable to a denial of service attack. Lastly, if the increment and decrement functions are predictable, on-demand signing may enable a chosen-plaintext attack on a zone's private keys. Zones using this approach should attempt to use cryptographic algorithms that are resistant to chosen-plaintext attacks. It's worth noting that while DNSSEC has a "mandatory to implement" algorithm, that is a requirement on resolvers and validators -- there is no requirement that a zone be signed with any given algorithm. If any "mandatory to implement" algorithm is found to be particularly vulnerable to chosen plaintext attack, a zone may which to switch to another algorithm or use less predictable increment and decrement function. The success of using minimally covering NSEC record to prevent zone walking depends greatly on the quality of the increment and decrement functions chosen. An increment function that chooses a name obviously derived from the next instantiated name may be easily reverse engineered, destroying the value of this technique. An increment function that always returns a name close to the next instantiated name is likewise a poor choice. A good choice of increment and decrement functions are the ones that produce the immediately following and preceeding names, respectively, though zone administrators may wish to use less perfect functions that return more human-friendly names than the functions described in section X above. Another obvious but misguided concern is the danger from synthesized NSEC records being replayed. It's possible for an attacker to replay an old but still validly signed NSEC record after a new name has been added in the span covered by that NSEC, incorrectly proving that there is no record at that name. This danger exists with DNSSEC as defined in [-bis]. The techniques described here actually decrease the danger, since the span covered by any NSEC record is smaller than before. Choosing better increment and decrement functions will further reduce this danger. Normative References (out of date versions) [I-D.ietf-dnsext-dnssec-intro] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 2004. [I-D.ietf-dnsext-dnssec-records] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-records-08 (work in progress), May 2004. [I-D.ietf-dnsext-dnssec-protocol] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in progress), May 2004. Acknowledgements Many individuals contributed to this design. They include, in addition to the authors of this document, Olaf Kolkman, Ed Lewis, Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, Jakob Schlyter, Bill Manning, and Joao Damas. Authors' Addresses Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 USA EMail: weiler@tislabs.com Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm, Sweden Mail: johani@autonomica.se -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: online signing draft Date: Tue, 09 Nov 2004 16:02:41 +0000 Lines: 15 References: <Pine.GSO.4.55.0411081817130.15465@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 09 17:17:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (X11/20041031) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411081817130.15465@filbert> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > Better Increment & Decrement Functions Geoff and I have been working on a rigorous definition of these, which I hope he'll post later today. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: dee3@pothole.com Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Tue, 9 Nov 2004 17:53:44 -0500 (EST) Lines: 147 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert> <ilu3bznewbb.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Nov 10 00:08:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: dee3@localhost.localdomain To: namedroppers@ops.ietf.org In-Reply-To: <ilu3bznewbb.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Samuel Weiler wrote: > Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST) > From: Samuel Weiler <weiler@tislabs.com> > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > On Tue, 12 Oct 2004 dee3@pothole.com wrote: > >> Please post any comments on these two drafts. I gave brief presentations >> on them at the last IETF and plan to do so again next month. If there are >> no substantial comments, I will ask that they be working group Last Called >> right after the upcoming meeting. > > I've only read parts of draft-ietf-dnsext-ecc-key-05. Here are some > comments on the bits I have read: > > This document needs to take into account the type code roll (RFC3755). > Examples: Section 1 refers to SIG, which has been largely, but not > entirely, deprecated. Section 2 says "key RRs", then cites > DNSSECbis-records. See RFC3755 IANA considerations, section 4.2. Be > much more explicit about which of DNSKEY and/or KEY you mean here. You are right. My only excuse, not very good, is that this draft has been around for many years in one form or another. It is meant to define algorithm code point 4 which has always been reserved for ECC. As originally posted, it also defined a signature format usable in RRSIG and SIG. There was lots of resistence due to fears of inability to handle a zone signed with more than one algorithm, and the like. So, quite some time ago, the draft was admitted as a WG draft only on condition that the signature date format be stripped out of it. I think that's silly and the signature format section should be reinserted. > Section 2, second paragraph: "with signatures..." is confusing. Just > say RRSIGs. Also: "key validity may not be in the RR with the > key...". First, just say KEY or DNSKEY. Also: I see no key validity > field in this RR -- why have the equivolcal phrasing with a "may"? I'd be happy to work on modernizing the wording. > IANA section: > > Should comment on whether any algorithm numbers need to be assigned > (and, if not, where they are assigned). See 3755 section 4.2. As I say, it is intended to be 4. > It looks like a new registry is being established. This text is > likely insufficient for that task. See > draft-narten-iana-considerations-rfc2434bis-01.txt Another case where I can bring the document up to the more recent standards. > Nits: > > Section 5 (Performance Considerations), second paragraph, third line: > s/ and and/, and/ > > Status of this memo: "This draft is intended to be become a Proposed > Standard RFC." is not allowed, per > http://www.ietf.org/ietf/1id-guidelines.txt I would agree that it would be better to remove this and the guidelines specifically prohibit certainly words, that imply status, from being in the title of an ID. But I don't actually see where the guidelines prohibit this sentence. Could you point it out to me? > Boilerplate looks incomplete (Acceptance of section 3 of 3667 is > missing). As above. On Thu, 4 Nov 2004, Samuel Weiler wrote: > Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST) > From: Samuel Weiler <weiler@tislabs.com> > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > On Thu, 4 Nov 2004, Samuel Weiler wrote: > >> Be much more explicit about which of DNSKEY and/or KEY ... > > Further comments after some more reflection. > > First, I'd like to thank Donald for his efforts to put this document > (and the HMAC SHA TSIG doc) together. There are very few people with > both the ability to follow the current crypto research and the > willingness to bring that knowledge back to the IETF in a useful form. > We should applaud Donald for his willingness to do that. > > I'd also like to say that I'm not particularly averse to storing > random data in the DNS. It certainly isn't particularly intended to be random data. It's original intent wass to provide ECC as another interoperable way to sign zones and store ECC keys for use by other protocols. > That said, it's not clear to me why we're trying to store ECC keys in > the DNS nor, given that uncertainty, what RR type we might want to use > to store them. Of late, we've been choosing to separate data into new > type codes based on the use of the data, not the content or format of > the data. For cryptographic keys, in particular, we've tried to reuse > key storage formats (we reused the 2536 and 3110 formats in DNSKEY and > IPSECKEY), but we've allocated new RR types for different data users. > See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt > section 2.6 (now at RFC-Editor). > > Since we're not defining a SIG nor RRSIG format for ECC, it would > appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) > nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and > RFC3755. Who are they useful for? (Does anyone really want to store > ECC keys in the DNS?) And what does that suggest about what RR > type(s) they should be stored in? This all feeds into the IANA > section questions I posted earlier today. I removed the signature format, which was present in earlier versions, because that was made a condition by the chairs for consideration by the WG. I think it should be added back. The ECC / Algorithm 4 should, in my opinion, be allowed as widely as RSA, although of course it should only be a MAY for implementation. The compactness of ECC keys and signatures is particularly attractive for DNS and a code point was reserved for ECC from the beginning. > Looking further ahead, I also wonder if this record format's > flexibility might be dangerous. Can we imagine users of data that > can't effectively use all of the different types of eliptic curve keys > that can be stored in this RR? If so, we may be creating another > subtyping problem. This is a reasonable topic for discussion. > -- Sam Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: dee3@pothole.com Subject: RFC2538bis Re: draft-ietf-dnsext-ecc-key-05.txt Date: Tue, 9 Nov 2004 18:06:49 -0500 (EST) Lines: 74 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert> <ilu3bznewbb.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Nov 10 00:15:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: dee3@localhost.localdomain To: namedroppers@ops.ietf.org In-Reply-To: <ilu3bznewbb.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Simon Josefsson wrote: > Date: Fri, 05 Nov 2004 23:59:52 +0100 > From: Simon Josefsson <jas@extundo.com> > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > Samuel Weiler <weiler@tislabs.com> writes: > >>> If I remember correctly, RFC 2538 uses the same IANA name space as the >>> rest of DNSSEC for the key algorithms. Perhaps someone is using ECC >>> for X.509 or OpenPGP data. So a specification for ECC, and an entry >>> in the IANA DNSKEY key algorithm registry, seem useful. It's almost the same. RFC 2538 specifically allows zero for unknown cases. >> I'm surprised that no one caught this when we were bickering over the >> RFC3755 IANA registry format. I don't have any problems with CERT >> reusing the registry, but as you're working on 2538bis, you might want >> to check the IANA considerations section in 3755 and the registry >> itself to see if any changes are needed. I think it is a lot easier to have one registry. > It seems one new column, to specify applicability for CERT records > would have to be added. I can add this as a IANA consideration of > 2538bis. > > One could argue that this new IANA consideration in RFC 2538bis would > make it incompatible with RFC 2538, thus preventing it from > progressing to DRAFT STANDARD. This sort of thing is one reason why algorithms and their implementation requirements are increasingly being split out into separate documents. That way, if a protocol is reasonably algorithm independent, it can continue to advance along the standards track even if advances in cryptography requires the corresponding "crypto suites" document to keep changing. > On the other hand, the incompatibility is due to the changes > introduced by RFC 3755, not the original specification nor the > original DNSSEC specification. > > I would appreciate input on this issue, from people more familiar with > procedural issues. > >> 2538bis might want to cite 3755, too. > > Won't DNSSECbis obsolete 3755? I'd rather reference DNSSECbis. Yes, it does obsolete 3755. >> In any case, I think it would be good to add a note in the registry >> mentioning that CERT uses these numbers, also: >> >> http://www.iana.org/assignments/dns-sec-alg-numbers > > I agree. How can we make that happen? > > Thanks, > Simon Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Document advancement DNSEXT: Case Insensitive Date: Wed, 10 Nov 2004 11:04:00 -0500 Lines: 100 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: namedroppers@ops.ietf.org, Margaret Wasserman <margaret@thingmagic.com>, ogud@ogud.com, "Olaf M. Kolkman" <olaf@ripe.net>, iesg-secretary@ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 10 17:14:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: Thomas Narten <narten@us.ibm.com> X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thomas, Please advance Case Insensitive clarification on the standards track: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-04.txt. 1. Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes, we have read this document and it has been reviewed and revised. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, key members of DNSEXT a have read this document. As this document was created to address a narrow non-controversial issue that was from identified during the review of RFC3597, this issue has clear base and purpose. 3. Do you have concerns that the document needs more review from a particular (broader) perspective? In theory this document should be reviewed by people that are experts in non English languages as it border line touches on how these are represented in DNS. But as IDN has addressed that there is no further review needed. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? The only concern with the document, is that the educational/background sections may draw more interest and discussion than the actual DNS Protocol content of the document. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group consensus is solid. The WG has only raised issues with the semantics and structure of the document not content. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No 7. Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). The document adheres to most of the ID nits with the exception that some of the IPR statements required by RFC3668 are non compliant. There are no IPR issues possible with this document. We request that the editor fix the IPR statement at the same time as he addresses any nits brought up during AD review. 8. Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? References are split, and all normative references are RFCs. 9. For Standards Track and BCP documents, the IESG approval announcement includes a write up section with the following sections: Technical Summary: RFC1034/5 was written when US-ASCII was the only language used on on the Internet. For this reason some corner cases related to case folding where not thought out. This document nails down these corner cases. The action of the document is to explicitly say only case folding only applies to letters in the A-Z range. This is the only guaranteed 100% inter operable solution. Working Group Summary The document being advanced has been reviewed, it is non-controversial and will not change any implementations or practices. Protocol Quality: This is quality document. The protocol change is minimal. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: online signing draft Date: Thu, 11 Nov 2004 09:54:03 +0000 (GMT) Lines: 22 References: <4190EA21.8010205@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 11:07:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <4190EA21.8010205@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> wrote: > Samuel Weiler wrote: > > > Better Increment & Decrement Functions > > Geoff and I have been working on a rigorous definition of these, which I > hope he'll post later today. Now available at: http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-00.txt Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: On dynamic NSEC Date: Thu, 11 Nov 2004 13:04:26 +0100 Lines: 52 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 13:13:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 45 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:7i4epkPKNXHMCFAu2EaTULZy/z0= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > [13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it > on the fly. minimally cover. idea has been posted to ML. not in > archive. use NSEC mechanism, good things, can use current resolvers > to validate. would mean can deploy DNSSECbis without enumeration > properties, if can implement this in server.... ... > [13:07:54] <ggm> Proposed way forward: fast-track epsilon in this > group, review, try to see if will work, publish asap. so that things > can be deployed today. in same time, continue on other solutions, > without makeing choices. There seem to be some assumption that online signing of dynamically generated NSEC with "epsilon" domains coexist with DNSECbis. I'd like to remind people about section 2.3 of protocol-09: Each owner name in the zone which has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. ... An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner names nodes which were not the owner name of any RRset before the zone was signed. This text imply to me that you cannot invent new owner names for NSEC. I believe the above MUST's are not required for interoperability nor are they necessary for successful operation of DNSECbis. It seems the text may cause problems, if dynamic signing of NSEC with epsilon domain names is used together with DNSECbis. I raised this problem, in the context of lying NSEC, during the DNSECbis last call. It was apparently ignored. http://article.gmane.org/gmane.ietf.dnsext/5339 I maintain that the MUST cannot in general be verified by clients, and hence should not be part of the specification. Further I believe that the text prevent deployment of NSEC alternatives. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 13:10:45 +0000 Lines: 24 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 14:21:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 13:04 +0100 Simon Josefsson <jas@extundo.com> wrote: > I maintain that the MUST cannot in general be verified by clients, and > hence should not be part of the specification. Further I believe that > the text prevent deployment of NSEC alternatives. Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't be fiddling with DNSSEC-bis now (not sure we even can). Both epsilon-based dynamic signing, and hashed NSEC'-based mechanisms will require an alteration to/addition to DNSSEC-bis, and will need to make their own (separate) way down the standards track. The former alteration is clearly smaller, and hence progress should be quicker (though I suspect due to key exposure and other factors, its audience may be more limited). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 09:16:42 -0500 Lines: 33 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ed.lewis@neustar.biz X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 15:26:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:10 -0500 11/11/04, Alex Bligh wrote: >Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't >be fiddling with DNSSEC-bis now (not sure we even can). I'd put it this way - we shouldn't be fiddling with the DOCUMENTS that are in production. But don't let DOCUMENTS get in the way of RUNNING CODE. Proposed Standard status recognizes that there may need to be adjustments to the text to describe reality. I said in another group "it's never too late to comment on the protocol, but it's too late to comment on the document" in the context of a document that we had handed to the IESG. Simon is right about the passage. Alex is half right that fiddling with DNSSECbis - we ought not fiddle with docs so implementers and operators can get to work. But never let the bureaucracy of what's been written get in the way of real technical progress. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar I would have been at the meeting, but I was busy raking the leaves from the (now) empty non-terminals in my yard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 14:31:03 +0000 Lines: 60 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 15:43:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (X11/20041031) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-OriginalArrivalTime: 11 Nov 2004 14:33:05.0428 (UTC) FILETIME=[5B373540:01C4C7FB] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > > >>[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it >>on the fly. minimally cover. idea has been posted to ML. not in >>archive. use NSEC mechanism, good things, can use current resolvers >>to validate. would mean can deploy DNSSECbis without enumeration >>properties, if can implement this in server.... > > ... > >>[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this >>group, review, try to see if will work, publish asap. so that things >>can be deployed today. in same time, continue on other solutions, >>without makeing choices. > > > There seem to be some assumption that online signing of dynamically > generated NSEC with "epsilon" domains coexist with DNSECbis. > > I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. > ... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. > > This text imply to me that you cannot invent new owner names for NSEC. > > I believe the above MUST's are not required for interoperability nor > are they necessary for successful operation of DNSECbis. > > It seems the text may cause problems, if dynamic signing of NSEC with > epsilon domain names is used together with DNSECbis. > > I raised this problem, in the context of lying NSEC, during the > DNSECbis last call. It was apparently ignored. > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > I maintain that the MUST cannot in general be verified by clients, and > hence should not be part of the specification. Further I believe that > the text prevent deployment of NSEC alternatives. This is a known issue. In order to deploy NSEC+epsilon, we have to change the text. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 09:47:03 -0500 Lines: 42 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 15:56:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: namedroppers@ops.ietf.org In-Reply-To: <a06110402bdb92386847d@[10.20.30.22]> References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:16 11/11/2004, Edward Lewis wrote: >At 8:10 -0500 11/11/04, Alex Bligh wrote: >>Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't >>be fiddling with DNSSEC-bis now (not sure we even can). > >I'd put it this way - we shouldn't be fiddling with the DOCUMENTS that are >in production. > >But don't let DOCUMENTS get in the way of RUNNING CODE. Proposed Standard >status recognizes that there may need to be adjustments to the text to >describe reality. > >I said in another group "it's never too late to comment on the protocol, >but it's too late to comment on the document" in the context of a document >that we had handed to the IESG. > >Simon is right about the passage. Alex is half right that fiddling with >DNSSECbis - we ought not fiddle with docs so implementers and operators >can get to work. But never let the bureaucracy of what's been written get >in the way of real technical progress. To amplify what Ed said, at this point we do not know the FULL extent of the changes needed to the DNSSECbis documents, when we know that we will issue an update to DNSSECbis documents. We also do not know at this time for sure that anyone will deploy the +/-epsilon changes, there might be engineering reasons not to do that in which case the updating the protocol is a mute point. Please start the discussion on what +/- epsilon will be like, once the WG understands and has consensus on the modified protocol, the appropriate changes to protocol described in DNSSECbis will be made. Olafur Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 15:53:12 +0100 (CET) Lines: 63 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <419377A7.3000906@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:01:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <419377A7.3000906@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Nov 2004, Ben Laurie wrote: > Simon Josefsson wrote: > > Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > > > > > >>[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it > >>on the fly. minimally cover. idea has been posted to ML. not in > >>archive. use NSEC mechanism, good things, can use current resolvers > >>to validate. would mean can deploy DNSSECbis without enumeration > >>properties, if can implement this in server.... > > > > ... > > > >>[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this > >>group, review, try to see if will work, publish asap. so that things > >>can be deployed today. in same time, continue on other solutions, > >>without makeing choices. > > > > > > There seem to be some assumption that online signing of dynamically > > generated NSEC with "epsilon" domains coexist with DNSECbis. > > > > I'd like to remind people about section 2.3 of protocol-09: > > > > Each owner name in the zone which has authoritative data or a > > delegation point NS RRset MUST have an NSEC resource record. > > ... > > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > > RRset at any particular owner name. That is, the signing process > > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > > not the owner name of any RRset before the zone was signed. > > > > This text imply to me that you cannot invent new owner names for NSEC. > > > > I believe the above MUST's are not required for interoperability nor > > are they necessary for successful operation of DNSECbis. > > > > It seems the text may cause problems, if dynamic signing of NSEC with > > epsilon domain names is used together with DNSECbis. > > > > I raised this problem, in the context of lying NSEC, during the > > DNSECbis last call. It was apparently ignored. > > > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > > > I maintain that the MUST cannot in general be verified by clients, and > > hence should not be part of the specification. Further I believe that > > the text prevent deployment of NSEC alternatives. > > This is a known issue. In order to deploy NSEC+epsilon, we have to > change the text. IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion path until DNSSEC-ter. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 15:11:20 +0000 Lines: 35 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> <6.1.2.0.2.20041111093020.049cbec0@localhost> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:18:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org In-Reply-To: <6.1.2.0.2.20041111093020.049cbec0@localhost> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 09:47 -0500 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 <ogud@ogud.com> wrote: > To amplify what Ed said, at this point we do not know the FULL extent > of the changes needed to the DNSSECbis documents, when we know that we > will issue an update to DNSSECbis documents. [***] > We also do not know at this time for sure that anyone will deploy > the +/-epsilon changes, there might be engineering reasons not to do that > in which case the updating the protocol is a mute point. Sorry to be an aspiring documentation-lawyer, but I presume what you mean is that (a) we should be developing a draft documentation which, if things run to completition will form a stand-alone set of documents which can be read as as update for the existing DNSSECbis protocol (i.e. that the two instances of the word "documentats" above should be "protocol"); and not (b) that we are going to be doing work now which will result is us asking the IESG to change the DNSSECbis documents themselves prior to further advance down the standards track. I would be worried if you did in fact mean (b) as I thought the entire purpose of sending DNSSECbis off to the IESG although quite a few people think it is far from perfect was so that further development would NOT disrupt code development deployment. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 02:14:39 +1100 Lines: 35 References: <Pine.BSO.4.56.0411111552060.749@trinitario.schlyter.se> Cc: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:21:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Arends <roy@dnss.ec> In-reply-to: Your message of "Thu, 11 Nov 2004 15:53:12 BST." <Pine.BSO.4.56.0411111552060.749@trinitario.schlyter.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > I raised this problem, in the context of lying NSEC, during the > > > DNSECbis last call. It was apparently ignored. > > > > > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > > > > > I maintain that the MUST cannot in general be verified by clients, and > > > hence should not be part of the specification. Further I believe that > > > the text prevent deployment of NSEC alternatives. > > > > This is a known issue. In order to deploy NSEC+epsilon, we have to > > change the text. > > IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion > path until DNSSEC-ter. Maybe temporary. Once implemented there is less pressure to implement other online signing solutions. To get rid of enumeneration in deep zones online signing appears to be the only solution. Once there is a online signing solution it is unlikely that a second solution will be implemented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 16:42:47 +0100 (CET) Lines: 56 References: <200411111514.iABFEdvi052278@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:50:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200411111514.iABFEdvi052278@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 12 Nov 2004, Mark Andrews wrote: > > > > > I raised this problem, in the context of lying NSEC, during the > > > > DNSECbis last call. It was apparently ignored. > > > > > > > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > > > > > > > I maintain that the MUST cannot in general be verified by clients, and > > > > hence should not be part of the specification. Further I believe that > > > > the text prevent deployment of NSEC alternatives. > > > > > > This is a known issue. In order to deploy NSEC+epsilon, we have to > > > change the text. > > > > IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion > > path until DNSSEC-ter. > > Maybe temporary. Once implemented there is less pressure > to implement other online signing solutions. Yes. So we can focus on nsec++. Online signing is not really optimal for high load servers. > To get rid > of enumeneration in deep zones online signing appears to > be the only solution. Not really. This can be solved using CNAME for these extremely long names. If you're referring to wildcards, I see the problem. Wildcard proofs using NSEC++ may have multiple NSEC++'s in contrast with current NSEC where there is a maximum of two. > Once there is a online signing solution it is unlikely that > a second solution will be implemented. No worries. Online signing is not an optimal solution. NSEC++ is not an optimal solution as well. We might need both. I do think that the larger TLD's might have a problem with dynamic signing, due to several critical deployment issues, like an online key, high response cost due to the crypto, key management between the authoritative servers. Typically, these larger TLD's do not have zones with very long, multiple labels. In general TLD's have just single label deep delegations, so the wildcard problem of > 2 NSEC++ does not apply. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 15:32:23 +0000 Lines: 43 References: <200411111514.iABFEdvi052278@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roy Arends <roy@dnss.ec>, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 17:07:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (X11/20041031) X-Accept-Language: en-us, en To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200411111514.iABFEdvi052278@drugs.dv.isc.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-OriginalArrivalTime: 11 Nov 2004 16:00:31.0748 (UTC) FILETIME=[92441C40:01C4C807] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Andrews wrote: >>>>I raised this problem, in the context of lying NSEC, during the >>>>DNSECbis last call. It was apparently ignored. >>>> >>>>http://article.gmane.org/gmane.ietf.dnsext/5339 >>>> >>>>I maintain that the MUST cannot in general be verified by clients, and >>>>hence should not be part of the specification. Further I believe that >>>>the text prevent deployment of NSEC alternatives. >>> >>>This is a known issue. In order to deploy NSEC+epsilon, we have to >>>change the text. >> >>IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion >>path until DNSSEC-ter. > > > Maybe temporary. Once implemented there is less pressure > to implement other online signing solutions. To get rid > of enumeneration in deep zones online signing appears to > be the only solution. As I pointed out yesterday, deep zones are only an issue with hashed NSEC if you consider the hashes to be names. Clearly this is the simplest solution, but, equally clearly, it is not the only one. > Once there is a online signing solution it is unlikely that > a second solution will be implemented. Given that there are several TLDs (and probably others) that won't deploy online keys, nor NSEC, I think you're wrong. But there's little point debating it. It'll either happen, or it won't. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Rob Austein <sra@isc.org> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 11:09:54 -0500 Lines: 22 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 17:16:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 11 Nov 2004 13:04:26 +0100, Simon Josefsson wrote: > ... > I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. > ... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. > > This text imply to me that you cannot invent new owner names for NSEC. Um, no, at worst it means that when you synthesize an NSEC RR you also have to synthesize something else, eg, a NULL RR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 16:56:49 +0000 Lines: 39 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <20041111160955.764677C@thangorodrim.hactrn.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 18:05:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org In-Reply-To: <20041111160955.764677C@thangorodrim.hactrn.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 11:09 -0500 Rob Austein <sra@isc.org> wrote: >> This text imply to me that you cannot invent new owner names for NSEC. > > Um, no, at worst it means that when you synthesize an NSEC RR you also > have to synthesize something else, eg, a NULL RR. Nope don't think so - that changes wildcard behaviour. I think that's even trivially exploitable, EG $ORIGIN example.com foo IN MX mail-1.evilempire.com * IN MX mail-2.goodempire.com Two users (Evil Ed, and User Ursula), share the same caching resolver. Ursula wants to send mail to bill@fred.example.com Ed works out P(fred.example.com), S(fred.example.com), and queries for them and for fred.example.com. example.com's nameserver returns an NSEC record that mentions fred.example.com, and by your assumption synthesizes not only the NSEC record but also a NULL RR, for fred.example.com. The NULL RR is then cached by the caching nameserver. This means Ursula's mail will NOT go to mail-2.goodempire.com, it will either bounce (as an MX lookup will yield the NULL record), or possibly go to the mail-1.evilempire.com. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 19:03:35 +0000 Lines: 19 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> <6.1.2.0.2.20041111093020.049cbec0@localhost> <53726696A246CF93D3E31D55@[192.168.100.25]> <6.1.2.0.2.20041111105323.04b0a070@localhost> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 20:17:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org In-Reply-To: <6.1.2.0.2.20041111105323.04b0a070@localhost> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 13:55 -0500 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 <ogud@ogud.com> wrote: > DNSSECbis documents are set in stone. > > The WG can issue NEW documents that clearly, coherently and safely > specify changes in DNSSECbis protocol. Thanks :-) (& I agree). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Rob Austein <sra@isc.org> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 14:29:04 -0500 Lines: 52 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <20041111160955.764677C@thangorodrim.hactrn.net> <D0D2E3869BCF337EB20008BB@192.168.100.25> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 20:39:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <D0D2E3869BCF337EB20008BB@[192.168.100.25]> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 11 Nov 2004 16:56:49 +0000, Alex Bligh wrote: > > >> This text imply to me that you cannot invent new owner names for NSEC. > > > > Um, no, at worst it means that when you synthesize an NSEC RR you also > > have to synthesize something else, eg, a NULL RR. > > Nope don't think so - that changes wildcard behaviour. In what way does the existance of a synthetic NULL RRset change the wildcard behavior compared to the behavior if only the synthetic NSEC were present? At least one of us is confused. > > I think that's even trivially exploitable, EG > > $ORIGIN example.com > > foo IN MX mail-1.evilempire.com > * IN MX mail-2.goodempire.com > > Two users (Evil Ed, and User Ursula), share the same caching resolver. > > Ursula wants to send mail to bill@fred.example.com > > Ed works out P(fred.example.com), S(fred.example.com), and queries for them Queries with what QTYPE? > and for fred.example.com. example.com's nameserver returns an NSEC record > that mentions fred.example.com, and by your assumption synthesizes not > only the NSEC record but also a NULL RR, for fred.example.com. The NULL > RR is then cached by the caching nameserver. Given suitable definitions of the P() and S() functions and a suitable choice of RR type (something that is very unlikely to occur in normal use, eg, NULL), the name server in the above scenario has several hints that something evil is going on, and might choose to return RCODE 5 (refused) rather than participating in the attack. :) If for some reason it seems reasonable to return a synthetic NULL RR in such a case (unlikely) it should probably have a TTL of zero. In practice, the only real difference between this and the epsilon solution as already described is that the bit corresponding to the NULL RR type would be turned on in the NSEC bitvector. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 20:47:44 +0000 Lines: 119 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <20041111160955.764677C@thangorodrim.hactrn.net> <D0D2E3869BCF337EB20008BB@192.168.100.25> <20041111192906.B53125A@thangorodrim.hactrn.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 21:58:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org In-Reply-To: <20041111192906.B53125A@thangorodrim.hactrn.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 14:29 -0500 Rob Austein <sra@isc.org> wrote: > At Thu, 11 Nov 2004 16:56:49 +0000, Alex Bligh wrote: >> >> >> This text imply to me that you cannot invent new owner names for NSEC. >> > >> > Um, no, at worst it means that when you synthesize an NSEC RR you also >> > have to synthesize something else, eg, a NULL RR. >> >> Nope don't think so - that changes wildcard behaviour. > > In what way does the existance of a synthetic NULL RRset change the > wildcard behavior compared to the behavior if only the synthetic NSEC > were present? At least one of us is confused. Yes. I am assuming that the reason for the assumption Simon Josefsson mentioned: under section 2.3 of protocol-09: Each owner name in the zone which has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. ... An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner names nodes which were not the owner name of any RRset before the zone was signed. is that NOT doing so would require a change to wildcard behaviour, and thus that in order to support epsilon NSECs, wildcard behaviour would be changed so presence of an NSEC record "only" would not "count" for the purposes of determining whether a wild-card was applicable. If this is the case (i.e. if the appropriate change is made to the wildcard treatment algorithm), then the restrictions in 2.3 can be lifted. However, if NO change to the wildcard processing stuff is made, then as you point out they are equivalent, and (as far as I can see) NSEC epsilons break wildcards. I seem to remember greater minds than mine pointed this out at the time when we were considering NSEC 'white lies' which is why the requirement in section 2.3 never got removed at the time (because we didn't want to fiddle with wildcard processing at that late stage). The reason for the breakage is quite simple: Under NSEC epsilon, every label must have an associated record returned on a query - either it "really" exists (in which case by definition there is a record), or it "really" does not (in which case by assumption - NSEC epilson) there is an epsilon record pointing to the records successor. Under such circumstances, the wildcard record is never the closest encloser of anything (as the closest encloser is either an epsilon NSEC or a real record). So I'd been working under the assumption the wildcard lookup would be changed to exclude NSEC only labels (hence NULL and NSEC aren't equivalent). If my assumption is wrong, then you are indeed right, NULL and NSEC *will* break wildcards - in exactly the same way, and, AFAICT, completely. But I may have missed something here. >> I think that's even trivially exploitable, EG >> >> $ORIGIN example.com >> >> foo IN MX mail-1.evilempire.com >> * IN MX mail-2.goodempire.com >> >> Two users (Evil Ed, and User Ursula), share the same caching resolver. >> >> Ursula wants to send mail to bill@fred.example.com >> >> Ed works out P(fred.example.com), S(fred.example.com), and queries for >> them > > Queries with what QTYPE? Not sure it particularly matters, but let's say ANY. >> and for fred.example.com. example.com's nameserver returns an NSEC record >> that mentions fred.example.com, and by your assumption synthesizes not >> only the NSEC record but also a NULL RR, for fred.example.com. The NULL >> RR is then cached by the caching nameserver. > > Given suitable definitions of the P() and S() functions and a suitable > choice of RR type (something that is very unlikely to occur in normal > use, eg, NULL), the name server in the above scenario has several > hints that something evil is going on, and might choose to return > RCODE 5 (refused) rather than participating in the attack. :) How does that work algorithmically? I can only see heuristic solutions to this, and it's a reasonable attack vector as far as I can see, with potentially disastrous results. If you are trying to change the use of NULL above in wildcard processing, you might as well just change the wording and the wildcard algorithm for NSEC instead and drop 2.3. NULL is actually USEFUL to indicate an exception to a wildcard, as someone (Ed Lewis I think) pointed out to me here not so long ago. > If for some reason it seems reasonable to return a synthetic NULL RR > in such a case (unlikely) it should probably have a TTL of zero. > > In practice, the only real difference between this and the epsilon > solution as already described is that the bit corresponding to the > NULL RR type would be turned on in the NSEC bitvector. Why not just except NSECs from the wildcard algorithm, and drop the text in 2.3? That's useful for both NSEC epsilon and NSEC' hashes. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 22:19:13 +0000 Lines: 55 References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 23:29:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Thu, 11 Nov 2004 13:04:26 +0100." <iluy8h8h9rp.fsf@latte.josefsson.org> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson <jas@extundo.com> wrote: > I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. > ... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. ... > I maintain that the MUST cannot in general be verified by clients, and > hence should not be part of the specification. Further I believe that > the text prevent deployment of NSEC alternatives. i agree with the first part of this. the specification should include no server constraints beyond those that will be invisible to clients. i do not agree with the second part of this. nsec alternatives will be developed, and they might take advantage of errors in the original specs (like proscriptions against server side activities which weren't distinguishable by clients). in other words, this is a loophole, let's drive a truck through it. Alex Bligh <alex@alex.org.uk> wrote: > So I'd been working under the assumption the wildcard lookup would > be changed to exclude NSEC only labels (hence NULL and NSEC aren't > equivalent). If my assumption is wrong, then you are indeed right, > NULL and NSEC *will* break wildcards - in exactly the same way, > and, AFAICT, completely. > > But I may have missed something here. i think you missed two things. first, see above. in this case the loophole created by the dnssec-bis spec error (that of outlawing something in the server that will not affect the client or be distinguishable to the client) allows you to simply say, in a later spec, that a server who "violates" this provision of dnssec-bis by creating on-the-fly NSECs for with epsilon names at nodes with no real (unsynthesized) rrsets, must treat the zone as having no rrsets at these synthetic names, for all purposes related to wildcards. second, your argument pertains to a zone signer, which changes zone content. in the case of an on-the-fly signer, which does not change zone content, it is very possible to get exactly the treatment we'll probably want, without invalidating any conforming clients of the dnssec-bis protocol. (i wish i wasn't such an expert at exploting loopholes in specifications...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 23:19:43 +0000 Lines: 40 References: <20041111221913.26B5E13E69@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 00:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041111221913.26B5E13E69@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 22:19 +0000 Paul Vixie <paul@vix.com> wrote: > second, your argument pertains to a zone signer, which changes zone > content. in the case of an on-the-fly signer, which does not change zone > content, it is very possible to get exactly the treatment we'll probably > want, without invalidating any conforming clients of the dnssec-bis > protocol. Assuming we cache NSEC records, which is presumably desirable, what prevents a caching resolver relying on a cached NSEC to fail to match an otherwise closest enclosing wildcard? IE how the wildcard spec is written at the moment, if a resolving client sees foo IN NSEC bar in example.com, it should not match a query for QNAME=foo.example.com., QTYPE=MX against * IN NSEC baz Right? In which case, if bar=S(foo) and foo does not exist in the unsynthesized zone, the above is easy enough for a miscreant to put in the nameserver yes? I agree if there is a hole in the original spec (i.e. the original spec is too prescriptive) we can drive a truck through it, but I thought the original prescription that NSEC records only exist where other non-NSEC labels exist was there for a well-defined reason (so not to break wildcards) - IE I don't think this /is/ a hole. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 01:00:47 +0000 Lines: 33 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 02:10:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Thu, 11 Nov 2004 23:19:43 GMT." <82B8F39F152DE9ED339E597A@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... your argument pertains to a zone signer, which changes zone > > content. in the case of an on-the-fly signer, which does not change > > zone content, it is very possible to get exactly the treatment we'll > > probably want, without invalidating any conforming clients of the > > dnssec-bis protocol. > > Assuming we cache NSEC records, which is presumably desirable, what > prevents a caching resolver relying on a cached NSEC to fail to match > an otherwise closest enclosing wildcard? caches don't match wildcards. only an authority server can do that. otherwise a server who had cached "*.dom" and "foo.dom" might decide that a query for "bar.dom" matched the while card, even if in the authority server, "bar.dom" actually exists. (not that a synthetic rr would have a nonzero ttl in the first place.) > I agree if there is a hole in the original spec (i.e. the original > spec is too prescriptive) we can drive a truck through it, but I thought > the original prescription that NSEC records only exist where other > non-NSEC labels exist was there for a well-defined reason (so not to > break wildcards) - IE I don't think this /is/ a hole. nope. it was an oversight. at least two editors admitted this to me in person when i said "hey wait, we can't ship this to the iesg without relaxing the parts that proscribe synthetic epsilon-named nsec rr's" but the second of the two was able to explain how, actually, we could and must. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 17:10:10 +0000 Lines: 53 References: <20041112010047.B87EA13E26@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 18:23:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041112010047.B87EA13E26@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 12 November 2004 01:00 +0000 Paul Vixie <paul@vix.com> wrote: > caches don't match wildcards. only an authority server can do that. > otherwise a server who had cached "*.dom" and "foo.dom" might decide > that a query for "bar.dom" matched the while card, even if in the > authority server, "bar.dom" actually exists. > > (not that a synthetic rr would have a nonzero ttl in the first place.) OK. Let me simplify a bit, drop the caching nameservers, and at the risk of looking stupid: Take a zone example.com: * IN MX foo bar IN MX baz dummy IN NULL dummy2 IN TXT "fred" It uses NSEC epsilon. That means for every possible label, there is a synthetic NSEC record, and per Rob's proposal, also a synthetic NULL record. Synthetic I am taking to mean "not in the original zone loaded into the nameserver, but created algorithmically so it appears under all other circumstances to be in the zone" I then make the following queries: 1. type=NSEC, label=xxx.example.com 2. type=MX, label=xxx.example.com 3. type=ANY, label=xxx.example.com 4. type=MX, label=dummy.example.com 5. type=MX, label=dummy2.example.com What do I get? Surely type 1 HAS to return (at least) xxx IN NSEC S(xxx) or the whole epsilon NSEC stuff doesn't work Surely (2) is indistinguishable from (4) if there is a NULL record synthesized? Surely (2) is indistinguishable from (4) and (5) unless NSECs are processed differently from NULL's in the wildcard algorithm? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 17:34:37 +0000 Lines: 64 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 18:43:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Fri, 12 Nov 2004 17:10:10 GMT." <66805DF7731B03771BE327B8@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... > > (not that a synthetic rr would have a nonzero ttl in the first place.) > > OK. Let me simplify a bit, drop the caching nameservers: > > Take a zone example.com: > * MX foo > bar MX baz > dummy NULL > dummy2 TXT "fred" > > It uses NSEC epsilon. That means for every possible label, there is a > synthetic NSEC record, and per Rob's proposal, also a synthetic NULL > record. Synthetic I am taking to mean "not in the original zone > loaded into the nameserver, but created algorithmically so it appears > under all other circumstances to be in the zone" with the proviso that i didn't understand the need for a NULL RR, i'm tracking you so far. > I then make the following queries: > 1. type=NSEC, label=xxx.example.com > 2. type=MX, label=xxx.example.com > 3. type=ANY, label=xxx.example.com > 4. type=MX, label=dummy.example.com > 5. type=MX, label=dummy2.example.com > > What do I get? > > Surely type 1 HAS to return (at least) > xxx IN NSEC S(xxx) > or the whole epsilon NSEC stuff doesn't work given that there is a wildcard, there will be no NXDOMAINs for this zone. therefore every NSEC will have a real owner name. so, i'm with you so far. each of queries (1), (2), and (3) will produce the same NSEC result, but with different RRtypes claimed at the ownername. which is another very fine reason why client-side negative caching based on previously cached NSEC RRs won't work, and thus i renew my claim that wildcarding should be done on the client side rather than the server side. (but that's a different windmill.) > Surely (2) is indistinguishable from (4) if there is a NULL record > synthesized? i don't know why you'd ever synthesize a NULL RR. i don't like NULL RRs at all, but in your example you made the NULL RR a real RR, not a synthetic one. therefore query (4) would get a NOERROR/NODATA reply and the wildcard would not be part of the choice of what to return -- because the qname actually does exist. > Surely (2) is indistinguishable from (4) and (5) unless NSECs are > processed differently from NULL's in the wildcard algorithm? response to (5) would be NOERROR/NODATA as with (4). i appear to be lost. can we have this discussion over again, except this time can you do it without the synthetic NULL RRs, and can you explain the non-dnssec parts of each reply so i'll know what covering dnssec metadata will be applied? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Sat, 13 Nov 2004 15:16:18 +0000 Lines: 89 References: <20041112173437.0BB4813E64@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Nov 13 16:29:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041112173437.0BB4813E64@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul, >> OK. Let me simplify a bit, drop the caching nameservers: >> >> Take a zone example.com: >> * MX 10 foo >> bar MX 10 baz >> dummy NULL >> dummy2 TXT "fred" >> www IN A 1.1.1.1 >> zzz IN A 2.2.2.2 >> >> It uses NSEC epsilon. That means for every possible label, there is a >> synthetic NSEC record, and per Rob's proposal, also a synthetic NULL >> record. Synthetic I am taking to mean "not in the original zone >> loaded into the nameserver, but created algorithmically so it appears >> under all other circumstances to be in the zone" > > with the proviso that i didn't understand the need for a NULL RR, i'm > tracking you so far. OK, Rob Austein suggested synthesizing a NULL RR to avoid changing the requirements of 2.3 - I was pointing out that didn't help. So let us assume for the minute *NO* NULL RR's are synthesized (i.e. it operates in breach of 2.3 but we hope this doesn't cause any harm). >> I then make the following queries: >> 1. type=NSEC, label=xxx.example.com >> 2. type=MX, label=xxx.example.com >> 3. type=ANY, label=xxx.example.com >> 4. type=MX, label=dummy.example.com >> 5. type=MX, label=dummy2.example.com >> >> What do I get? >> >> Surely type 1 HAS to return (at least) >> xxx IN NSEC S(xxx) >> or the whole epsilon NSEC stuff doesn't work > > given that there is a wildcard, there will be no NXDOMAINs for this zone. > therefore every NSEC will have a real owner name. so, i'm with you so > far. ... > response to (5) would be NOERROR/NODATA as with (4). i appear to be lost. > can we have this discussion over again, except this time can you do it > without the synthetic NULL RRs, and can you explain the non-dnssec parts > of each reply so i'll know what covering dnssec metadata will be applied? OK, so I think what should happen WITHOUT epsilon signing - i.e. if normal NSEC records are put in (note I've stuck a couple more records in to make it obvious) is something like: 1. My mind is fried and I know can't work out what that returns but it's not relevant for the point 2. xxx IN MX foo 3. xxx IN MX foo 4. NOERROR/NODATA 5. NOERROR/NODATA With epsilon signing, there is an NSEC record for every possible label query (either synthesized or not). So, queries (2), and (3) should hit a zone with RR's against the label "xxx", something like xxx NSEC S(xxx) but no RR of type MX. Therefore, *if the current DNSSEC-bis lookup algorithm is followed*, the presence of an RR of any type (even NSEC) will result in that RR being the closest encloser for xxx, and (2) should thus return NOERROR/NODATA as the closest encloser has no RR of type MX. This thus breaks wildcard MX (and as far as I can tell this was the reason for 2.3). The solution of course is for the server NOT to count NSEC records (or at least synthetic NSEC records) as closest enclosers. If no NSEC records are considered closest enclosers (at least for QTYPES other than NSEC), then 2.3 can be dropped in its entirety as far as I can see, and this also helps with some of the arguments against hashed NSEC' sharing the same namespace and interfering with wildcards. Perhaps I'm making some mistake here. My point to Rob was that adding NULL RR's to give technical conformance of synthentic NSEC's to 2.3 does not help as they equally break wildcards and cannot be excepted in the same manner from closest encloser rules (i.e. it makes things worse). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Sat, 13 Nov 2004 20:43:51 +0000 Lines: 45 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Nov 13 21:57:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sat, 13 Nov 2004 15:16:18 GMT." <96FDE9312D5CDA02D5DB2D65@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > With epsilon signing, there is an NSEC record for every possible label > query (either synthesized or not). no, it matters whether it's synthesized or not. if there's a real nsec rr then it would have an impact on the wildcard search algorythm. a synthetic nsec rr, being made from whole cloth, can be defined as having no impact on the wildcard search algorythm. this is possible only because the synthesis and the wildcard search are both done in the authority server. > ... The solution of course is for the server NOT to count NSEC records > (or at least synthetic NSEC records) as closest enclosers. yes. > If no NSEC records are considered closest enclosers (at least for > QTYPES other than NSEC), then 2.3 can be dropped in its entirety as > far as I can see, and this also helps with some of the arguments > against hashed NSEC' sharing the same namespace and interfering with > wildcards. not unless the hashed nsec's were synthetic. we REALLY needed slabs before security, to keep all the security metadata completely out of the dns world view. if you want to define NSEC2/NSEC3/whatever as having no effect on the wildcard search algorythm, you'll have to do so explicitly, and carefully. > Perhaps I'm making some mistake here. your thinking on this topic is very creative. i'm only able to fault you on matters of terminology and for occasionally forgetting which constraints will be in effect under which circumstances. please do continue. > My point to Rob was that adding NULL RR's to give technical > conformance of synthentic NSEC's to 2.3 does not help as they equally > break wildcards and cannot be excepted in the same manner from closest > encloser rules (i.e. it makes things worse). i don't think rob intended his offhand mention of NULL RRs to be given as much scrutiny as you have done. if it's not a helpful approach, abandon it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Niall O'Reilly <niall.oreilly@ucd.ie> Subject: Re: online signing draft Date: Sat, 13 Nov 2004 21:42:31 +0000 Lines: 56 References: <4190EA21.8010205@algroup.co.uk> <20041111095403.8ED62E7E50@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Niall O'Reilly <niall.oreilly@ucd.ie> X-From: owner-namedroppers@ops.ietf.org Sat Nov 13 22:50:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-reply-to: <20041111095403.8ED62E7E50@mx1.nominet.org.uk> To: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.619) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 11 Nov 2004, at 09:54, Geoffrey Sisson wrote: > Now available at: > > http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-00.txt IMO, a refinement to the notation " non-printable octet values are expressed as three-digit octal numbers preceded by a backslash " allowing a decimal repeat count in parens between the backslash and the first of the three octal digits would immensely enhance readability. As a consequence, any unwittingly-introduced errors would be more easily noticed. For example, in the first example in section 5.1, x' = \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377.\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377.\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377.fon\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377.exa\ mple.com. could then be represented as x' = \(50)377.\(63)377.\(63)377.fon\(60)377.example.com. if I've counted all those octal-encoded octets correctly. Best regards, Niall O'Reilly PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Andras Salamon <andras@dns.net> Subject: Re: online signing draft Date: Sun, 14 Nov 2004 13:32:08 +0200 Lines: 68 References: <Pine.GSO.4.55.0411081817130.15465@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 12:42:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <Pine.GSO.4.55.0411081817130.15465@filbert> User-Agent: Mutt/1.5.6i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Nov 08, 2004 at 06:28:08PM -0500, Samuel Weiler wrote: > Minimally Covering NSEC Records and DNSSEC On-line Signing > draft-weiler-dnsext-dnssec-online-signing-00.txt > > This document presents a way to prevent zone walking by > constructing NSEC records that cover fewer names. These records > can make zone walking take approximately as many queries as simply > asking for all possible names in a zone, making zone walking > impractical. Let n(Z) be the size of zone Z, f(Z) be the number of queries typically generated by a brute force enumeration of zone Z, and k(Z) be the number of enumerations sought each day by people trying to enumerate zone Z, and we have been told previously that k(Z) is likely to be a number in the hundreds (if not more). Usually f(Z) >> n(Z). With online-signing-00, we are then back to O(f(Z)*k(Z)) daily queries being sent to name servers authoritative for zones Z, just like today. However, today without DNSSEC each query costs O(1) time to generate and O(1+log n(Z)) time to answer. With online signing, we still have each query costing time O(1) but answers now costing O(q+1+log n), where q is a constant dependent on the length of the encryption key and the server's crypto hardware accelerator. As far as I can tell, this is at least an order of magnitude more work for the servers, given usual values of the constant q. This breaks requirement 15 (minimisation of asymmetry) in signed-nonexistence-requirements-00. Given requirement 15, shouldn't we also revisit increasing the time on the _query_ side of DNSSEC, so each query takes time O(q) to generate and process? As far as I can see, there will always be asymmetry if one can make a trivial distinction between positive and negative answers. After all, an enumerator isn't interested in verifying signatures on responses. Precomputed NSEC records are a way to keep the server side cost down to O(1), but allow enumeration if there are only O(n(Z)) precomputed records, or otherwise require infeasibly large space, approaching f(Z). In DNSSEC-ter, could we not drop this distinction, and instead always return responses to queries, accompanied by indicator records which have to be decrypted to determine if the response is actually a dummy? These records would indicate whether the response is a dummy, and if not they would serve the same function as NSEC records. A www.example.com? -> www.example.com. A 10.0.0.1 ISEC <encrypted indicator, null> A wwx.example.com? -> wwx.example.com. A 127.0.1.2 ISEC <encrypted indicator, cf. NSEC> However, I don't yet see how in the above scheme responses could be chosen to always be "harmless" without being identifiable by an enumerator as being negative responses (eg. IPv4 addresses in the block 127/8 as above). The other alternative seems to be to find a way to generate and store at least O([n(Z)]^2) precomputed signed NSEC responses. For zones with 1m domain names, this doesn't seem feasible either. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Sun, 14 Nov 2004 13:07:23 +0000 Lines: 96 References: <20041113204351.9747013E1D@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 14:14:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041113204351.9747013E1D@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 13 November 2004 20:43 +0000 Paul Vixie <paul@vix.com> wrote: >> With epsilon signing, there is an NSEC record for every possible label >> query (either synthesized or not). > > no, it matters whether it's synthesized or not. if there's a real nsec rr > then it would have an impact on the wildcard search algorythm. a > synthetic nsec rr, being made from whole cloth, can be defined as having > no impact on the wildcard search algorythm. this is possible only > because the synthesis and the wildcard search are both done in the > authority server. [1] > >> ... The solution of course is for the server NOT to count NSEC records >> (or at least synthetic NSEC records) as closest enclosers. > > yes. > >> If no NSEC records are considered closest enclosers (at least for >> QTYPES other than NSEC), then 2.3 can be dropped in its entirety as >> far as I can see, and this also helps with some of the arguments >> against hashed NSEC' sharing the same namespace and interfering with >> wildcards. > > not unless the hashed nsec's were synthetic. OK. I am now going to play your game of driving a truck but this time through a hole you created :-) If you are correct with [1] above, and there is no reason to doubt you, then your assertion works because the epsilon NSECs are created by the authority server according to a specific algorithm. Provided that the algorithm is used, the resolver would have no way of telling whether they are in fact synthetic NSECs, or whether they aren't. So, for example, the zone I create and give to the authority server could have (and I'm assuming S(foo)=foo\000, S(foo\000)=foo\000\000 etc.) * IN MX 2.2.2.2 foo IN A 1.1.1.1 foo IN NSEC foo\000 [A] foo\000 IN NSEC foo\000\000 [B] The authority server would produce synthetic NSECs (for instance foo\000\000 IN NSEC fooo\000\000\000 [C] But I can't see a resolver can tell the difference. That doesn't matter because (as you say) the wildcard search (which is the only thing it matters to we think) is carried out on the authoritative server. Now given these NSEC records have to be signed, there is nothing (it seems to me) to stop us saying hashed NSEC' records are the same. They could all be created on the authoritative server, and all signed on the authoritative server. In that way, the authoritative server can exclude them from the wildcard lookup algorithm. And if that's the case, then you can use the same argument I've used above to say that NSEC' records could IN FACT not be synthesized - they could come from the original zone, and still omitted from the wildcard lookup algorithm - the resolver wouldn't be able to tell the difference. IE, if you can get away with an authoritative server treating synthetic NSEC epsilon records differently in terms of the wildcard lookup algorithm, then as far as I can see, logically the same must be true of non-synthetic NSEC' hash records. In which case we know that removing the requirement in 2.3 and amending the wildcard search algorithm to remove hashed NSEC' records is not going to be problematic. I would add that you might as well remove the requirement for NSEC records (as opposed to hashed NSEC' records) to be treated that way, except that in the above example there is I suppose a theoretical need for a QTYPE=MX query on the zone to produce a different result for QLABEL=foo\000 and QLABEL=foo\000\000 (as only one is synthetic). [Note, side argument: I am not sure that we should not in that case not have put a note to the effect that resolvers should not rely on servers following 2.3: just as we are driving a truck through what we think an open hole in that 2.3 can be violated because the resolvers must fulfil other parts of the specification and not, for instance, do their own local optimizations for wildcard searches by relying on (say) cached records, others writing from the resolver end may conclude that in fact THAT restriction is a whole in the spec THEY can drive a truck through because it doesn't matter if they violate rule (X) because all servers will be following the restrictions in 2.3 so breaking rule X won't damage anything will it? - visions of 2 trucks driving through dark holes and colliding in the middle] Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: online signing draft Date: Sun, 14 Nov 2004 13:32:44 +0000 Lines: 92 References: <Pine.GSO.4.55.0411081817130.15465@filbert> <20041114113208.GA29061@dns.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 14:37:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net>, namedroppers@ops.ietf.org In-Reply-To: <20041114113208.GA29061@dns.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 November 2004 13:32 +0200 Andras Salamon <andras@dns.net> wrote: > With online-signing-00, we are then back to O(f(Z)*k(Z)) daily queries > being sent to name servers authoritative for zones Z, just like today. > > However, today without DNSSEC each query costs O(1) time to generate and > O(1+log n(Z)) time to answer. With online signing, we still have each > query costing time O(1) but answers now costing O(q+1+log n), where q is > a constant dependent on the length of the encryption key and the server's > crypto hardware accelerator. Actually a ratio of that constant to the processor time to do a lookup. IE as its O() it depends on the relative speed of lookups to crypto. > As far as I can tell, this is at least > an order of magnitude more work for the servers, given usual values of > the constant q. As you say, depends on q and log n, but yes. > This breaks requirement 15 (minimisation of asymmetry) > in signed-nonexistence-requirements-00. Yes. The other side of the same coin is it is trivial to perform an effective denial of service attack by querying random QNAMEs. Whilst one might chose to drop ones that don't (say) have LNH composition in high load environments, zones are normally sufficiently sparse that it would be possible to generate unique (i.e. uncachable authoritative server side) queries that are distinctly plausible. For instance, 6 letter strings have over 10^10 combinations, and [consonant][vowel][consonant][vowel][consonant][vowel] [consonant][vowel][consonant][vowel][consonant][vowel][consonant] has over 10^13 combinations. Cycling through those from sufficient parallelized zombies will, I would have thought, saturate any crypto processor. Whilst it's possible to start dropping synthetic NSECs (apparently acceptable to some as "authenticated denial is less important" - to them), that's a ridiculous argument as you might as well just go with opt-in if that were the case and drop the crypto processor requirements and script kiddie opportunity. > Given requirement 15, shouldn't we also revisit increasing the time on > the _query_ side of DNSSEC, so each query takes time O(q) to generate > and process? That assume that the solution you want on the resolver side does have an element that takes O(q) time to process! Whilst the latter is possible, I'm not sure it is desirable, not least because of the asymmetry problem. I'm not sure whether you are just suggesting this as a straw man, but saying we'll make all queries more resource intensive, because by only making minimal changes to the protocol we've been left with making some responses more resource intensive, and otherwise there will be asymmetry, to me suggests that we have to look beyond minimal changes to the protocol. > As far as I can see, there will always be asymmetry if one can make a > trivial distinction between positive and negative answers. After all, > an enumerator isn't interested in verifying signatures on responses. > Precomputed NSEC records are a way to keep the server side cost down to > O(1), but allow enumeration if there are only O(n(Z)) precomputed records, > or otherwise require infeasibly large space, approaching f(Z). > > In DNSSEC-ter, could we not drop this distinction, and instead always > return responses to queries, accompanied by indicator records which > have to be decrypted to determine if the response is actually a dummy? > These records would indicate whether the response is a dummy, and if > not they would serve the same function as NSEC records. > > A www.example.com? -> > www.example.com. A 10.0.0.1 > ISEC <encrypted indicator, null> > > A wwx.example.com? -> > wwx.example.com. A 127.0.1.2 > ISEC <encrypted indicator, cf. NSEC> Perhaps I am missing something here, but now rather than do f(Z) cheap queries, does the attacker not instead have to do n(Z) expensive queries? (i.e. he can work his way through the zone by enumeration, but has to decrypt each answer). Assuming the decryption is about as hard as the online signing, and f(Z) >> n(Z) (as you yourself posit), doesn't this make the job rather easier for the attacker? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: online signing draft Date: Sun, 14 Nov 2004 14:41:00 +0000 (GMT) Lines: 34 References: <EBCA3DAB-35BC-11D9-880A-000393B02BAC@ucd.ie> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 15:48:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <EBCA3DAB-35BC-11D9-880A-000393B02BAC@ucd.ie> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Niall O'Reilly <niall.oreilly@ucd.ie> writes: > IMO, a refinement to the notation > > " non-printable octet values are expressed as three-digit octal > numbers preceded by a backslash " > > allowing a decimal repeat count in parens between the backslash and the > first of the three octal digits would immensely enhance readability. . . . > could then be represented as > > x' = \(50)377.\(63)377.\(63)377.fon\(60)377.example.com. I'd considered using something similar to regexp notation to represent the examples, e.g.: x' = \377{50}.\377{63}.\377{63}.fon\377{60}.example.com. . . . but was reluctant to lose the `tangibility' of the unabridged examples. Your suggestion makes me think that the draft probably should have both; I'll change this in -01. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Sun, 14 Nov 2004 20:02:36 +0000 Lines: 116 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 21:14:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sun, 14 Nov 2004 13:07:23 GMT." <1C3176DB8286514F3DFFE7CC@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > no, it matters whether it's synthesized or not. if there's a real nsec rr > > then it would have an impact on the wildcard search algorythm. a > > synthetic nsec rr, being made from whole cloth, can be defined as having > > no impact on the wildcard search algorythm. this is possible only > > because the synthesis and the wildcard search are both done in the > > authority server. [1] > > OK. I am now going to play your game of driving a truck but this time > through a hole you created :-) If you are correct with [1] above, and > there is no reason to doubt you, ... every extension to every protocol relies on creative interpretation of what were previously undefined or illegal symbol patterns. EDNS depends on ADCOUNT>0 in initiatorgrams (queries, updates, etc), which was not a legal pattern in DNS. once you've figured out a way to signal something that will only be visible and valid to participants who understand it, you've got your loophole. everything after that is just whiteboarding. > ... then your assertion works because > the epsilon NSECs are created by the authority server according to > a specific algorithm. Provided that the algorithm is used, the resolver > would have no way of telling whether they are in fact synthetic NSECs, > or whether they aren't. now you're getting into the spirit of this thing. welcome to the dark side. what you have to define is how the authority servers will act. given dns's insane notion of authority-side-synthesis for wildcards, you just have to make sure that the synthesis of wildcards and the sythesis of NSECs are done in a way that queriers see what you want them to see. it will require that all authority servers for a given zone understand the same zone semantics, but DNSSEC-bis also has this requirement, so extending it to cover synthetic NSEC (and later, DNSSEC-ter) is completely reasonable. you may have to add some kind of format versioning, so that old-semantics authority servers will refuse to load and serve new-semantics zones. (we didn't do this in DNSSEC-bis, and a lot of master/slave relationships are going to become stressful as a result.) > So, for example, the zone I create and give to the authority server > could have (and I'm assuming S(foo)=foo\000, S(foo\000)=foo\000\000 etc.) > * IN MX 2.2.2.2 > foo IN A 1.1.1.1 > foo IN NSEC foo\000 [A] > foo\000 IN NSEC foo\000\000 [B] > > The authority server would produce synthetic NSECs (for instance > foo\000\000 IN NSEC fooo\000\000\000 [C] > > But I can't see a resolver can tell the difference. That doesn't matter > because (as you say) the wildcard search (which is the only thing it > matters to we think) is carried out on the authoritative server. yup. being able to take advantage of the authority-side wildcard synthesis insanity is a wonderful benefit after all the pain and cost that's been paid by DNSSEC for said insanity up until now. > Now given these NSEC records have to be signed, there is nothing (it seems > to me) to stop us saying hashed NSEC' records are the same. They could all > be created on the authoritative server, and all signed on the authoritative > server. In that way, the authoritative server can exclude them from the > wildcard lookup algorithm. yes. > And if that's the case, then you can use the same argument I've used above > to say that NSEC' records could IN FACT not be synthesized - they could > come from the original zone, and still omitted from the wildcard lookup > algorithm - the resolver wouldn't be able to tell the difference. yes. > IE, if you can get away with an authoritative server treating synthetic > NSEC epsilon records differently in terms of the wildcard lookup > algorithm, then as far as I can see, logically the same must be > true of non-synthetic NSEC' hash records. yes. > In which case we know that removing the requirement in 2.3 and amending > the wildcard search algorithm to remove hashed NSEC' records is not > going to be problematic. right. > I would add that you might as well remove the requirement for NSEC > records (as opposed to hashed NSEC' records) to be treated that way, > except that in the above example there is I suppose a theoretical need > for a QTYPE=MX query on the zone to produce a different result for > QLABEL=foo\000 and QLABEL=foo\000\000 (as only one is synthetic). also, it's too late. this is one of many ideas that might have improved DNSSEC-bis but would have added more years to its schedule, so while we will miss the functionality, we will not be sorry we shipped without it. > [Note, side argument: I am not sure that we should not in that case not > have put a note to the effect that resolvers should not rely on servers > following 2.3: just as we are driving a truck through what we think > an open hole in that 2.3 can be violated because the resolvers must > fulfil other parts of the specification and not, for instance, do > their own local optimizations for wildcard searches by relying on > (say) cached records, others writing from the resolver end may conclude > that in fact THAT restriction is a whole in the spec THEY can drive > a truck through because it doesn't matter if they violate rule (X) because > all servers will be following the restrictions in 2.3 so breaking > rule X won't damage anything will it? - visions of 2 trucks driving > through dark holes and colliding in the middle] the DNSSEC-bis documents overspecify a number of things, including this, and i expect they will be edited to be more minimal before they can reach the next bus-stop on the standards track. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Andras Salamon <andras@dns.net> Subject: Re: online signing draft Date: Mon, 15 Nov 2004 11:56:48 +0200 Lines: 57 References: <Pine.GSO.4.55.0411081817130.15465@filbert> <20041114113208.GA29061@dns.net> <0DB4EC63628DA3B1286BC1EF@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 11:07:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <0DB4EC63628DA3B1286BC1EF@[192.168.100.25]> User-Agent: Mutt/1.5.6i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Nov 14, 2004 at 01:32:44PM +0000, Alex Bligh wrote: > >Given requirement 15, shouldn't we also revisit increasing the time on > >the _query_ side of DNSSEC, so each query takes time O(q) to generate > >and process? > > That assume that the solution you want on the resolver side does have an > element that takes O(q) time to process! Whilst the latter is possible, I'm > not sure it is desirable, not least because of the asymmetry problem. It seems the way to fix asymmetry is either to reduce the server side time, or to increase the resolver side time: so why is increasing resolver side time not desirable? > I'm > not sure whether you are just suggesting this as a straw man, but saying > we'll make all queries more resource intensive, because by only making > minimal changes to the protocol we've been left with making some responses > more resource intensive, and otherwise there will be asymmetry, to me > suggests that we have to look beyond minimal changes to the protocol. I'm struggling to follow your reasoning here. I was trying to look at _how_ the resolver side could be made to incur O(q) time, without mandating major changes to resolvers which are uninterested in the additional DNSSEC information. Overall, I am tending toward your conclusion that major protocol changes may be required if asymmetry is to be avoided. The one solution I put forward relies on returning RRs for non-existent domain names, which seems to lead to unsafe values being returned, or otherwise allows trivial recognition. The other solution would require a very large number of precomputed signed negative answers. There may be other, smarter ways of going forward. Any further ideas for solving the asymmetry problem, or for rigorously showing it can't be solved while keeping backward compatibility? > >In DNSSEC-ter, could we not drop this distinction, and instead always > >return responses to queries, accompanied by indicator records which > >have to be decrypted to determine if the response is actually a dummy? > >These records would indicate whether the response is a dummy, and if > >not they would serve the same function as NSEC records. > > Perhaps I am missing something here, but now rather than do f(Z) cheap > queries, does the attacker not instead have to do n(Z) expensive queries? I should have explicitly mentioned that I was thinking of epsilon semantics for NSEC records when I wrote the above, ie. f(Z) expensive queries would be required. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: David Fort <david.fort@irisa.fr> Subject: Re: On dynamic NSEC Date: Mon, 15 Nov 2004 11:13:08 +0100 Lines: 125 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050501050400090705040300" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 11:20:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> X-Virus-Scanned: by amavisd-new at irisa.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050501050400090705040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Simon Josefsson wrote: >Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > > > >>[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it >>on the fly. minimally cover. idea has been posted to ML. not in >>archive. use NSEC mechanism, good things, can use current resolvers >>to validate. would mean can deploy DNSSECbis without enumeration >>properties, if can implement this in server.... >> >> >... > > >>[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this >>group, review, try to see if will work, publish asap. so that things >>can be deployed today. in same time, continue on other solutions, >>without makeing choices. >> >> > >There seem to be some assumption that online signing of dynamically >generated NSEC with "epsilon" domains coexist with DNSECbis. > >I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. >... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. > > > [...] Correct me if i'm wrong, but the current NSEC allows to prove that a domain is an Empty Non-Terminal domain. The dynamic NSEC proposed in that draft prevent from doing this. Isn't that a problem ? -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T�l: +33 (0) 2 99 84 71 33 --------------050501050400090705040300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title>

From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Mon, 1 Nov 2004 08:35:01 +0100 Lines: 193 X-From: owner-namedroppers@ops.ietf.org Mon Nov 01 08:48:57 2004 Return-path: To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.496783 / -5.9 X-RIPE-Signature: e4de494b639be15a0684369688ad923b Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt) Date: Wed, 3 Nov 2004 15:04:49 +0100 Organization: RIPE NCC Lines: 91 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 15:21:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: James Snell <jasnell@gmail.com> In-Reply-To: <2bcdc7c404102513103b6b1891@mail.gmail.com> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.172480 / -5.9 X-RIPE-Signature: 0cba5f0e5794ca24e4328f35964c33bf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello James and Andrew, I have been reading your draft. Having very little experience with the web-services architecture there are a few things that I cannot get my finger behind. The first question I have is on EPR. It is triggered by having possible redirection ( WDSL URL or an XML RR), why not simply always redirect to a WSDL document describing the service? It may make life much easier if the web service descriptions are dynamic in nature. You will not need to bother with caching and other DNS data propagation effects such as secondary DNS servers not updating in time. I do not feel comfortable with the XML RR. It has more or less the same properties as the TXT RR. It has no limitations and may cause people to put all kinds of things in the XML RR, such as internet-draft XML source (interesting idea :-) ). If there is a possibility for redirection I do not understand why the XML RR would be needed, what is the perceived benefit? I also have a more detailed questions and remarks about the RRs. 1. I think that some of the EPR RDATA elements can be split into their functional parts. For instance the PortType QNAME (confusing name for a data element in the context of DNS :-) ) could be encoded as: |length|namespace-uri|length|localpart 2. It is not clear to me why the separator "_ws" is needed in the proposed owner names of EPR records {name}._ws.{domain}. Both client and server will know which part of the name is intended to be the domain part and which part will be the name part. Dropping _ws could introduce an ambiguity (If there exists both a "inquire.uddi" and a "inquire" service and the "inquire.uddi" service has been implemented for the "example.com" domain and the "inquire" service has been implemented for the "uddi.example.com" domain.) But that ambiguity one could solve by adding a simple counter in the RDATA that tells us at which label the split between name and domain occurs. The DNSSIG RR uses a similar mechanism to indicate to indicate which part of a domain name has been synthesized. 3. Section 2.3.1. "DNS implementations MUST send the XML data using the encoding specified by the encoding byte flag". DNS implementations will send binary RDATA, they will never look at the content of the RDATA before putting information on the wire. The encoding flag can only be used as an indicator to the client interpreting the RDATA on what the binary RDATA is representing. Most of the MUSTs in this paragraphs are not enforcable and probably should be SHOULDs. (most of them relate to language that enforces implementers to strip the XML cruft before putting it into the RDATA). 4. Editing nit: most of your example RRs span multiple lines, you should use brackets to indicate this mystock._ws.example.com XML 0 <EndpointReference ( xmlns="..." .... </EndpointReference> ) Olaf Kolkman namedropper (no hats) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Wildcard Clarify 4 Date: Wed, 3 Nov 2004 16:39:55 +0100 Organization: RIPE NCC Lines: 850 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 16:58:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.500000 / -1.0 X-RIPE-Signature: b27956e900b50eef81638c80ab192347 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, For some reason wcard-clarify-04 did not make it into the repository. We think it is important to base discussions next week on the latest version, so here it is. (Note that on the agenda we refer to version 3, but it is version 4 that will be discussed.). --Olaf DNSEXT Co-Chair. --------- DNSEXT Working Group E. Lewis INTERNET DRAFT NeuStar Expiration Date: April 25, 2005 October 2004 Clarifying the Role of Wild Card Domains in the Domain Name System draft-ietf-dnsext-wcard-clarify-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and not to significantly alter the spirit or intent of that definition. 1 Introduction In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis of answers from special records called wildcards. The original definitions are incomplete. This document clarifies and describes the wildcard synthesis by adding to the discussion and making limited modifications. Modifications are made only where necessary to close inconsistencies that have led to interoperability issues. 1.1 Motivation Over time many implementations have diverged in different ways from the original definition, or at from least what had been intended. Although there is clearly a need to clarify the original documents in light of this, the impetus for this document lay in the engineering of the DNS security extensions [RFC TBD]. With an unclear definition of wildcards the design of authenticated denial became entangled. Although this document is motivated by DNSSEC and the need to have a separate document passed for the sake of DNSSEC, other motivations have arisen. The renewed understanding of wildcards gained is worthy of being documented. 1.2 The Original Definition This document is intended to make just one change, based on implementation experience, and to remain as close to the original document as possible. To reinforce this, relevant sections of RFC 1034 are repeated verbatim to help compare the old and new text. There are a few passages which are changed. This may seem to contradict the goal of not changing the original specification, but the changes herein are required because of inconsistencies with the wording in RFC 1034. The beginning of the discussion ought to start with the definition of the term "wildcard" as it appears in RFC 1034, section 4.3.3. # In the previous algorithm, special treatment was given to RRs with owner # names starting with the label "*". Such RRs are called wildcards. # Wildcard RRs can be thought of as instructions for synthesizing RRs. # When the appropriate conditions are met, the name server creates RRs # with an owner name equal to the query name and contents taken from the # wildcard RRs. This passage appears after the algorithm in which they are used is presented. The terminology is not consistent, the word "wildcard" is clearly defined to be a resource record. Wildcard has also been used to refer to domain names whose first (i.e., left most or least significant) label consists of an asterisk. 1.3 The Clarification The clarification effort can be divided into three sections: o The introduction of new terminology for clarity of the discussion o Changes to the wording of passages of RFC 1034 prompted by discoveries of conflicting concepts o Descriptions of special resource record types in the context of wildcards. 1.3.1 New Terms The term "wildcard" has become so overloaded it is virtually useless as a description. A few new terms will be introduced to be more descriptive. The new terms that will be introduced are: Asterisk Label - a label consisting of an asterisk ("*") and no other characters. Wild Card Domain Name - a domain name whose least significant label (first when reading left to right) is an asterisk label. Other labels might also be asterisk labels. Source of Synthesis - a wild card domain name when it is consulted in the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm. Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which the last match was possible in step 3, part c. This is the longest sequence of exactly matching labels from the root downward in both the query name (QNAME) and in the zone being examined. Label Match - two labels are equivalent if the label type and label length are both the same and if the labels are case-independent equivalent strings. Pattern matching is not involved. These terms will be more fully described as needed later. These terms will be used to describe a few changes to the words in RFC 1034. A summary of the changes appear next and will be fully covered in later sections. Note that labels other than the asterisk label which contain asterisks have no special significance or terminology in this document; thus the fact that a domain names starts with an asterisk is also of no special significance (and has no special terminology) unless its first label is the asterisk label, e.g., "*foo.example." has no special significance). 1.3.2 Changed Text The definition of "existence" is changed, superficially, to exclude empty domains that have no subdomains with resource records. This change will not be apparent to implementations; it is needed to make descriptions more concise. In RFC 1034, there is text that seems to prohibit having two asterisk labels in a wild card domain name. There is no further discussion, no prescribed error handling, nor enforcement described. With this document implementations will have to account for such a name's use. The actions when a source of synthesis owns a CNAME RR are changed to mirror the actions if an exact match name owns a CNAME RR. This is an addition to the words in RFC 1034, section 4.3.2, step 3, part c. 1.3.3 Considerations with Special Types This clarification will describe in some detail the semantics of wildcard CNAME RRSets, wildcard NS RRSets, wildcard SOA RRSets, wildcard DNAME RRSets [RFC 2672], and empty non-terminal wildcards. Understanding these types in the context of wildcards has been clouded because these types incur special processing if they are the result of an exact match. By the definition in RFC 1034, there can be no empty non-terminal "wildcards" ("RRs are called wildcards"). However, in the algorithm, it is possible that an empty non-terminal is sought as the potential owner of a "wildcard." This is one example of why the ordering of the discussion in RFC 1034 is confusing. 1.4 Standards Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in the document entitled "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] Quotations of RFC 1034 (as has already been done once above) are denoted by a '#' in the leftmost column. 2 "Wildcard" The context of the wildcard concept involves the algorithm by which a name server prepares a response (in RFC 1034's section 4.3.2) and the way in which a resource record (set) is identified as being a source of synthetic data (section 4.3.3). Tackling the latter first, there are two objectives in defining a means to identify a resource record set as a source of synthesis. First, to simplify implementations, one objective is to encode synthesis rules into the domain tree, i.e., avoiding a special data store for synthesis is desirable. The second objective impacts interoperability, that is a master server of one implementation has to be able to send the synthesis instructions to the slaves. Although there are alternatives to the use of zone transfers via port 53, a truly interoperable record synthesis approach has to be able to insert the synthesis instructions into a zone transfer. The objectives in describing the synthesis of records in the context of the name server algorithm include knowing when to employ the process of synthesis and how the synthesis is carried out. 2.1 Identifying a wildcard To provide a more accurate description of "wildcards", the definition has to start with a discussion of the domain names that appear as owners. 2.1.1 Wild Card Domain Name and Asterisk Label A "wild card domain name" is defined by having its initial (i.e., left-most or least significant) label be, in binary format: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) This is "*" in presentation format. The first octet is the normal label type and length for a 1 octet long label, the second octet is the ASCII representation [RFC 20] for the '*' character. In RFC 1034, ASCII encoding is assumed to be the character encoding. A descriptive name of a label equaling that value is an "asterisk label." RFC 1034's definition of wildcard would be "a resource record owned by a wild card domain name." This is mentioned to help maintain some orientation between this clarification and RFC 1034. Keep in mind, that in "Clarifications to the DNS Specification" [RFC 2181] the name of the basic unit of DNS data became the resource record set (RRSet) and not the resource record. 2.1.2 Variations on Wild Card Domain Names Labels other than the asterisk label which contain the ASCII representation of the asterisk (0x2a) have no significance for the purposes of this document. RFC 1034 and RFC 1035 do not explicitly mention the case in which a domain name might be something like "the*.example." The interpretation is that this domain name in a zone would only match queries for "the*.example." and not have any other role. An asterisk ('*') occurring other than as the sole character in a label is simply a character forming part of the label and has no special meaning. This is not an asterisk label, simply a label an asterisk in it. The same is true for "**.example." and "*the.example." The interpretation of a wild card domain specification which is not a leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example., is not discussed, not barred. In wanting to minimize changes from the original specification, such names are permitted. Although "sub.*.example." is not a wild card domain name, "*.example." is. RRSets used to synthesize records can be owned by a wild card domain name that has subdomains. 2.1.3 Non-terminal Wild Card Domain Names In section 4.3.3, the following is stated: # .......................... The owner name of the wildcard RRs is of # the form "*.<anydomain>", where <anydomain> is any domain name. # <anydomain> should not contain other * labels...................... This covers names like "*.foo.*.example." The pre-RFC2119 wording uses "should not" which has an ambiguous meaning. The specification does not proscribe actions upon seeing such a name, such as whether or not a zone containing the name should fail to be served. What if a dynamic update (RFC2136) requested to add the name to the zone? The failure semantics are not defined. The recommendation is that implementations ought to anticipate the appearance of such names but generally discourage their use in operations. No standards statement, such as "MUST NOT" nor "SHOULD NOT" is made here. The interpretation of this is, when seeking a wild card domain name for the purposes of record synthesis, an implementation need not to check the domain name for subdomains. It is possible that a wild card domain name is an empty non-terminal. (See the upcoming sections on empty non-terminals.) In this case, the lookup will terminate as would any empty non-terminal match. 2.2 Existence Rules The notion that a domain name 'exists' arises numerous times in discussions about the wildcard concept. RFC 1034 raises the issue of existence in a number of places, usually in reference to non-existence and in reference to processing involving wildcards. RFC 1034 contains algorithms that describe how domain names impact the preparation of an answer and does define wildcards as a means of synthesizing answers. Because of this a discussion on wildcards needs to cover a definition of existence. To help clarify the topic of wild cards, a positive definition of existence is needed. Complicating matters, though, is the realization that existence is relative. To an authoritative server, a domain name exists if the domain name plays a role following the algorithms of preparing a response. To a resolver, a domain name exists if there is any data available corresponding to the name. The difference between the two is the synthesis of records according to a wildcard. For the purposes of this document, the point of view of an authoritative server is more interesting. A domain name is said to exist if it plays a role in the execution of the algorithms in RFC 1034. 2.2.1. An Example To illustrate what is meant by existence consider this complete zone: $ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "this is a wild card" *.example. 3600 MX 10 host1.example. host1.example. 3600 A 192.0.4.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net. A look at the domain names in a tree structure is helpful: | -------------example------------ / / \ \ / / \ \ / / \ \ * host1 host2 subdel | | | | _tcp _tcp | | | | _ssh _ssh The following queries would be synthesized from one of the wildcards: QNAME=host3.example. QTYPE=MX, QCLASS=IN the answer will be a "host3.example. IN MX ..." QNAME=host3.example. QTYPE=A, QCLASS=IN the answer will reflect "no error, but no data" because there is no A RR set at '*.example.' QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN the answer will be "foo.bar.example. IN TXT ..." because bar.example. does not exist, but the wildcard does. The following queries would not be synthesized from any of the wildcards: QNAME=host1.example., QTYPE=MX, QCLASS=IN because host1.example. exists QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN because *.example. exists QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN because _tcp.host1.example. exists (without data) QNAME=host.subdel.example., QTYPE=A, QCLASS=IN because subdel.example. exists (and is a zone cut) To the server, all of the domains in the tree exist. The resolver will get answers to some names off the tree, thanks to synthesis. 2.2.2 Empty Non-terminals Empty non-terminals are domain names that own no resource records but have subdomains that do. This is defined in section 3.1 of RFC 1034: # The domain name space is a tree structure. Each node and leaf on the # tree corresponds to a resource set (which may be empty). The domain # system makes no distinctions between the uses of the interior nodes and # leaves, and this memo uses the term "node" to refer to both. The parenthesized "which may be empty" specifies that empty non- terminals are explicitly recognized. According to the definition of existence in this document, empty non-terminals do exist at the server. Pedantically reading the above paragraph can lead to an interpretation that all possible domains exist - up to the suggested limit of 255 octets for a domain name [RFC 1035]. For example, www.example. may have an A RR, and as far as is practically concerned, is a leaf of the domain tree. But the definition can be taken to mean that sub.www.example. also exists, albeit with no data. By extension, all possible domains exist, from the root on down. As RFC 1034 also defines "an authoritative name error indicating that the name does not exist" in section 4.3.1, this is not the intent of the original document. 2.2.3 Yet Another Definition of Existence RFC1034's wording is clarified by the following paragraph: A node is considered to have an impact on the algorithms of 4.3.2 if it is a leaf node with any resource sets or an interior node (with or without a resource set) that has a subdomain that is a leaf node with a resource set. A QNAME and QCLASS matching an existing node never results in a response code of authoritative name error (RCODE==3). The terminology in the above paragraph is chosen to remain as close to that in the original document. The term "with" is a alternate form for "owning" in this case, hence "a leaf node owning resources sets, or an interior node, owning or not owning any resource set, that has a leaf node owning a resource set as a subdomain," is the proper interpretation of the middle sentence. The phrase "resource set" appears in the original text of RFC 1034, this would now be replaced by "RRSet." As an aside, an "authoritative name error", response code (RCODE) 3, has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned to such an error by at least one implementation of DNS. Summarizing the discussion on existence in non-RFC1034 words: An authoritative server is to treat a domain name as existing during the execution of the algorithms in RFC 1034 when the domain name conforms to the following definition. A domain name is defined to exist if the domain name is on the domain tree and either owns data or has a subdomain that exists. Note that at a zone boundary, the domain name owns data, including the NS RR set. At the delegating server, the NS RR set is not authoritative, but that is of no consequence here. The domain name owns data, therefore, it exists. 2.3 When does a Wild Card Domain Name not own a wildcard (record) When a wild card domain name appears in a message's query section, no special processing occurs. An asterisk label in a query name only (label) matches an asterisk label in the existing zone tree when the 4.3.2 algorithm is being followed. When a wild card domain name appears in the resource data of a record, no special processing occurs. An asterisk label in that context literally means just an asterisk. 3. Impact of a Wild Card Domain On a Response The description of how wild cards impact response generation is in RFC 1034, section 4.3.2. That passage contains the algorithm followed by a server in constructing a response. Within that algorithm, step 3, part 'c' defines the behavior of the wild card. The algorithm is directly quoted in lines that begin with a '#' sign. Commentary is interleaved. There is a documentation issue deserving some explanation. The algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo code, i.e., its steps are not intended to be followed in strict order. The "algorithm" is a suggestion. As such, in step 3, parts a, b, and c, do not have to be implemented in that order. Another issue needing explanation is that RFC 1034 is a full standard. There is another RFC, RFC 2672, which makes, or proposes an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME RR. RFC 2672 is a proposed standard. The dilemma in writing these clarifications is knowing which document is the one being clarified. Fortunately, the difference between RFC 1034 and RFC 2672 is not significant with respect to wild card synthesis, so this document will continue to state that it is clarifying RFC 1034. If RFC 2672 progresses along the standards track, it will need to refer to modifying RFC 1034's algorithm as amended here. 3.1 Step 2 Step 2 of the RFC 1034's section 4.3.2 reads: # 2. Search the available zones for the zone which is the nearest # ancestor to QNAME. If such a zone is found, go to step 3, # otherwise step 4. In this step, the most appropriate zone for the response is chosen. The significance of this step is that it means all of Step 3 is being performed within one zone. This has significance when considering whether or not an SOA RR can be ever be used for synthesis. If an implementation were to attempt to synthesize zones, this would be the step to do this. Note though that each name server listed in the NS RRSet for the synthesized zone would have to coherently synthesize the zone. 3.2 Step 3 Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. But the beginning of the Step is important and needs explanation. # 3. Start matching down, label by label, in the zone. The # matching process can terminate several ways: The word 'matching' refers to label matching. The concept is based in the view of the zone as the tree of existing names. The query name is considered to be an ordered sequence of labels - as if the name were a path from the root to the owner of the desired data. (Which it is.) The process of label matching a query name ends in exactly one of three choices, the parts 'a', 'b', and 'c'. Once one of the parts is chosen, the other parts are not considered. (E.g., do not execute part 'c' and then change the execution path to finish in part 'b'.) The process of label matching is also done independent of the Query Type. Parts 'a' and 'b' are not an issue for this clarification as they do not relate to record synthesis. Part 'a' generally covers a situation in which all of the labels in the query name have a (label) match in the tree. Part 'b' generally covers a situation in which any label in the query name (label) matches a tree label and the tree label has a NS RRSet. 3.3 Part 'c' The context of part 'c' is that the process of label matching the labels of the query name has resulted in a situation in which there is no corresponding label in the tree. It is as if the lookup has "fallen off the tree." # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if a # the "*" label exists. To help describe the process of looking 'to see if a [sic] the "*" label exists' a term has been coined to describe the last label matched. The term is "closest encloser." 3.3.1 Closest Encloser and the Source of Synthesis The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward). Each match is a "label match" and the order of the labels is the same. The closest encloser is, by definition, an existing name in the zone. The closest encloser might be an empty non-terminal or even be a wild card domain name itself. In no circumstances is the closest encloser the used to synthesize records for the current query. The source of synthesis is defined in the context of a query process as that wild card domain name immediately descending from the closest encloser, provided that this wild card domain name exists. "Immediately descending" means that the source of synthesis has a name of the form <asterisk label>.<closest encloser>. A source of synthesis does not guarantee having a RRSet to use for synthesis. The source of synthesis could be an empty non-terminal. If the source of synthesis does not exist (not on the domain tree), there will be no wildcard synthesis. There is no search for an alternate. The important concept is that for any given lookup process, there is at most one place at which wildcard synthetic records can be obtained. If the source of synthesis does not exist, the lookup terminates, the lookup does not look for other wildcard records. Other terms have been coined on the mailing list in the past. E.g., it has been said that existing names block the application of wildcard records. This is still an appropriate viewpoint, but replacing this notion with the closest encloser and source of synthesis terminology depicts the wildcard process is more clearly. 3.3.2 Closest Encloser and Source of Synthesis Examples To illustrate, using the example zone in section 2.2.1 of this document, the following chart shows QNAMEs and the closest enclosers. QNAME Closest Encloser Source of Synthesis host3.example. example. *.example. _telnet._tcp.host1.example. _tcp.host1.example. no source _telnet._tcp.host2.example. host2.example. no source _telnet._tcp.host3.example. example. *.example. _chat._udp.host3.example. example. *.example. 3.3.3 Non-existent Source of Synthesis In RFC 1034: # If the "*" label does not exist, check whether the name # we are looking for is the original QNAME in the query # or a name we have followed due to a CNAME. If the name # is original, set an authoritative name error in the # response and exit. Otherwise just exit. The above passage is clear, evidenced by the lack of discussion and mis-implementation of it over the years. It is included for completeness only. (No attempt is made to re-interpret it lest a mistake in editing leads to confusion.) 3.3.4 Type Matching RFC 1034 concludes part 'c' with this: # If the "*" label does exist, match RRs at that node # against QTYPE. If any match, copy them into the answer # section, but set the owner of the RR to be QNAME, and # not the node with the "*" label. Go to step 6. This final paragraph covers the role of the QTYPE in the lookup process. Based on implementation feedback and similarities between step 'a' and step 'c' a change to this passage a change has been made. The change is to add the following text: If the data at the source of synthesis is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response changing the owner name to the QNAME, change QNAME to the canonical name in the CNAME RR, and go back to step 1. This is essentially the same text in step a covering the processing of CNAME RRSets. 4. Considerations with Special Types Five types of RRSets owned by a wild card domain name have caused confusion. Four explicit types causing confusion are SOA, NS, CNAME, DNAME, and the fifth type - "none." 4.1. SOA RRSet at a Wild Card Domain Name A wild card domain name owning an SOA RRSet means that the domain is at the root of the zone (apex). The domain can not be a source of synthesis because that is, by definition, a descendent node (of the closest encloser) and a zone apex is at the top of the zone. Although a wild card domain name owning an SOA RRSet can never be a source of synthesis, there is no reason to forbid the ownership of an SOA RRSet. E.g., if *.example. has an SOA record, then only a query like QNAME=*.example., QTYPE=A, QCLASS=IN would see it. A query like QNAME=foo.example., QTYPE=A, QCLASS=IN would not see it - a different zone would have been picked in Step 2. A QNAME of www.*.example. would result in a query referencing the *.example zone. 4.2. NS RRSet at a Wild Card Domain Name The semantics of a wild card domain name's ownership of a NS RRSet has been unclear. Looking through RFC 1034, the recommendation is to have the NS RRSet act the same a any non-special type, e.g., like an A RRSet. If the NS RRSet in question is at the top of the zone, i.e., the name also owns an SOA RRSet, the QNAME equals the zone name. This would trigger part 'a' of Step 3. In any other case, the wild card domain name owned NS RRSet would be the only RRSet (prior to changes instituted by DNSSEC) at the node by DNS rules. If the QNAME equals the wild card domain name or is a subdomain of it, then the node would be considered in part 'b' of Step 3. [should dnssec be left out of this?] Note that there is no synthesis of records in the authority section because part 'b' does not specify synthesis. The referral returned would have the wild card domain name in the authority section unchanged. If the QNAME is not the same as the wild card domain name nor a subdomain of it, then part 'c' of Step 3 has been triggered. Once part 'c' is entered, there is no reverting to part 'b' - i.e., once an NS RRSet is synthesized it does not mean that the server has to consider the name delegated away. I.e., the server is not synthesizing a record (the NS RRSet) that means the server does not have the right to synthesize. (Only an authoritative server can perform synthesis. By synthesizing an NS RRSet, it appears that the authority for the name has been delegated to another authority.) In summation, an NS RRSet at a wild card domain name will not result in the generation of referral messages for non-existent domains. 4.3. CNAME RRSet at a Wild Card Domain Name The issue of a CNAME RRSet owned by wild card domain names has prompted a suggested change to the last paragraph of step 3c of the algorithm in 4.3.2. The changed text appears in section 3.3.4 of this document. 4.4. DNAME RRSet at a Wild Card Domain Name The specification of the DNAME RR, which is at the proposed level of standardization, is not as mature as the full standard in RFC 1034. Because of this, or the reason for this is, there appears to be a a number of issues with that definition and it's rewrite of the algorithm in 4.3.2. For the time being, when it comes to wild card processing issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME at a wild card domain name is effectively the same as a CNAME at a wild card domain name. 4.5 Empty Non-terminal Wild Card Domain Name If a source of synthesis is an empty non-terminal, then the response will be one of no error in the return code and no RRSet in the answer section. 5. Security Considerations This document is refining the specifications to make it more likely that security can be added to DNS. No functional additions are being made, just refining what is considered proper to allow the DNS, security of the DNS, and extending the DNS to be more predictable. 6. References Normative References [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, Nov-01-1987 [RFC 1035] Domain Names - Implementation and Specification, P.V Mockapetris, Nov-01-1987 [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S Bradner, March 1997 [RFC 2181] Clarifications to the DNS Specification, R. Elz and R. Bush, July 1997. Informative References [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 7. Others Contributing to This Document Others who have been editors of this document: Bob Halley. Others who have directly caused text to appear in the document: Alex Bligh, Robert Elz, Paul Vixie and Olaf Kolkman. Many others have indirect influences on the content. 8. Editor Name: Edward Lewis Affiliation: NeuStar Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US Phone: +1-571-434-5468 Email: Ed.Lewis@neustar.biz Comments on this document can be sent to the editor or the mailing list for the DNSEXT WG, namedroppers@ops.ietf.org. 9. Trailing Boilerplate Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expiration This document expires on or about 25 April 2005. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: James Snell <jasnell@gmail.com> Subject: Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt) Date: Wed, 3 Nov 2004 08:13:14 -0800 Lines: 159 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> <20041103150449.2285e598.olaf@ripe.net> Reply-To: James Snell <jasnell@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 17:24:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=c4W/I/WlhjCJZm8EfkvhBvHqE63TCnGqbOg5SYW5HAo5YDGbPkloPQLGduab85VClj9suJ1GEWhtCUSSq6nBtoIGZbGfR4Xo4XHFb0akNRgUvrmhO0wYWcq1riwH06WYvuCHaKftiScO+k47jfyCDqhJDvIw2FTYcF7cXXTRPBY= To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20041103150449.2285e598.olaf@ripe.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello Olaf, Thanks for taking a look at the spec. Comments below. On Wed, 3 Nov 2004 15:04:49 +0100, Olaf M. Kolkman <olaf@ripe.net> wrote: > > > Hello James and Andrew, > > I have been reading your draft. Having very little experience with the > web-services architecture there are a few things that I cannot get my > finger behind. > > The first question I have is on EPR. It is triggered by having > possible redirection ( WDSL URL or an XML RR), why not simply always > redirect to a WSDL document describing the service? It may make life > much easier if the web service descriptions are dynamic in nature. You > will not need to bother with caching and other DNS data propagation > effects such as secondary DNS servers not updating in time. > At the most basic level, a Web service client needs to know three pieces of information in order to contact with a service endpoint: a) The URL of the service, b) the protocol binding to use (HTTP, etc), and c) the QName of the WSDL defined portType implemented by the service. The portType tells clients what message exchanges the service is capable of supporting. Some portType QNames will be well known, others will not. In the case that a portType is well known, a redirection to a WSDL document is entirely optional and is only needed if additional policy and binding information is required to enable the interaction. Further, we are specifically targeting DNS-EPD towards use with relatively static infrastructure level Web services whose descriptions remain fairly stable over time. More dynamic business level services are better served by high level discovery mechanisms such as UDDI, or possibly LDAP or SLP. For example, if a company deploys UDDI services within their Intranet environment to support some business critical processes, the WSDL description of that service is going to remain static over time. > I do not feel comfortable with the XML RR. It has more or less the > same properties as the TXT RR. It has no limitations and may cause > people to put all kinds of things in the XML RR, such as > internet-draft XML source (interesting idea :-) ). > :-) I quite expected folks to be uncomfortable with this, it will definitely be something that we need to have further discussion about. I will prepare a separate note with specific discussion about the XML RR and why it is needed and post that a bit later today. > If there is a possibility for redirection I do not understand why the > XML RR would be needed, what is the perceived benefit? > > I also have a more detailed questions and remarks about the RRs. > > 1. I think that some of the EPR RDATA elements can be split into > their functional parts. For instance the PortType QNAME (confusing > name for a data element in the context of DNS :-) ) could be > encoded as: > > |length|namespace-uri|length|localpart > Yeah, I thought of this after rereading the published draft and already had it marked in my notes as a potential change. This encoding would be more natural from a DNS standpoint and would save a byte of information. The original {uri}localname syntax was selected mostly as a default because it is the syntax used by the standard Java implementation of the QName datatype. (No language bias here ;-) .....). I'll make the change. > 2. It is not clear to me why the separator "_ws" is needed in the > proposed owner names of EPR records {name}._ws.{domain}. Both > client and server will know which part of the name is intended to > be the domain part and which part will be the name part. > > Dropping _ws could introduce an ambiguity (If there exists both a > "inquire.uddi" and a "inquire" service and the "inquire.uddi" > service has been implemented for the "example.com" domain and the > "inquire" service has been implemented for the "uddi.example.com" > domain.) But that ambiguity one could solve by adding a simple > counter in the RDATA that tells us at which label the split between > name and domain occurs. The DNSSIG RR uses a similar mechanism to > indicate to indicate which part of a domain name has been > synthesized. > The _ws separater was selected specifically to allow DNS-EPD records to be segregated and organized by distinct, unambiguous domains. We expect various name fragments to become somewhat well known in the industry, such as inquire.uddi._ws and publish.uddi._ws, in much the same way www has become ubiquitous. A service with the label inquire._ws in the domain uddi.example.com may be significantly different than a service with the label inquire.uddi._ws in the domain example.com. Exactly as you point out, elimating the _ws tag would make this too ambiguous. Another advantage of the _ws tag is that it allows DNS-EPD records to be split out completely and delegated as a set to a different DNS server so that they may be managed separately. In some of our use case models, for instance, Dynamic DNS Update is used to update EPR resource records. If I understand current DNS management best practices correctly, it is ideal is isolate such records to a dedicated DNS server that separates them from more mission critical static records. The _ws label allows us to delegate all DNS-EPD records as a whole. Now, I'll be the first to admit that I am not a DNS management expert and may be completely off base here so if I'm wrong about this, please correct me, but be gentle ;-) ;-) > 3. Section 2.3.1. > > "DNS implementations MUST send the XML data using the encoding > specified by the encoding byte flag". > > DNS implementations will send binary RDATA, they will never look at > the content of the RDATA before putting information on the > wire. The encoding flag can only be used as an indicator to the > client interpreting the RDATA on what the binary RDATA is > representing. > > Most of the MUSTs in this paragraphs are not enforcable and > probably should be SHOULDs. (most of them relate to language that > enforces implementers to strip the XML cruft before putting it into the > RDATA). Ok, I had suspected that this might be a problem. I will deal with this in my separate email focusing specifically on the XML resource record. > > 4. Editing nit: most of your example RRs span multiple lines, you > should use brackets to indicate this > > mystock._ws.example.com XML 0 <EndpointReference ( > xmlns="..." > .... > </EndpointReference> ) > Thanks, I'll make the change. > Olaf Kolkman > > namedropper (no hats) > -- - James Snell IBM, Emerging Technologies jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Wed, 03 Nov 2004 16:21:54 +0000 Lines: 60 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 03 17:36:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0410291610461.25617@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > On Fri, 29 Oct 2004, Ben Laurie wrote: > > >>If opt-in is dropped, then (from memory), the only remaining point >>is whether hashing is done per-label or over the whole name. > > > In San Diego, I did presentation comparing the two NSEC++ proposals, > but I don't think a summary ever made it to the list (sorry about > that). The slides are in the meeting proceedings: > > http://www.ietf.org/proceedings/04aug/slides/dnsext-7.pdf > > To summarize, in addition to the choice of whether hashing is > per-label or not [1], the two proposals had three "options": opt-in, > allowing hash iterations, and defining a null hash function. I think > we can pick and choose among these, and I think both the iteration > option and the null hash option are pretty trivial, but I don't recall > us making any decisions about them. > > In my presentation, I also faulted both proposals for not describing > how to change hash functions or salts (or number of iterations) I didn't understand this criticism at the time, and I still don't. > and > for not going into enough detail about wildcard processing. Both of > those need to be addressed. I also worried about hash collisions, > though people keep trying to convince me that the probabilities of a > collision can be made vanishingly small. I'd rather see a mechanism > for rolling (or allowing for coexistence of multiple) hashs and/or > salts, but I'm willing to drop the collision concern. The current draft of NSEC2 does allow for coexistence, since the salt and iterations are included in each record. I can't remember if that is a change. > [1] The choice of whether to do per-label or whole-name hashing could > require the introduction of an EXIST RR and other changes to wildcard > processing rules. Each choice also reveals different information > about the zone: whole-name hashing (NSEC2) exposes the names of empty > non-terminals (via the EXIST RR); per-label hashing (DNSNR/NSEC3) > exposes the structure of the zone but not the names. Good point. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Wed, 3 Nov 2004 22:40:03 -0500 (EST) Lines: 42 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 04:50:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418905A2.1050107@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Nov 2004, Ben Laurie wrote: > > In my presentation, I also faulted both proposals for not describing > > how to change hash functions or salts (or number of iterations) > > I didn't understand this criticism at the time, and I still don't. ... > > .... I'd rather see a mechanism > > for rolling (or allowing for coexistence of multiple) hashs and/or > > salts .... > > The current draft of NSEC2 does allow for coexistence, since the salt > and iterations are included in each record. I can't remember if that is > a change. I'm talking about the same thing in these two sentences. The proposals need to describe what is required to change salt/hash function/iterations, even if that is expected to be a rare or disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) occurence. Is that clearer? Allowing for coexistence makes it much easier, assuming coexistence works. DNSNR section 2.1.3 specifically excluded coexistence of multiple salts and implicitly excluded multiple hashes: "The Salt field value must be the same for every DNSNR generated in the zone." I can't find a current NSEC2 draft (was it ever in the i-d repository?), but I don't think it specifically said "yes, you may have multiple salts, etc.", nor did it discuss why that would always work. A previous version had salt and hash functions as zone properties (in the NSECINFO RR). The draft I have (-01, May '04) still mentions NSECINFO in section 4. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 14:37:59 +0000 Lines: 87 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 15:50:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411032227130.622@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > On Wed, 3 Nov 2004, Ben Laurie wrote: > > >>>In my presentation, I also faulted both proposals for not describing >>>how to change hash functions or salts (or number of iterations) >> >>I didn't understand this criticism at the time, and I still don't. > > ... > >>>.... I'd rather see a mechanism >>>for rolling (or allowing for coexistence of multiple) hashs and/or >>>salts .... >> >>The current draft of NSEC2 does allow for coexistence, since the salt >>and iterations are included in each record. I can't remember if that is >>a change. > > > I'm talking about the same thing in these two sentences. The > proposals need to describe what is required to change salt/hash > function/iterations, even if that is expected to be a rare or > disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) > occurence. Is that clearer? OK, I understand what you are saying, but not why you are saying it. If you want to change them, you just change them. > Allowing for coexistence makes it much easier, assuming coexistence > works. DNSNR section 2.1.3 specifically excluded coexistence of > multiple salts and implicitly excluded multiple hashes: > > "The Salt field value must be the same for every DNSNR > generated in the zone." Roy has tried to persuade me that there's some reason this _must_ be true, but I can't currently recreate the logic[1]. > I can't find a current NSEC2 draft (was it ever in the i-d > repository?), Hmm. There was some mixup with boilerplates, it may never have made it. > but I don't think it specifically said "yes, you may > have multiple salts, etc.", nor did it discuss why that would always > work. A previous version had salt and hash functions as zone > properties (in the NSECINFO RR). The draft I have (-01, May '04) > still mentions NSECINFO in section 4. You can find it here: http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-02.txt Pending rediscussing with Roy why he thought this didn't work, I don't intend to update this document as you suggest. I can't see a particular problem with it, but I'd note that allowing extra salts does not solve the collision problem. In any case, until we have reached some kind of consensus on the requirements stuff, I do not consider this to be anything more than a currently superfluous proposal. Should it become relevant, I will update it and get it properly submitted as an I-D. Cheers, Ben. [1] I may be confused. Certainly its the case that for each salt/number of iterations/hash function, one must hash every name in the zone in order to find the correct (minimal) enclosing pair. But this is not a barrier to having multiple coexisting salts (etc.). It may be that this is what I discussed with Roy. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 17:08:15 +0100 Lines: 47 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 17:22:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 40 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:wEV7cKTA2x6btH/yzgv8VH4DG6Y= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: >>>The current draft of NSEC2 does allow for coexistence, since the salt >>>and iterations are included in each record. I can't remember if that is >>>a change. >> I'm talking about the same thing in these two sentences. The >> proposals need to describe what is required to change salt/hash >> function/iterations, even if that is expected to be a rare or >> disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) >> occurence. Is that clearer? > > OK, I understand what you are saying, but not why you are saying it. If > you want to change them, you just change them. For what its worth, I also do not understand why this is needed. At one point I thought the motivation was a miss-guided attempt to mimic other security standards (i.e., signature algorithms). For such algorithms, it make sense to be support multiple hash algorithms, if one hash algorithm is broken. It might have lead people to think that multiple hash algorithms must always be supported. However, as far as I understand, the hashed-NSEC idea does not require a cryptographic strong hash function. I suspect the idea would work just as well with CRC-128. So if my understanding is correct, supporting arbitrary hash algorithms (possibly via an IANA registry) would not serve any purpose, except to decrease interoperability. The properties we need from the hash function (large enough output set to make it possible to avoid collisions by changing the salt) can be verified empirically. I invite people to think about the hashed-NSEC idea with CRC-128 as the "hash" function. I have not analyzed it, or even thought about it, in any significant detail. I may be wrong, but proving me wrong on this, would contribute to a better understanding of the hash requirements in the hashed-NSEC idea. And give the satisfaction of proving me wrong. ;) Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 17:10:35 +0100 (CET) Lines: 41 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 17:28:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418A3EC7.4050302@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Ben Laurie wrote: > > Allowing for coexistence makes it much easier, assuming coexistence > > works. DNSNR section 2.1.3 specifically excluded coexistence of > > multiple salts and implicitly excluded multiple hashes: > > > > "The Salt field value must be the same for every DNSNR > > generated in the zone." > > Roy has tried to persuade me that there's some reason this _must_ be > true, but I can't currently recreate the logic[1]. > > [1] I may be confused. Certainly its the case that for each salt/number > of iterations/hash function, one must hash every name in the zone in > order to find the correct (minimal) enclosing pair. > > But this is not a > barrier to having multiple coexisting salts (etc.). It may be that this > is what I discussed with Roy. This is exactly what we discussed. In San Diego, I was talking about salting requirements, Ben was talking about multiple salt possibilities, hence the confusion between us at the time. We agreed that multiple salts are possible, as long as the salting requirement (every name MUST be salted with each salt) was satisfied. Therefor, the relevant section in the DNSNR draft needs to be updated, since I did not anticipate having multiple salts. Multiple salts are no problem, as long as every name is salted with each salt. For every salt there will exist an NSEC-chain. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 17:49:04 +0100 Lines: 29 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 17:58:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 22 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:l10F0ua1nBiofYZvAvYyCIg2iQs= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > Multiple salts are no problem, as long as every name is salted with each > salt. For every salt there will exist an NSEC-chain. Could you expand on the justification of this requirement? In particular, what will break if one of the chains do not cover all names? Of course, there must be some applicable NSEC record for each question-tuple. But do they also have to be part of a full chain? To me, it seems the interesting property should be that clients should be able to verify the returned NSECbis record. Whether or not the NSECbis records involved form a complete chain or not does not seem to be critical to me. One situation where having partial hashed-NSEC chains may be with dynamic update. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 17:08:07 +0000 Lines: 66 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 18:36:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluactxy4uo.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>>>The current draft of NSEC2 does allow for coexistence, since the salt >>>>and iterations are included in each record. I can't remember if that is >>>>a change. >>> >>>I'm talking about the same thing in these two sentences. The >>>proposals need to describe what is required to change salt/hash >>>function/iterations, even if that is expected to be a rare or >>>disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) >>>occurence. Is that clearer? >> >>OK, I understand what you are saying, but not why you are saying it. If >>you want to change them, you just change them. > > > For what its worth, I also do not understand why this is needed. > > At one point I thought the motivation was a miss-guided attempt to > mimic other security standards (i.e., signature algorithms). For such > algorithms, it make sense to be support multiple hash algorithms, if > one hash algorithm is broken. It might have lead people to think that > multiple hash algorithms must always be supported. > > However, as far as I understand, the hashed-NSEC idea does not require > a cryptographic strong hash function. It does require preimage resistance, though, which is not a property you find much in non-cryptographic hash functions. > I suspect the idea would work > just as well with CRC-128. So if my understanding is correct, > supporting arbitrary hash algorithms (possibly via an IANA registry) > would not serve any purpose, except to decrease interoperability. The > properties we need from the hash function (large enough output set to > make it possible to avoid collisions by changing the salt) can be > verified empirically. > > I invite people to think about the hashed-NSEC idea with CRC-128 as > the "hash" function. I have not analyzed it, or even thought about > it, in any significant detail. I may be wrong, but proving me wrong > on this, would contribute to a better understanding of the hash > requirements in the hashed-NSEC idea. And give the satisfaction of > proving me wrong. ;) See above. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 04 Nov 2004 18:52:21 +0100 Lines: 66 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 19:05:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 59 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:QDJtXDzcT5Uq+NNjS27EoPsVuZc= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: > It does require preimage resistance, though, which is not a property you > find much in non-cryptographic hash functions. Could you explain when the preimage resistance property required, to prevent an attack? I'm trying to work out a complete example (although simplified): Let's say a client query for ("foo.example",IN,A). Let's say CRC128(foo.example) = 42. Server realize "foo.example" doesn't exist, and return the NSECbis RR that has a range that include 42: 17 NSECbis ... 96 ... 17 RRSIG ... NSECbis ... The client verify the signature, and notices that 42 is in range, and return a "domain does not exist" error, or whatever. Since CRC-128 is not preimage resistant, an attacker can find many domain names that produce 17, 42, 96, or any other CRC-128 value, as the output. What does he gain by doing so? Perhaps the problem is when NSECbis is used to prove non-existence of types on existing names? I.e., client query for ("foo.example",IN,A) but now only TXT records exists. Again, CRC128(foo.example) = 42. The server returns: 42 NSECbis ... TXT ... 50 42 RRSIG ... NSECbis... The client verify the signature, compare CRC128(foo.example) with the owner name of the returned NSECbis RR, and realize A is not mentioned as an existing type on the list (only TXT is). Here, again the attacker can compute strings that produce 42 and 50 as output, but what does he gain? Admittedly, one could claim that there is a wart in the design. Attackers can construct query names that produce the same output as existing names. That follow immediately from the lack of preimage resistance. For example, the attacker might determine a query name "gazonk.example" such that CRC128(gazonk.example) = 42, thereby (using the last example above) implicitly proving that TXT records exists for "gazonk.example". Is this wart the only consequence you see? If so, I don't understand how this become anything but a denial-of-service attack, which the attacker can do anyway. The client presumably wouldn't ask for gazonk.example, right? If the attacker control what the client queries for, it seems the attacker might as well point the client to the attackers own zone, which the attacker control. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 13:47:02 -0500 (EST) Lines: 55 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 20:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0411032227130.622@filbert> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [I wrote the below message last night before seeing this morning's very interesting exchange. Sorry for some redundancy.] Yesterday, I said: > Allowing for coexistence [of different salts/hashes] makes [changing > salts/hashes] much easier, assuming coexistence works. I think I've been looking at "coexistence" too naively -- there's more subtlety here than I first realized, and probably more than I realize now. First, the term "coexistence" is overloaded, at least the way I was looking at it. One form of "coexistence" is "multiple hashes/salts[1] are in use in a zone at one time". Or: "some NSEC records in a zone can use hash/salt X, while some use Y". Or even: "each NSEC record may have its own unique salt". As I was imagining it, that doesn't work. Unless someone beats me to it, I can more about that in a later message. I'll keep using the word "coexistence" for this, since it's about what data is actually in the zone file. The other thing I was describing with that label was "a client, having seen (and cached) an NSEC record from a zone then seeing another NSEC using a different hash/salt will behave as expected". This doesn't necessarily mean that both hashes/salts are "in use" at the same time -- perhaps the zone entirely changed hashes/salts, but some NSECs with the old hash/salt are still cached in upstream caches. I suspect this just works, but I think we haven't thought about it enough (nor implemented enough code and tested it enough). If not, it MAY be easy to make work. In any case, "coexistence" is a bad label for this. For want of a better term, I'll call it "non-interference (of multiple hashes/salts from the same zone)", since it refers more to client behavior than zone contents. To summarize using these new labels: as NSEC2/DNSNR are defined, multiple hashes/salts MAY be non-interfering. "Coexistence" as described above, does not work. [Addendum, as of Thursday morning: since last night, Roy and Ben have talked about why. Simon's question suggests that more explanation is needed.] -- Sam [1] Throughout this message, I use "salt/hash" to mean "salt and/or hash function and/or number of hash iterations", since changing either is approximately equivalent. Changing hash functions is actually a bigger problem than changing salts or number of iterations, for reasons to be talked about later. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 13:55:36 -0500 (EST) Lines: 41 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 20:07:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu654ly2yn.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Multiple salts are no problem, as long as every name is salted with each > > salt. For every salt there will exist an NSEC-chain. > > Could you expand on the justification of this requirement? In > particular, what will break if one of the chains do not cover all > names? > > Of course, there must be some applicable NSEC record for each > question-tuple. But do they also have to be part of a full chain? I'm having a hard time coming up with simple examples, so let's see if questions are enough: If there is not a complete chain, how do you ensure that you'll have a NSEC covering each possible Q-tuple? And that no NSEC covers existing names (except during the NSEC TTL or RRSIG lifetime after adding a new name)? Or: how do you know what to put in the 'next name' field of an NSEC? For the owner name, it's easy: you use the hash of the 'natural' owner name. But you can't use the hash of the lexically next name in the 'next name' field. With NSEC++, we discard the 'natural' lexical ordering: we instead hash all of the names, sort the hashes, and insert the lexically next hash. The lexically next hash should have no relationship with the lexicaly next name. > One situation where having partial hashed-NSEC chains may be with > dynamic update. Expand on this some idea more. Are you imagining one NSEC chain of the "permanent" names and another of the updated names? If so, one chain can be used to spoof away names in the other chain. If you're imagining incomplete chains, see the questions above. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: Denial Of Existence: Way Forward Date: Thu, 4 Nov 2004 14:07:37 -0500 (EST) Lines: 44 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 20:24:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418A3EC7.4050302@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I'm talking about the same thing in these two sentences. The > > proposals need to describe what is required to change salt/hash > > function/iterations, even if that is expected to be a rare or > > disaster-recovery-only (my-hash-function-had-a-very-bad-day-only) > > occurence. Is that clearer? > > OK, I understand what you are saying, but not why you are saying it. If > you want to change them, you just change them. Caching and resolver state. What happens when an NSEC using one hash/salt/etc. is cached, then a different one is seen? Or what happens when one answer contains two NSECs from the same zone based on different parameters (ie. the NSEC proving no exact match and the NSEC proving no wildcard match have different parameters)? A resolver must already have logic to find and distinguish between the two NSECs. With this kind of answer, it would have to do BOTH hashes on both the exact name and wildcard name to distinguish them. Then, too, you should never see such an NSEC constructed by a cache -- if auth servers use consistent parameters throughout, it gets simpler. But if you want to allow inconsistency at the auth servers (and within one answer), resolvers need to be explicitly told what logic to use. In any case, resolvers need to be told to expect inconsistent parameters from zones, and I think some serious testing of that would be needed. If you want to allow inconsistency at the auth servers, even more testing will be needed. Or maybe I'm just being too paranoid. > In any case, until we have reached some kind of consensus on the > requirements stuff, I do not consider this to be anything more than a > currently superfluous proposal. Should it become relevant, I will update > it and get it properly submitted as an I-D. Fair enough. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST) Lines: 47 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 04 22:08:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: dee3@pothole.com In-Reply-To: <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 12 Oct 2004 dee3@pothole.com wrote: > Please post any comments on these two drafts. I gave brief presentations > on them at the last IETF and plan to do so again next month. If there are > no substantial comments, I will ask that they be working group Last Called > right after the upcoming meeting. I've only read parts of draft-ietf-dnsext-ecc-key-05. Here are some comments on the bits I have read: This document needs to take into account the type code roll (RFC3755). Examples: Section 1 refers to SIG, which has been largely, but not entirely, deprecated. Section 2 says "key RRs", then cites DNSSECbis-records. See RFC3755 IANA considerations, section 4.2. Be much more explicit about which of DNSKEY and/or KEY you mean here. Section 2, second paragraph: "with signatures..." is confusing. Just say RRSIGs. Also: "key validity may not be in the RR with the key...". First, just say KEY or DNSKEY. Also: I see no key validity field in this RR -- why have the equivolcal phrasing with a "may"? IANA section: Should comment on whether any algorithm numbers need to be assigned (and, if not, where they are assigned). See 3755 section 4.2. It looks like a new registry is being established. This text is likely insufficient for that task. See draft-narten-iana-considerations-rfc2434bis-01.txt Nits: Section 5 (Performance Considerations), second paragraph, third line: s/ and and/, and/ Status of this memo: "This draft is intended to be become a Proposed Standard RFC." is not allowed, per http://www.ietf.org/ietf/1id-guidelines.txt Boilerplate looks incomplete (Acceptance of section 3 of 3667 is missing). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST) Lines: 46 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 04:59:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: dee3@pothole.com In-Reply-To: <Pine.GSO.4.55.0411041546200.16737@filbert> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Samuel Weiler wrote: > Be much more explicit about which of DNSKEY and/or KEY ... Further comments after some more reflection. First, I'd like to thank Donald for his efforts to put this document (and the HMAC SHA TSIG doc) together. There are very few people with both the ability to follow the current crypto research and the willingness to bring that knowledge back to the IETF in a useful form. We should applaud Donald for his willingness to do that. I'd also like to say that I'm not particularly averse to storing random data in the DNS. That said, it's not clear to me why we're trying to store ECC keys in the DNS nor, given that uncertainty, what RR type we might want to use to store them. Of late, we've been choosing to separate data into new type codes based on the use of the data, not the content or format of the data. For cryptographic keys, in particular, we've tried to reuse key storage formats (we reused the 2536 and 3110 formats in DNSKEY and IPSECKEY), but we've allocated new RR types for different data users. See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt section 2.6 (now at RFC-Editor). Since we're not defining a SIG nor RRSIG format for ECC, it would appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and RFC3755. Who are they useful for? (Does anyone really want to store ECC keys in the DNS?) And what does that suggest about what RR type(s) they should be stored in? This all feeds into the IANA section questions I posted earlier today. Looking further ahead, I also wonder if this record format's flexibility might be dangerous. Can we imagine users of data that can't effectively use all of the different types of eliptic curve keys that can be stored in this RR? If so, we may be creating another subtyping problem. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 09:02:03 +0100 (CET) Lines: 27 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:14:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu654ly2yn.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Simon Josefsson wrote: > Roy Arends <roy@dnss.ec> writes: > > > Multiple salts are no problem, as long as every name is salted with each > > salt. For every salt there will exist an NSEC-chain. > > Could you expand on the justification of this requirement? In > particular, what will break if one of the chains do not cover all > names? Sure, you must have at least one entire NSEC-chain. A second set of NSEC's does not have to cover every name. But the second set of NSEC's has to be complete before the first set is deteriorated. Sidenote: the NSEC's from the incomplete set of names MUST NOT form a complete chain. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 08:44:58 +0000 Lines: 58 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:52:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluactxy4uo.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 04 November 2004 17:08 +0100 Simon Josefsson <jas@extundo.com> wrote: > However, as far as I understand, the hashed-NSEC idea does not require > a cryptographic strong hash function. Depends which hash property you are talking about. What you don't want is inversion (i.e. you know H(x), can you discover x?). It requires some cryptographically strong properties to prevent this (or rather make the problem computationally infeasible). > I suspect the idea would work > just as well with CRC-128. So if my understanding is correct, > supporting arbitrary hash algorithms (possibly via an IANA registry) > would not serve any purpose, except to decrease interoperability. I may be partly responsible for this confusion. I jumped on the proposal to support alternative hash algorithms for various reasons: a) When we were back discussing the possibilities of hash collisions (i.e. H(a)=H(b) where a != b), I pointed out these only happen because (most) hash functions are not guaranteed to be injective (in fact the ones we consider are guaranteed not to be injective, i.e. we know collisions will exist, they are just infinitesimally rare and don't know where they are). However, for those who are really worried about such things and don't care about enumeration, but did want to use NSEC2 for something else (opt-in being discussed at the time), they could use the identity function as a hash (i.e. H(x)=x) which clearly never collides. b) Shorter hashes may be useful for those not overly worried about enumeration who are worried about size of zone file / amount of on-wire data etc. / computational resources. For all but the latter, truncated hashes are just as good. I think (b) is the only really significant reason to support alternative hashes, though if you are doing this, you might as well support the identity hash, just as a debugging tool (may be a "reverse the order of the octets in each label" hash too). If one is truncating, one could imagine a zone signing thing which automagically sized the hash sensibly (for minimal chance of collision for incremental update but also minimizing zone file size). The interoperability concerns come down to which hashes you make mandatory to support. I would suggest if we are going this way, we chose one (long) hash, and the identity hash (as mandatory), reserve all other codes (rather than go the IANA route), and have another field which is the number of octets to truncate each hash to. I cannot see a reason to support multiple hashes for the same record. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 08:48:36 +0000 Lines: 18 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:53:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluvfclwlgq.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 04 November 2004 18:52 +0100 Simon Josefsson <jas@extundo.com> wrote: > Since CRC-128 is not preimage resistant, an attacker can find many > domain names that produce 17, 42, 96, or any other CRC-128 value, as > the output. What does he gain by doing so? If it's not preimage resistant, these can then be sifted by (for instance) only looking at ones which match /[a-zA-Z-]+/. Unless I'm missing something. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 09:51:59 +0100 (CET) Lines: 69 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 09:58:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluvfclwlgq.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > > It does require preimage resistance, though, which is not a property you > > find much in non-cryptographic hash functions. > > Could you explain when the preimage resistance property required, to > prevent an attack? I came to a similar question when writing the DNSNR/NSEC3 draft (section 3.2.2/3.2.3). The following analysis applies to the second-preimage resistance property. All in all my conclusion was that since the need for preimage requirement is low, truncation of hashes can be used. Ofcourse, using the exact same analysis, the use CRC-128 can be defended. Roy 3.2.2 Second Preimage Requirement Analysis A collision resistant hash function has a second-preimage resistance property. The second-preimage resistance property means that it is computationally infeasible to find another message with the same hash value as a given message, i.e, given x, to find a second-preimage X' <> X such that hash(X) = hash(X'). The probability of finding a second preimage is 1 in 2^160 for SHA-1 on average. To mount an attack using an existing DNSNR RR, an adversary needs to find a second preimage. Assuming an adversary is capable of mounting such an extreme, the actual damage is that a response message can be generated which claims that a certain QNAME (i.e. the second pre-image) does exist, while in reality QNAME does not exist (aka false positive), which will either cause a security aware resolver to re-query for the non-existent name, or to fail the initial query. Note that the adversary can't mount this attack on an existing name, solely on a name that the adversary can't choose and does not yet exist. 3.2.3 Possible Hash Value Truncation Method The previous sections outlined the low probability and low impact of a second-preimage attack. When impact and probability are low, while space in a DNS message is costly, truncation is tempting. Truncation might be considered to allow for shorter ownernames and rdata in case of labels with hash values. The author seeks comfirmation on the assumption that truncation decreases resilliance on colliding hash values though the overall security model does not significantly deteriorate. An extreme hash value truncation would be truncating to the shortest possible unique label value. Considering that hash values are presented in base32, which represents 5 bits per label character, truncation must be done on a 5 bit boundary. Though the mentioned truncation can be maximised to a certain extreme, the probability of collision increases exponentially for every truncated bit. Given the low impact of hash value collisions and limited space in DNS messages, the balance between truncation profit and collision damage may be determined by local policy (but see first paragraph where 'the author seeks'). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:22:32 +0100 Lines: 41 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 10:31:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 34 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:TGqYUxkpcSBs5BaSPkkpe7FyepQ= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> writes: > --On 04 November 2004 17:08 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> However, as far as I understand, the hashed-NSEC idea does not require >> a cryptographic strong hash function. > > Depends which hash property you are talking about. What you don't > want is inversion (i.e. you know H(x), can you discover x?). It > requires some cryptographically strong properties to prevent this > (or rather make the problem computationally infeasible). Ah, right. This should be mentioned as the primary requirement on the chosen hash. CRC-128 is fully invertible for input strings < 16 bytes, because of the linearity. However, if we assume the salt is 16 bytes (as in NSEC2), or longer, it is no longer possible to invert it. > --On 04 November 2004 18:52 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> Since CRC-128 is not preimage resistant, an attacker can find many >> domain names that produce 17, 42, 96, or any other CRC-128 value, as >> the output. What does he gain by doing so? > > If it's not preimage resistant, these can then be sifted by (for instance) > only looking at ones which match /[a-zA-Z-]+/. Unless I'm missing something. I don't understand. Are you saying that th attacker finds domain names /[a-zA-Z-]+/ that "hash" to 17, 42, or 96? That's possible. But then what does he do with does names? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:39:20 +0100 Lines: 73 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411050930150.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 10:45:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 66 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:qzYSxpjW4unWpGHmLvJNa8T5Y7w= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > On Thu, 4 Nov 2004, Simon Josefsson wrote: > >> Ben Laurie <ben@algroup.co.uk> writes: >> >> > It does require preimage resistance, though, which is not a property you >> > find much in non-cryptographic hash functions. >> >> Could you explain when the preimage resistance property required, to >> prevent an attack? > > I came to a similar question when writing the DNSNR/NSEC3 draft (section > 3.2.2/3.2.3). The following analysis applies to the second-preimage > resistance property. That was a useful section. I believe it, and similar sections on other properties (like non-invertible and preimage resistance), should go into a document based on the hashed-NSEC idea. Some specific comment: > A collision resistant hash function has a second-preimage resistance > property. If you want, you may add a reference to this excellent paper for the background: http://www.cs.ucdavis.edu/~rogaway/papers/relates.html > The probability of finding a > second preimage is 1 in 2^160 for SHA-1 on average. This is only conjectured, right? > Assuming an adversary is capable of mounting such an extreme, the > actual damage is that a response message can be generated which > claims that a certain QNAME (i.e. the second pre-image) does exist, > while in reality QNAME does not exist (aka false positive), which > will either cause a security aware resolver to re-query for the > non-existent name, or to fail the initial query. Note that the > adversary can't mount this attack on an existing name, solely on a > name that the adversary can't choose and does not yet exist. One might make it explicit that this result in a Denial-Of-Service attack. Something which is possible anyway. > 3.2.3 Possible Hash Value Truncation Method > > The previous sections outlined the low probability and low impact of > a second-preimage attack. When impact and probability are low, while > space in a DNS message is costly, truncation is tempting. Truncation > might be considered to allow for shorter ownernames and rdata in case > of labels with hash values. The author seeks comfirmation on the > assumption that truncation decreases resilliance on colliding hash > values though the overall security model does not significantly > deteriorate. For what it's worth, I cannot prove that truncation is safe, so I also encourage more investigation into truncation. In an earlier version of the NO draft, it was suggested that truncation should be done to the closest unique prefix. Obviously, that didn't work, but it took me a week to realize it. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:01:12 +0000 Lines: 44 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:06:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Thu, 4 Nov 2004, Simon Josefsson wrote: > > >>Roy Arends <roy@dnss.ec> writes: >> >> >>>Multiple salts are no problem, as long as every name is salted with each >>>salt. For every salt there will exist an NSEC-chain. >> >>Could you expand on the justification of this requirement? In >>particular, what will break if one of the chains do not cover all >>names? > > > Sure, you must have at least one entire NSEC-chain. A second set of NSEC's > does not have to cover every name. But the second set of NSEC's has to be > complete before the first set is deteriorated. > > Sidenote: the NSEC's from the incomplete set of names MUST NOT form a > complete chain. Because you can't predict the order of the hashes, although this requirement is theoretically believable, it is practically impossible to generate a partial NSEC chain without hashing all names first, in which case you may as well generate a complete one. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 11:03:00 +0100 Lines: 43 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:07:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 36 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:oR0cclODhOJHWmHfWb4+ptePcLU= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > On Thu, 4 Nov 2004, Simon Josefsson wrote: > >> Roy Arends <roy@dnss.ec> writes: >> >> > Multiple salts are no problem, as long as every name is salted with each >> > salt. For every salt there will exist an NSEC-chain. >> >> Could you expand on the justification of this requirement? In >> particular, what will break if one of the chains do not cover all >> names? > > Sure, you must have at least one entire NSEC-chain. A second set of NSEC's > does not have to cover every name. But the second set of NSEC's has to be > complete before the first set is deteriorated. > > Sidenote: the NSEC's from the incomplete set of names MUST NOT form a > complete chain. How do this statement match your earlier (quoted above)? I read your first post as suggesting that multiple salts would work, if you create a complete chain using each salt. Now you are saying the opposite? I.e., multiple salts work, but there must only be one complete chain? FWIW, I would agree with your last message. One chain with one salt is how you typically would start out, and later you can introduce new salts, and there is no requirement to produce a complete chain with the new salt. I'm not sure I understand why the new salt cannot be used to build a complete chain, though. Perhaps I misunderstood your first post, hence my question above. Thanks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:01:36 +0000 Lines: 38 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:07:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu654ly2yn.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Roy Arends <roy@dnss.ec> writes: > > >>Multiple salts are no problem, as long as every name is salted with each >>salt. For every salt there will exist an NSEC-chain. > > > Could you expand on the justification of this requirement? In > particular, what will break if one of the chains do not cover all > names? > > Of course, there must be some applicable NSEC record for each > question-tuple. But do they also have to be part of a full chain? > > To me, it seems the interesting property should be that clients should > be able to verify the returned NSECbis record. Whether or not the > NSECbis records involved form a complete chain or not does not seem to > be critical to me. > > One situation where having partial hashed-NSEC chains may be with > dynamic update. A partial chain will deny records that exist. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:03:06 +0000 Lines: 49 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:08:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluvfclwlgq.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>It does require preimage resistance, though, which is not a property you >>find much in non-cryptographic hash functions. > > > Could you explain when the preimage resistance property required, to > prevent an attack? > > I'm trying to work out a complete example (although simplified): > > Let's say a client query for ("foo.example",IN,A). Let's say > CRC128(foo.example) = 42. > > Server realize "foo.example" doesn't exist, and return the NSECbis RR > that has a range that include 42: > > 17 NSECbis ... 96 ... > 17 RRSIG ... NSECbis ... > > The client verify the signature, and notices that 42 is in range, and > return a "domain does not exist" error, or whatever. > > Since CRC-128 is not preimage resistant, an attacker can find many > domain names that produce 17, 42, 96, or any other CRC-128 value, as > the output. What does he gain by doing so? A filtered list of domains to query for existence - i.e. a very cheap brute force attack. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:04:25 +0000 Lines: 36 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <EDBA1D3C2161047C978E7937@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:08:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <EDBA1D3C2161047C978E7937@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > > > --On 04 November 2004 18:52 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> Since CRC-128 is not preimage resistant, an attacker can find many >> domain names that produce 17, 42, 96, or any other CRC-128 value, as >> the output. What does he gain by doing so? > > > If it's not preimage resistant, these can then be sifted by (for instance) > only looking at ones which match /[a-zA-Z-]+/. Unless I'm missing > something. There is no requirement to recognise the form of the name. If you can invert the hash function (even if the inverse is multi-valued) then you get a list of names that might exist that is very much smaller than the exhaustive list. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:06:21 +0000 Lines: 44 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:13:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <A558EB4247020EDB1980A8FB@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > > > --On 04 November 2004 17:08 +0100 Simon Josefsson <jas@extundo.com> wrote: > >> However, as far as I understand, the hashed-NSEC idea does not require >> a cryptographic strong hash function. > > > Depends which hash property you are talking about. What you don't > want is inversion (i.e. you know H(x), can you discover x?). It > requires some cryptographically strong properties to prevent this > (or rather make the problem computationally infeasible). > >> I suspect the idea would work >> just as well with CRC-128. So if my understanding is correct, >> supporting arbitrary hash algorithms (possibly via an IANA registry) >> would not serve any purpose, except to decrease interoperability. > > > I may be partly responsible for this confusion. I jumped on the proposal > to support alternative hash algorithms for various reasons: > > a) When we were back discussing the possibilities of hash collisions (i.e. > H(a)=H(b) where a != b), I pointed out these only happen because (most) > hash functions are not guaranteed to be injective (in fact the ones we > consider are guaranteed not to be injective, i.e. we know collisions will > exist, they are just infinitesimally rare and don't know where they are). All fixed-length hash functions have this property (obviously). -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 10:20:09 +0000 Lines: 90 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <Pine.GSO.4.55.0411041343510.12330@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:30:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411041343510.12330@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > [I wrote the below message last night before seeing this morning's > very interesting exchange. Sorry for some redundancy.] > > Yesterday, I said: > > >>Allowing for coexistence [of different salts/hashes] makes [changing >>salts/hashes] much easier, assuming coexistence works. > > > I think I've been looking at "coexistence" too naively -- there's more > subtlety here than I first realized, and probably more than I realize > now. > > First, the term "coexistence" is overloaded, at least the way I was > looking at it. > > One form of "coexistence" is "multiple hashes/salts[1] are in use in a > zone at one time". Or: "some NSEC records in a zone can use hash/salt > X, while some use Y". Or even: "each NSEC record may have its own > unique salt". As I was imagining it, that doesn't work. Its clear that doesn't work in practice, though there isn't anything theoretically wrong - the issue is that finding a set of salts that covers the zone would be hard. > Unless > someone beats me to it, I can more about that in a later message. > I'll keep using the word "coexistence" for this, since it's about > what data is actually in the zone file. > > The other thing I was describing with that label was "a client, having > seen (and cached) an NSEC record from a zone then seeing another NSEC > using a different hash/salt will behave as expected". This doesn't > necessarily mean that both hashes/salts are "in use" at the same time > -- perhaps the zone entirely changed hashes/salts, but some NSECs with > the old hash/salt are still cached in upstream caches. I suspect this > just works, but I think we haven't thought about it enough (nor > implemented enough code and tested it enough). You may not have thought about it enough, but it seems to me quite obvious it works. The reason being that an NSEC record denies an interval, and that interval is defined entirely by the NSEC record alone, so the age of it is immaterial (except, of course, that new records may now exist in the interval, but that is a TTL issue, not a hashing/salting issue). > If not, it MAY be easy > to make work. In any case, "coexistence" is a bad label for this. > For want of a better term, I'll call it "non-interference (of multiple > hashes/salts from the same zone)", since it refers more to client > behavior than zone contents. > > To summarize using these new labels: as NSEC2/DNSNR are defined, > multiple hashes/salts MAY be non-interfering. "Coexistence" as > described above, does not work. [Addendum, as of Thursday morning: > since last night, Roy and Ben have talked about why. Simon's question > suggests that more explanation is needed.] Which question? > > -- Sam > > [1] Throughout this message, I use "salt/hash" to mean "salt and/or > hash function and/or number of hash iterations", since changing either > is approximately equivalent. Changing hash functions is actually a > bigger problem than changing salts or number of iterations, for > reasons to be talked about later. I don't buy this. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 11:28:35 +0100 Lines: 34 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:35:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 27 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:hWu2TJSk8nL6MCKtb8lG7XLCVTs= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: >> Since CRC-128 is not preimage resistant, an attacker can find many >> domain names that produce 17, 42, 96, or any other CRC-128 value, as >> the output. What does he gain by doing so? > > A filtered list of domains to query for existence - i.e. a very cheap > brute force attack. Ah, I understand now. However, the traditional "preimage resistance" property is how difficult it is to find ONE input that hash to a known value. Even if that is possible, it seems it could still be computationally infeasible to derivate a list of such names, containing enough entries to be useful in a dictionary or brute force attack. So preimage resistance seem to be a stronger property than what is needed to guard for this attack. Perhaps we could define "enumerated preimage resistance" to be the property applicable here. To clarify my position: Hashed-NSEC should ideally use the strongest known hash function, to be on the safe side. But considering how the hashed-NSEC idea fail given various "bad" hashes is a good exercise in understanding the assumptions. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 11:33:49 +0100 (CET) Lines: 81 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 11:41:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluu0s4fwa3.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Simon Josefsson wrote: > Roy Arends <roy@dnss.ec> writes: > > > On Thu, 4 Nov 2004, Simon Josefsson wrote: > > > >> Roy Arends <roy@dnss.ec> writes: > >> > >> > Multiple salts are no problem, as long as every name is salted with each > >> > salt. For every salt there will exist an NSEC-chain. > >> > >> Could you expand on the justification of this requirement? In > >> particular, what will break if one of the chains do not cover all > >> names? > > > > Sure, you must have at least one entire NSEC-chain. A second set of NSEC's > > does not have to cover every name. But the second set of NSEC's has to be > > complete before the first set is deteriorated. > > > > Sidenote: the NSEC's from the incomplete set of names MUST NOT form a > > complete chain. > > How do this statement match your earlier (quoted above)? > > I read your first post as suggesting that multiple salts would work, > if you create a complete chain using each salt. CHAIN is the keyword. My statement should have been: Multiple CHAINS are no problem, as long as every name is salted with each salt. For every salt there will exist an NSEC-chain. With NSEC chain I mean an ordered circulair linked list of optionally hashed ownernames. > Now you are saying > the opposite? I.e., multiple salts work, but there must only be one > complete chain? No. multiple salts work, but there must at least be one complete chain. > FWIW, I would agree with your last message. One chain with one salt > is how you typically would start out, and later you can introduce new > salts, and there is no requirement to produce a complete chain with > the new salt. As long as the 'old' chain is complete. > I'm not sure I understand why the new salt cannot be used to build a > complete chain, though. It can, no problem. This is what I ment: given four names (a,b,c,d) and salt X, you'd start out with 1 2 3 4 H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) This is a circular ordered list (assume H(name,salt)=name). Now we introduce salt Y for two names (b, c) but not for (a,d) We are able to create the NSEC: H(b,Y)-H(c,Y) But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) Since H(c,Y)-H(b,Y) would deny existence of d. The new salt can be used to form NSEC records, but to be able to form a _complete_chain_, all names must be included in the chain. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 12:10:29 +0100 (CET) Lines: 33 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411050930150.2709@trinitario.schlyter.se> <ilu4qk4hbxz.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 12:19:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilu4qk4hbxz.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Simon Josefsson wrote: > Some specific comment: > > > A collision resistant hash function has a second-preimage resistance > > property. > > If you want, you may add a reference to this excellent paper for the > background: > > http://www.cs.ucdavis.edu/~rogaway/papers/relates.html Thanks, great paper. > > The probability of finding a > > second preimage is 1 in 2^160 for SHA-1 on average. > > This is only conjectured, right? Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas non caperet. :-) Yes, this is only conjectured. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 11:49:30 +0000 Lines: 39 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 12:55:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > This is what I ment: > > given four names (a,b,c,d) and salt X, you'd start out with > > 1 2 3 4 > H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) > > > This is a circular ordered list (assume H(name,salt)=name). > > Now we introduce salt Y for two names (b, c) but not for (a,d) > > We are able to create the NSEC: H(b,Y)-H(c,Y) > But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) > Since H(c,Y)-H(b,Y) would deny existence of d. This is incorrect, since we do not have a H(a) < H(b). That is, we don't know whether H(a) or H(d) falls between H(b) and H(c) or not. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 12:52:53 +0100 (CET) Lines: 33 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 12:58:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418B68CA.1060308@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Ben Laurie wrote: > Roy Arends wrote: > > This is what I ment: > > > > given four names (a,b,c,d) and salt X, you'd start out with > > > > 1 2 3 4 > > H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) > > > > > > This is a circular ordered list (assume H(name,salt)=name). > > > > Now we introduce salt Y for two names (b, c) but not for (a,d) > > > > We are able to create the NSEC: H(b,Y)-H(c,Y) > > But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) > > Since H(c,Y)-H(b,Y) would deny existence of d. > > This is incorrect, since we do not have a H(a) < H(b). assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. > That is, we don't know whether H(a) or H(d) falls between H(b) and H(c) > or not. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 12:07:06 +0000 Lines: 54 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 13:14:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilumzxwfv3g.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>>Since CRC-128 is not preimage resistant, an attacker can find many >>>domain names that produce 17, 42, 96, or any other CRC-128 value, as >>>the output. What does he gain by doing so? >> >>A filtered list of domains to query for existence - i.e. a very cheap >>brute force attack. > > > Ah, I understand now. > > However, the traditional "preimage resistance" property is how > difficult it is to find ONE input that hash to a known value. This is second preimage resistance, surely? > Even if > that is possible, it seems it could still be computationally > infeasible to derivate a list of such names, containing enough entries > to be useful in a dictionary or brute force attack. So preimage > resistance seem to be a stronger property than what is needed to guard > for this attack. Perhaps we could define "enumerated preimage > resistance" to be the property applicable here. We don't care whether a list is available or just a single preimage, surely, so long as the actual name hashed is in the list. > To clarify my position: Hashed-NSEC should ideally use the strongest > known hash function, to be on the safe side. But considering how the > hashed-NSEC idea fail given various "bad" hashes is a good exercise in > understanding the assumptions. Indeed. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Requirements Matrix updated Date: Fri, 05 Nov 2004 12:15:37 +0000 Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 13:21:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: DNSEXT WG <namedroppers@ops.ietf.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have updated the requirements matrix: http://www.links.org/dnssec/requirements-matrix-3.htm I have added rows for the proposals on the table which I perceive as having noticable support. Feel free to point out others. These are: NSEC2/NSEC3 with modifications that are obvious from discussion but may not be in the I-Ds yet, NSEC2/NSEC3 as above but with banning of wildcards, and synthesized NSEC records. Not surprisingly, these proposals are pretty much orthogonal (that is, the sets of requirements they do not satisfy are disjoint). I hope this is helpful. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 13:27:22 +0100 Lines: 68 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 13:41:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> X-Hashcash: 1:22:041105:ben@algroup.co.uk::7vdQC8gKgEiaWjq1:000000000000000000000000000000000000000000000JYX X-Hashcash: 1:22:041105:namedroppers@ops.ietf.org::uW8uZgHXtsVeFLZI:0000000000000000000000000000000000004H8/ In-Reply-To: <418B6CEA.1040002@algroup.co.uk> (Ben Laurie's message of "Fri, 05 Nov 2004 12:07:06 +0000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on yxa-iv X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: > Simon Josefsson wrote: >> Ben Laurie <ben@algroup.co.uk> writes: >> >>>>Since CRC-128 is not preimage resistant, an attacker can find many >>>>domain names that produce 17, 42, 96, or any other CRC-128 value, as >>>>the output. What does he gain by doing so? >>> >>> A filtered list of domains to query for existence - i.e. a very >>> cheap brute force attack. >> Ah, I understand now. >> However, the traditional "preimage resistance" property is how >> difficult it is to find ONE input that hash to a known value. > > This is second preimage resistance, surely? I think it depends on which of the hash value you are interested in. You only know the input to the hash function for H(x) = 42, in my example it was x = "foo.example", but for H(x) = 17, H(x) = 96 or any other output, you don't a priori know x. So for H(x) = 42, the x is known, so it is the second preimage resistance property that applies. But for H(x) != 42, the x is not known, so it is the preimage resistance property that applies. That is unless I have misunderstood hash function properties, somehow. There is a nice graphical explanation at the bottom of: http://www.unixwiz.net/techtips/iguide-crypto-hashes.html >> Even if >> that is possible, it seems it could still be computationally >> infeasible to derivate a list of such names, containing enough entries >> to be useful in a dictionary or brute force attack. So preimage >> resistance seem to be a stronger property than what is needed to guard >> for this attack. Perhaps we could define "enumerated preimage >> resistance" to be the property applicable here. > > We don't care whether a list is available or just a single preimage, > surely, so long as the actual name hashed is in the list. There could be many preimages, and only one of them (i.e., the original existing name that hash to the known value) give any information to the attacker. So even if an attacker is able to break the preimage resistance property, it might not help unless he can create many such preimages, and use them as input to a dictionary or brute force attack, to discover the real name that hash to that particular value. Perhaps this is just the non-invertible property, after all, with a special oracle. What I mean is: The attacker is able to invert the hash function, if she can break the (enumerated) preimage resistance and has access to a oracle that knows which names exists (i.e., online query to DNS itself). Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 13:17:02 +0000 Lines: 101 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> <iluis8kfplh.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 14:24:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluis8kfplh.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > >>Simon Josefsson wrote: >> >>>Ben Laurie <ben@algroup.co.uk> writes: >>> >>> >>>>>Since CRC-128 is not preimage resistant, an attacker can find many >>>>>domain names that produce 17, 42, 96, or any other CRC-128 value, as >>>>>the output. What does he gain by doing so? >>>> >>>>A filtered list of domains to query for existence - i.e. a very >>>>cheap brute force attack. >>> >>>Ah, I understand now. >>>However, the traditional "preimage resistance" property is how >>>difficult it is to find ONE input that hash to a known value. >> >>This is second preimage resistance, surely? > > I think it depends on which of the hash value you are interested in. > > You only know the input to the hash function for H(x) = 42, in my > example it was x = "foo.example", but for H(x) = 17, H(x) = 96 or any > other output, you don't a priori know x. > > So for H(x) = 42, the x is known, so it is the second preimage > resistance property that applies. > > But for H(x) != 42, the x is not known, so it is the preimage > resistance property that applies. > > That is unless I have misunderstood hash function properties, somehow. > There is a nice graphical explanation at the bottom of: > > http://www.unixwiz.net/techtips/iguide-crypto-hashes.html > > >>>Even if >>>that is possible, it seems it could still be computationally >>>infeasible to derivate a list of such names, containing enough entries >>>to be useful in a dictionary or brute force attack. So preimage >>>resistance seem to be a stronger property than what is needed to guard >>>for this attack. Perhaps we could define "enumerated preimage >>>resistance" to be the property applicable here. >> >>We don't care whether a list is available or just a single preimage, >>surely, so long as the actual name hashed is in the list. > > > There could be many preimages, and only one of them (i.e., the > original existing name that hash to the known value) give any > information to the attacker. > > So even if an attacker is able to break the preimage resistance > property, it might not help unless he can create many such preimages, > and use them as input to a dictionary or brute force attack, to > discover the real name that hash to that particular value. > > Perhaps this is just the non-invertible property, after all, with a > special oracle. What I mean is: The attacker is able to invert the > hash function, if she can break the (enumerated) preimage resistance > and has access to a oracle that knows which names exists (i.e., online > query to DNS itself). On reflection, I believe the property we are after is not a standard one for cryptographic hashes, which is probably why we're arguing about which of the standard properties it is! As you say, what we want is that the hash should not be invertible - or, more strictly, that we shouldn't be able to produce a list of inputs amongst which the actual input is guaranteed (or even likely) to be. Of course, any hash with that does not have this property will not be preimage or second preimage resistant (the latter if the list is always longer than one element), but a hash which was OK for our use might not be cryptographically strong. For example, if it were possible to produce a list of inputs for a particular output which was guaranteed to _not_ include the original input, this would work for us, but not as a cryptographic hash. Its trivial to produce artificial examples of this, but I can't think of a real hash function with the property. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 14:15:21 +0000 Lines: 42 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 15:22:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Fri, 5 Nov 2004, Ben Laurie wrote: > > >>Roy Arends wrote: >> >>>This is what I ment: >>> >>>given four names (a,b,c,d) and salt X, you'd start out with >>> >>> 1 2 3 4 >>>H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) >>> >>> >>>This is a circular ordered list (assume H(name,salt)=name). >>> >>>Now we introduce salt Y for two names (b, c) but not for (a,d) >>> >>>We are able to create the NSEC: H(b,Y)-H(c,Y) >>>But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) >>>Since H(c,Y)-H(b,Y) would deny existence of d. >> >>This is incorrect, since we do not have a H(a) < H(b). > > > assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. Choosing things for clarity that aren't true is not usually a great idea! -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: dee3@pothole.com Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 5 Nov 2004 09:31:54 -0500 (EST) Lines: 79 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Donald.Eastlake@motorola.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 15:45:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: dee3@localhost.localdomain To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411042242340.27766@filbert> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam, Thanks for all your comments. I'll review them more closely and respond at greater length but here are a couple of intial comments: I believe that the format of DNS keys should be defined independently of RR codes. As long as it works technically, I don't see why you would want to prohibit using a particular key format in a particular RR type. The original versions of this draft did include a signature format. Years ago, the DNSEXT chair made the removal of this a condition for accepting the draft as a WG draft. Although some have always had feelings against ECC due to the patent thicket that has surrounded much of it, I have always thought that the compact nature of ECC keys and signatures, at least in comparison with RSA, was a good fit for UDP DNS and there should be defined formats for interoperability for those who want to use it. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 4 Nov 2004, Samuel Weiler wrote: > Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST) > From: Samuel Weiler <weiler@tislabs.com> > To: dee3@pothole.com > Cc: namedroppers@ops.ietf.org > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > On Thu, 4 Nov 2004, Samuel Weiler wrote: > >> Be much more explicit about which of DNSKEY and/or KEY ... > > Further comments after some more reflection. > > First, I'd like to thank Donald for his efforts to put this document > (and the HMAC SHA TSIG doc) together. There are very few people with > both the ability to follow the current crypto research and the > willingness to bring that knowledge back to the IETF in a useful form. > We should applaud Donald for his willingness to do that. > > I'd also like to say that I'm not particularly averse to storing > random data in the DNS. > > That said, it's not clear to me why we're trying to store ECC keys in > the DNS nor, given that uncertainty, what RR type we might want to use > to store them. Of late, we've been choosing to separate data into new > type codes based on the use of the data, not the content or format of > the data. For cryptographic keys, in particular, we've tried to reuse > key storage formats (we reused the 2536 and 3110 formats in DNSKEY and > IPSECKEY), but we've allocated new RR types for different data users. > See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt > section 2.6 (now at RFC-Editor). > > Since we're not defining a SIG nor RRSIG format for ECC, it would > appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) > nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and > RFC3755. Who are they useful for? (Does anyone really want to store > ECC keys in the DNS?) And what does that suggest about what RR > type(s) they should be stored in? This all feeds into the IANA > section questions I posted earlier today. > > Looking further ahead, I also wonder if this record format's > flexibility might be dangerous. Can we imagine users of data that > can't effectively use all of the different types of eliptic curve keys > that can be stored in this RR? If so, we may be creating another > subtyping problem. > > -- Sam > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 15:54:15 +0100 (CET) Lines: 77 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:01:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418B8AF9.6010800@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Ben Laurie wrote: > Roy Arends wrote: > > On Fri, 5 Nov 2004, Ben Laurie wrote: > > > > > >>Roy Arends wrote: > >> > >>>This is what I ment: > >>> > >>>given four names (a,b,c,d) and salt X, you'd start out with > >>> > >>> 1 2 3 4 > >>>H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) > >>> > >>> > >>>This is a circular ordered list (assume H(name,salt)=name). > >>> > >>>Now we introduce salt Y for two names (b, c) but not for (a,d) > >>> > >>>We are able to create the NSEC: H(b,Y)-H(c,Y) > >>>But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) > >>>Since H(c,Y)-H(b,Y) would deny existence of d. > >> > >>This is incorrect, since we do not have a H(a) < H(b). > > > > assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. > > Choosing things for clarity that aren't true is not usually a great idea! What is not true about the statement H(name,salt)=name ? I chose that to make sure the ordered hash-chain is linear to the original name-chain. Is it that unthinkable that one implements a NULL hash function ? It is even in the DNSNR draft to have none-hashed values for the DNSNR/NSEC3 owner name. But, lets do the excersize without linearity. Lets NOT assume H(name,salt)=name, and go with a real hash function H(name,salt)=hash. given four names (a,b,c,d) and salt X, you'd start out with H(a,X)=g H(b,X)=z H(c,X)=l H(d,X)=q You'd get: 1 2 3 4 H(a,X)-H(c,X)-H(d,X)-H(b,X)-H(a,X) or, maybe more clear: g - l - q - z - g This is a circular ordered list. Now we introduce salt Y for two names (b, c) but not for (a,d), where H(b,Y)=s H(c,Y)=p We are able to create the NSEC: H(c,Y)-H(b,Y) or [p - s] But not the NSEC chain: H(c,Y)-H(b,Y)-H(c,Y) Since H(b,Y)-H(c,Y) would deny existence of H(d,Y) which is not H(b,Y) nor H(c,Y). Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Scott Rose" <scottr@nist.gov> Subject: question on draft-josefsson-rfc2538bis-00 Date: Fri, 5 Nov 2004 10:18:55 -0500 Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:25:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "DNSEXT WG" <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Reading over the drafts on the DNSEXT agenda for next week, I have a question on the algorithm field of the CERT RDATA: Section 2 says that if the algorithm of the key in the CERT RR is not defined in DNSSEC, to use RESERVED (0). I was wondering why this choice was made and not the PRIVATEDNS code (253)? There is a private code defined for the certificate type field. Scott **************************************** Scott Rose Adv. Network Tech. Div., NIST +1 301-975-8439 http://www-x.antd.nist.gov/dnssec/ **************************************** -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 05 Nov 2004 16:31:06 +0100 Lines: 27 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:40:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 20 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:fC9sYKFVI6x1muSblYZWvPKAo88= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler <weiler@tislabs.com> writes: > Since we're not defining a SIG nor RRSIG format for ECC, it would > appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) > nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and > RFC3755. Who are they useful for? (Does anyone really want to store > ECC keys in the DNS?) If I remember correctly, RFC 2538 uses the same IANA name space as the rest of DNSSEC for the key algorithms. Perhaps someone is using ECC for X.509 or OpenPGP data. So a specification for ECC, and an entry in the IANA DNSKEY key algorithm registry, seem useful. I believe it would be a too radical change to alter this now, if we want RFC 2538bis to move forward as a DRAFT STANDARD. Even if that isn't a consideration, I'm not convinced there is a strong motivation for changing this now. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: question on draft-josefsson-rfc2538bis-00 Date: Fri, 05 Nov 2004 16:49:35 +0100 Lines: 34 References: <ANECIHCPCBDLLEJLCOPGIEFADBAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 16:59:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 27 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:JzqIDz1ZI3fsMX1tBnggqRRhscg= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" <scottr@nist.gov> writes: > Reading over the drafts on the DNSEXT agenda for next week, I have a > question on the algorithm field of the CERT RDATA: > > Section 2 says that if the algorithm of the key in the CERT RR is not > defined in DNSSEC, to use RESERVED (0). I was wondering why this choice was > made and not the PRIVATEDNS code (253)? There is a private code defined > for the certificate type field. I don't know more than what's in RFC 2538. Donald? Olafur? PRIVATEDNS does not seem appropriate, draft-ietf-dnsext-dnssec-records: Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encoded domain name, which MUST NOT be compressed. That doesn't match the RRDATA specified in RFC 2538. However, using PRIVATEOID (254) might be appropriate for the X.509 certificate and CRLs, since they are prefixed with an OID. However that would not be compatible with RFC 2538. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 16:09:57 +0000 Lines: 100 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 17:19:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Fri, 5 Nov 2004, Ben Laurie wrote: > > >>Roy Arends wrote: >> >>>On Fri, 5 Nov 2004, Ben Laurie wrote: >>> >>> >>> >>>>Roy Arends wrote: >>>> >>>> >>>>>This is what I ment: >>>>> >>>>>given four names (a,b,c,d) and salt X, you'd start out with >>>>> >>>>> 1 2 3 4 >>>>>H(a,X)-H(b,X)-H(c,X)-H(d,X)-H(a,X) >>>>> >>>>> >>>>>This is a circular ordered list (assume H(name,salt)=name). >>>>> >>>>>Now we introduce salt Y for two names (b, c) but not for (a,d) >>>>> >>>>>We are able to create the NSEC: H(b,Y)-H(c,Y) >>>>>But not the NSEC chain: H(b,Y)-H(c,Y)-H(b,Y) >>>>>Since H(c,Y)-H(b,Y) would deny existence of d. >>>> >>>>This is incorrect, since we do not have a H(a) < H(b). >>> >>>assume H(name,salt)=name, as I wrote above. I chose linearity for clarity. >> >>Choosing things for clarity that aren't true is not usually a great idea! > > > What is not true about the statement H(name,salt)=name ? I chose that to > make sure the ordered hash-chain is linear to the original name-chain. Is > it that unthinkable that one implements a NULL hash function ? It is certainly not unthinkable, but non-NULL hash functions do not behave like NULL ones. What is not true about H(name,salt)=name is that it does not apply to all hash functions. > It is even > in the DNSNR draft to have none-hashed values for the DNSNR/NSEC3 owner > name. > > But, lets do the excersize without linearity. > > Lets NOT assume H(name,salt)=name, and go with a real hash function > H(name,salt)=hash. given four names (a,b,c,d) and salt X, you'd start out > with > > H(a,X)=g > H(b,X)=z > H(c,X)=l > H(d,X)=q > > You'd get: > > 1 2 3 4 > H(a,X)-H(c,X)-H(d,X)-H(b,X)-H(a,X) > > or, maybe more clear: > > g - l - q - z - g > > This is a circular ordered list. > > Now we introduce salt Y for two names (b, c) but not for (a,d), where > > H(b,Y)=s > H(c,Y)=p > > We are able to create the NSEC: H(c,Y)-H(b,Y) or [p - s] > But not the NSEC chain: H(c,Y)-H(b,Y)-H(c,Y) > Since H(b,Y)-H(c,Y) would deny existence of H(d,Y) which is not H(b,Y) > nor H(c,Y). The problem is that, for example, H(a,Y) might be q, so H(c,Y)-H(b,Y) denies (incorrectly) the existence of a. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 5 Nov 2004 17:16:21 +0100 (CET) Lines: 14 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> <418BA5D5.90108@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 17:22:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418BA5D5.90108@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Ben Laurie wrote: > The problem is that, for example, H(a,Y) might be q, so H(c,Y)-H(b,Y) > denies (incorrectly) the existence of a. I totally agree. This means every name has to be hashed for each salt. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 16:23:11 +0000 Lines: 25 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> <ilu654ly2yn.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411042124190.2709@trinitario.schlyter.se> <iluu0s4fwa3.fsf@latte.josefsson.org> <Pine.BSO.4.56.0411051115390.2709@trinitario.schlyter.se> <418B68CA.1060308@algroup.co.uk> <Pine.BSO.4.56.0411051250570.2709@trinitario.schlyter.se> <418B8AF9.6010800@algroup.co.uk> <Pine.BSO.4.56.0411051543250.2709@trinitario.schlyter.se> <418BA5D5.90108@algroup.co.uk> <Pine.BSO.4.56.0411051711430.2709@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 17:30:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411051711430.2709@trinitario.schlyter.se> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Fri, 5 Nov 2004, Ben Laurie wrote: > >>The problem is that, for example, H(a,Y) might be q, so H(c,Y)-H(b,Y) >>denies (incorrectly) the existence of a. > > > I totally agree. This means every name has to be hashed for each salt. Right. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 17:28:32 +0000 Lines: 23 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <EDBA1D3C2161047C978E7937@[192.168.100.25]> <418B5029.4060207@algroup.co.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 18:34:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <418B5029.4060207@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 05 November 2004 10:04 +0000 Ben Laurie <ben@algroup.co.uk> wrote: >> If it's not preimage resistant, these can then be sifted by (for >> instance) only looking at ones which match /[a-zA-Z-]+/. Unless I'm >> missing something. > > There is no requirement to recognise the form of the name. If you can > invert the hash function (even if the inverse is multi-valued) then you > get a list of names that might exist that is very much smaller than the > exhaustive list. My point is knowing what likely domain names look like means you are able to sift such a list very fast (without a query). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 17:27:31 +0000 Lines: 53 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> <iluactwhcpz.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 18:34:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluactwhcpz.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon, >>> However, as far as I understand, the hashed-NSEC idea does not require >>> a cryptographic strong hash function. >> >> Depends which hash property you are talking about. What you don't >> want is inversion (i.e. you know H(x), can you discover x?). It >> requires some cryptographically strong properties to prevent this >> (or rather make the problem computationally infeasible). > > Ah, right. This should be mentioned as the primary requirement on the > chosen hash. > > CRC-128 is fully invertible for input strings < 16 bytes, because of > the linearity. However, if we assume the salt is 16 bytes (as in > NSEC2), or longer, it is no longer possible to invert it. I am not a cryptographer, but many functions that munge things together losely called hash functions are not invertible for some values, and are trivially invertible for others. CRC-128 being an example if what you've said are correct. Hash functions may be overkill, but at least they provably do the job. >>> Since CRC-128 is not preimage resistant, an attacker can find many >>> domain names that produce 17, 42, 96, or any other CRC-128 value, as >>> the output. What does he gain by doing so? >> >> If it's not preimage resistant, these can then be sifted by (for >> instance) only looking at ones which match /[a-zA-Z-]+/. Unless I'm >> missing something. > > I don't understand. Are you saying that th attacker finds domain > names /[a-zA-Z-]+/ that "hash" to 17, 42, or 96? That's possible. > But then what does he do with does names? I mean if you have Y=H(x) to a small set of possibles x1, x2, ... for which H(x(n))=Y (i.e. they all have the same hash value), then you can reasonably trivially eliminate most of the set by looking at characteristics. For instance, if the hash function was "take the octet value as a number, and take it modulo a large prime", then you could sequentially add the large prime to H(x) and see when all octets fall match the regexp above. That would allow you to sift through the names very quickly. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 17:36:11 +0000 Lines: 22 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> <iluis8kfplh.fsf@latte.josefsson.org> <418B7D4E.7040501@algroup.co.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 18:44:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com> In-Reply-To: <418B7D4E.7040501@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 05 November 2004 13:17 +0000 Ben Laurie <ben@algroup.co.uk> wrote: > On reflection, I believe the property we are after is not a standard one > for cryptographic hashes, which is probably why we're arguing about which > of the standard properties it is! Seems to me that second preimage resistance is a sufficient but (perhaps) not a necessary condition (though I am not sure we've proved it's not necessary). As such, I'd have thought the obvious thing to do was to go for a function with the property, then truncate to appropriate length. I cannot see any *disadvantage* in doing that, unless someone can show there is a faster algorithm which is not invertible. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 18:30:43 +0000 Lines: 52 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <418A61F7.7030603@algroup.co.uk> <iluvfclwlgq.fsf@latte.josefsson.org> <418B4FDA.2040008@algroup.co.uk> <ilumzxwfv3g.fsf@latte.josefsson.org> <418B6CEA.1040002@algroup.co.uk> <iluis8kfplh.fsf@latte.josefsson.org> <418B7D4E.7040501@algroup.co.uk> <931BD0B0747AAEBA63339E5B@[192.168.0.4]> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 19:42:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com> In-Reply-To: <931BD0B0747AAEBA63339E5B@[192.168.0.4]> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben / Simon, --On 05 November 2004 17:36 +0000 Alex Bligh <alex@alex.org.uk> wrote: > Seems to me that second preimage resistance is a sufficient but (perhaps) > not a necessary condition (though I am not sure we've proved it's not > necessary). Actually, on further thought, and a quick look at the following URL to check my terminology is right: http://www.bletchleypark.net/cryptology/Hash_Functions.pdf I think if we assume (in deployment terms) the size of a domain is of comparable size to the size of a distributed attack network (or at least is not orders of magnitude larger), then the property we want is that knowing H(x) does not help us find x. This isn't quite second pre-image resistance - it's one-way or (first) pre-image resistance. I believe that this is a weaker requirement than second pre-image resistance as in second preimage resistance you are given an extra piece of information: some (other) value that hashes to the same number. So I think what we need is first-preimage resistance (and that is both necessary and sufficient) FOR THE PURPOSE OF PREVENTING ENUMERATION. However, we've also decided that people being able to find things that collide (i.e. knowing x, H(x), find a y such that H(y)=H(x)), is a bad thing (see archives). If we have first preimage resistance but not second preimage resistance, then it's going to be (by definition) computationally feasible to create collisions. Therefore, I think to be safe both from enumerations, and deliberate collisions, assuming a distributed attack, both first and second preimage resistance is both necessary and sufficient. What I do not think is necessary is strong collision resistance, but as far as I know it comes for free with all sensible hash functions. I'd have thought truncated SHA-256 would be a sensible choice. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 5 Nov 2004 14:35:10 -0500 (EST) Lines: 22 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 20:44:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluzn1we2it.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If I remember correctly, RFC 2538 uses the same IANA name space as the > rest of DNSSEC for the key algorithms. Perhaps someone is using ECC > for X.509 or OpenPGP data. So a specification for ECC, and an entry > in the IANA DNSKEY key algorithm registry, seem useful. I'm surprised that no one caught this when we were bickering over the RFC3755 IANA registry format. I don't have any problems with CERT reusing the registry, but as you're working on 2538bis, you might want to check the IANA considerations section in 3755 and the registry itself to see if any changes are needed. 2538bis might want to cite 3755, too. In any case, I think it would be good to add a note in the registry mentioning that CERT uses these numbers, also: http://www.iana.org/assignments/dns-sec-alg-numbers -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 23:47:55 +0100 Lines: 57 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> <iluactwhcpz.fsf@latte.josefsson.org> <1B7D12F383042E33099EA626@[192.168.0.4]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Nov 05 23:57:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 50 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Sz63UeSwHycK6N5JE8yixaE0xwA= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> writes: >>> Depends which hash property you are talking about. What you don't >>> want is inversion (i.e. you know H(x), can you discover x?). It >>> requires some cryptographically strong properties to prevent this >>> (or rather make the problem computationally infeasible). >> >> Ah, right. This should be mentioned as the primary requirement on the >> chosen hash. >> >> CRC-128 is fully invertible for input strings < 16 bytes, because of >> the linearity. However, if we assume the salt is 16 bytes (as in >> NSEC2), or longer, it is no longer possible to invert it. > > I am not a cryptographer, but many functions that munge things together > losely called hash functions are not invertible for some values, > and are trivially invertible for others. CRC-128 being an example > if what you've said are correct. Hash functions may be overkill, > but at least they provably do the job. Of course. My goal with introducing CRC-128 is to make it a vehicle for discussing exactly what properties are required of the hash function. I'm not seriously proposing to use CRC-128, but thought it might be a useful function for discussion, since it is one of the simplest and most well known function that behave like a hash function but is not cryptographically strong. If we only use (presumed) good functions like SHA-1 in discussion and examples, intuition about that specific function might fool you wrt to which properties are required, and which attacks are possible if some properties do not hold. > I mean if you have Y=H(x) to a small set of possibles x1, x2, ... > for which H(x(n))=Y (i.e. they all have the same hash value), then > you can reasonably trivially eliminate most of the set by looking > at characteristics. Yes, I understand it now. You don't even have to rely on characteristics, you can ask DNS directly, if the set x_i is not too large. But being able to compute the set x_i is not a well-known hash property. Preimage resistance is the property of computing one _single_ element of that set. And as Ben said, if the hash function is designed so that the set x1, x2, ... that can be feasible computed include all candidates _except_ the real existing name, then the hash function would still be usable for the hashed-NSEC idea, but would not have the preimage resistance property. So preimage resistance is not sufficient. Preimage resistance may be necessary, but that is not obvious to me at this point. Thanks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 05 Nov 2004 23:59:52 +0100 Lines: 48 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Nov 06 00:07:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 41 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:WziShMJn1fJUO35TB6wkdHPdrTw= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler <weiler@tislabs.com> writes: >> If I remember correctly, RFC 2538 uses the same IANA name space as the >> rest of DNSSEC for the key algorithms. Perhaps someone is using ECC >> for X.509 or OpenPGP data. So a specification for ECC, and an entry >> in the IANA DNSKEY key algorithm registry, seem useful. > > I'm surprised that no one caught this when we were bickering over the > RFC3755 IANA registry format. I don't have any problems with CERT > reusing the registry, but as you're working on 2538bis, you might want > to check the IANA considerations section in 3755 and the registry > itself to see if any changes are needed. It seems one new column, to specify applicability for CERT records would have to be added. I can add this as a IANA consideration of 2538bis. One could argue that this new IANA consideration in RFC 2538bis would make it incompatible with RFC 2538, thus preventing it from progressing to DRAFT STANDARD. On the other hand, the incompatibility is due to the changes introduced by RFC 3755, not the original specification nor the original DNSSEC specification. I would appreciate input on this issue, from people more familiar with procedural issues. > 2538bis might want to cite 3755, too. Won't DNSSECbis obsolete 3755? I'd rather reference DNSSECbis. > In any case, I think it would be good to add a note in the registry > mentioning that CERT uses these numbers, also: > > http://www.iana.org/assignments/dns-sec-alg-numbers I agree. How can we make that happen? Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Denial Of Existence: Way Forward Date: Fri, 05 Nov 2004 09:12:10 -0500 Lines: 27 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Laurie <ben@algroup.co.uk>, Samuel Weiler <weiler@tislabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Nov 06 01:49:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en To: Roy Arends <roy@dnss.ec> In-Reply-To: <Pine.BSO.4.56.0411041629470.9716@trinitario.schlyter.se> X-OriginalArrivalTime: 06 Nov 2004 00:38:24.0881 (UTC) FILETIME=[ECD16E10:01C4C398] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >In San Diego, I was talking about salting requirements, Ben was talking >about multiple salt possibilities, hence the confusion between us at the >time. We agreed that multiple salts are possible, as long as the >salting requirement (every name MUST be salted with each salt) was >satisfied. > >Therefor, the relevant section in the DNSNR draft needs to be updated, >since I did not anticipate having multiple salts. > >Multiple salts are no problem, as long as every name is salted with each >salt. For every salt there will exist an NSEC-chain. > > I am lost, can you provide a summary of the arguments that lead to this conclussion? --Olaf namedropper -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Date: Sat, 06 Nov 2004 14:37:04 +0000 Lines: 42 References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> <Pine.GSO.4.55.0410291610461.25617@filbert> <418905A2.1050107@algroup.co.uk> <Pine.GSO.4.55.0411032227130.622@filbert> <418A3EC7.4050302@algroup.co.uk> <iluactxy4uo.fsf@latte.josefsson.org> <A558EB4247020EDB1980A8FB@[192.168.100.25]> <iluactwhcpz.fsf@latte.josefsson.org> <1B7D12F383042E33099EA626@[192.168.0.4]> <ilu7jozewv8.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Nov 06 15:49:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <ilu7jozewv8.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 05 November 2004 23:47 +0100 Simon Josefsson <jas@extundo.com> wrote: > Yes, I understand it now. You don't even have to rely on > characteristics, you can ask DNS directly, if the set x_i is not too > large. The point is that elimination by property occupies a few CPU cycles, DNS involves several milliseconds. For a leaf label of length 8 octets, there are 256^8 possible values, of which only 63^8 are fall within the regexp (yes I know it's less than that if you don't have '-' at start and end, and far fewer if DNS records are stored in consistent case). That in effect reduces the time taken to find which of the set corresponds by a factor of 75,000. Let's call it 10^6 for simplicity. So if your set was of size (say) 10^12, without sifting, you'd have to make 10^12 DNS queries, which at (say) 1ms each, running 1000 in parallel, would, take 10^6 seconds or 11 days per name. However, with sifting, you instead take 1/75000th that time as you need to make far fewer queries - 13 seconds per name - 2 years to enumerate co.uk without spreading the load between machines. > But being able to compute the set x_i is not a well-known hash > property. Preimage resistance is the property of computing one > _single_ element of that set. First preimage resistance is the property of finding ANY single element of the set, not the entire set. That is true and I'd missed that. However, you don't need to find the entire set to have a good stab at enumerability. However, clearly if first preimage resistance is a sufficient (but not necessary) property for the "set" preimage resistance you describe; see other message for why I think you need second preimage resistance anyway. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: James Snell <jasnell@gmail.com> Subject: XML Resource Record [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Mon, 8 Nov 2004 08:46:36 -0500 Lines: 125 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> <20041103150449.2285e598.olaf@ripe.net> Reply-To: James Snell <jasnell@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 08 14:59:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GJUzTJwaJ1ZsOb+cLrmHaIGHL9E8Fn7hYWUlgdmpyDKEvdudlFo3TcapYbvAunInK65muHDkS1cQzZjdeSAxKi1Kbpvm724O1ZMTzocwGaOHtAx+CJWVUl2sCzK8kmyf4875ftZhcxNnMFQ+pjh0Z4hEaen5vdbtorFF3PSGgLw= To: "Olaf M. Kolkman" <olaf@ripe.net> In-Reply-To: <20041103150449.2285e598.olaf@ripe.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Regarding the XML Resource Record that we have included in this spec, I too have my reservations about it. Yes, as currently defined it does suffer from a lot of the same ambiguity problems as the TXT record with the one exception that the XML data is at least self describing. The reasons for having the XML RR in the first place are fairly simple: 1. Many very important Web service descriptors are going to be in various XML formats (WS-Policy, WS-Addressing, etc), some of which will be digitally signed. The goal is to allow clients to query for this information in one location, preferrably with the XML in tact. Redirection is possible, but we'd rather avoid redirecting for everything. The EPR record will be adequate for the majority of cases, but we need to be able to support the edge cases as well. 2. The XML descriptors are continuing to evolve and more may emerge over time. This is an area that is much more fluid and dynamic than what DNS typically handles therefore it is important to have a record type that is some what malleable to avoid having to change an RR or come up with a new one every time a new WS spec comes out. That said, however, there are definitely some things we can do to limit the scope of the record, thereby reducing the potential for abuse: First, we can limit the use of the XML record strictly to Web service related information. Initially this limit would cover things like WS-Policy and WS-Addressing. Second, we can limit the amount of data that goes into the record. Regarding the encoding field in the XML RR, thanks for the tip. I was unclear as to what extent DNS implementations were allowed to muck around with things based on the content of the RDATA. Changing the various MUSTs to SHOULDs should not be a problem. On Wed, 3 Nov 2004 15:04:49 +0100, Olaf M. Kolkman <olaf@ripe.net> wrote: > > > Hello James and Andrew, > > I have been reading your draft. Having very little experience with the > web-services architecture there are a few things that I cannot get my > finger behind. > > The first question I have is on EPR. It is triggered by having > possible redirection ( WDSL URL or an XML RR), why not simply always > redirect to a WSDL document describing the service? It may make life > much easier if the web service descriptions are dynamic in nature. You > will not need to bother with caching and other DNS data propagation > effects such as secondary DNS servers not updating in time. > > I do not feel comfortable with the XML RR. It has more or less the > same properties as the TXT RR. It has no limitations and may cause > people to put all kinds of things in the XML RR, such as > internet-draft XML source (interesting idea :-) ). > > If there is a possibility for redirection I do not understand why the > XML RR would be needed, what is the perceived benefit? > > I also have a more detailed questions and remarks about the RRs. > > 1. I think that some of the EPR RDATA elements can be split into > their functional parts. For instance the PortType QNAME (confusing > name for a data element in the context of DNS :-) ) could be > encoded as: > > |length|namespace-uri|length|localpart > > 2. It is not clear to me why the separator "_ws" is needed in the > proposed owner names of EPR records {name}._ws.{domain}. Both > client and server will know which part of the name is intended to > be the domain part and which part will be the name part. > > Dropping _ws could introduce an ambiguity (If there exists both a > "inquire.uddi" and a "inquire" service and the "inquire.uddi" > service has been implemented for the "example.com" domain and the > "inquire" service has been implemented for the "uddi.example.com" > domain.) But that ambiguity one could solve by adding a simple > counter in the RDATA that tells us at which label the split between > name and domain occurs. The DNSSIG RR uses a similar mechanism to > indicate to indicate which part of a domain name has been > synthesized. > > 3. Section 2.3.1. > > "DNS implementations MUST send the XML data using the encoding > specified by the encoding byte flag". > > DNS implementations will send binary RDATA, they will never look at > the content of the RDATA before putting information on the > wire. The encoding flag can only be used as an indicator to the > client interpreting the RDATA on what the binary RDATA is > representing. > > Most of the MUSTs in this paragraphs are not enforcable and > probably should be SHOULDs. (most of them relate to language that > enforces implementers to strip the XML cruft before putting it into the > RDATA). > > 4. Editing nit: most of your example RRs span multiple lines, you > should use brackets to indicate this > > mystock._ws.example.com XML 0 <EndpointReference ( > xmlns="..." > .... > </EndpointReference> ) > > Olaf Kolkman > > namedropper (no hats) > -- - James Snell IBM, Emerging Technologies jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Samuel Weiler <weiler@tislabs.com> Subject: online signing draft Date: Mon, 8 Nov 2004 18:28:08 -0500 (EST) Lines: 281 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Nov 09 00:48:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments invited. -- Sam Internet-Draft S. Weiler SPARTA, Inc. J. Ihren Autonomica 30 October 2004 Minimally Covering NSEC Records and DNSSEC On-line Signing draft-weiler-dnsext-dnssec-online-signing-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on 30 April 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by [-records]. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. Introduction and Terminology With DNSSEC [-records], an NSEC record lists the next instantiated name in its zone, proving that no names exist in the "span" between the NSEC's owner name and the name in the "next name" field. In this document, an NSEC record is said to "cover" the names between its owner name and next name. Through repeated queries that return NSEC records, it is possible to retrieve all of the names in the zone, a process commonly called "walking" the zone. Some zones have policies forbidding zone transfers by arbitrary clients; this side-effect of the NSEC architecture subverts those policies. This document presents a way to prevent zone walking by constructing NSEC records that cover fewer names. These records can make zone walking take approximately as many queries as simply asking for all possible names in a zone, making zone walking impractical. Some of these records must be created and signed on demand, which requires on-line private keys. Anyone contemplating use of this technique is strongly encouraged to review the discussion of the risks of on-line signing in section [Security Considerations]. The technique presented here may be useful to a zone that wants to use DNSSEC, is concerned about exposure of its zone contents via zone walking, and is willing to bear the costs of on-line signing. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119]. Minimally Covering NSEC Records This mechanism involves both changes to NSEC records for instantiated names, which can still be generated and signed in advance, as well as the on-demand generation and signing of new NSEC records whenever a name must be proven not to exist. In the 'next name' field of instantiated names' NSEC records, rather than list the next instantiated name in the zone, list any name that falls lexically after the NSEC's owner name and before the next instantiated name in the zone, according to the ordering function in [-records] section 6.2. These NSEC records are returned whenever proving something specifically about the owner name (e.g. that no resource records of a given type appear at that name). Whenever an NSEC record is needed to prove the non-existence of a name, a new NSEC record is produced and signed. The new NSEC record has an owner name lexically before the QNAME but lexically following any existing name and a "next name" lexically following the QNAME but before any existing name. The functions to generate the lexically following and proceeding names need not be perfect nor consistent, but the generated NSEC records must not cover any existing names. Furthermore, this technique works better when the generated NSEC records cover very little of the zone's namespace. For example, a query for the non-instantiated name example.com might produce the following NSEC record: exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) Before answering a query with this record, an authoritative server must test for the existence of names between these endpoints. If the generated NSEC would cover existing names (e.g. exampldd.com), a better increment or decrement function may be used or the covered name closest to the QNAME could be used as the NSEC owner name or next name, as appropriate. If an existing name is used as the NSEC owner name, that name's real NSEC record MUST be returned. Using the same example, assuming an exampldd.com delegation exists, this record might be returned from the parent: exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) Like every authoritative record in the zone, each generated NSEC record MUST have corresponding RRSIGs generated using each algorithm (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as described in [-protocol] section 2.2. To minimize the number of signatures that must be generated, a zone may wish to limit the number of algorithms in its DNSKEY RRset. Better Increment & Decrement Functions Section 6.2 of [-records] defines a strict ordering of DNS names. Working backwards from that definition, it should be possible to define increment and decrement functions that generate the immediately following and preceeding names, respectively. This document does not define such functions. Instead, this section presents functions that come reasonably close to the perfect ones. As described above, an authoritative server MUST ensure than no generated NSEC covers any existing name. To increment a name, add a leading label with a single null octet. To decrement a name, decrement the last character of the leftmost label, then fill that label to a length of 63 octets with octets of value 255. To decrement a null octet, remove the octet -- if an empty label is left, remove the label. Defining this function numerically: fill the left-most label to its maximum length with zeros (numeric, not ASCII zeros) and subtract one. In response to a query for the non-existent name foo.example.com, these functions produce an NSEC record of: fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) Both of these functions are imperfect: they don't take into account constraints on number of labels in a name nor total length of a name. IANA Considerations This document has no IANA Actions. Security Considerations This approach requires on demand generation of RRSIG records. This creates several new vulnerabilities. First, on demand signing requires that a zone's authoritative servers have access to its private keys. Storing private keys on well-known internet-accessible servers may make them more vulnerable to unintended disclosure. Second, since generation of public key signatures tends to be computationally demanding, the requirement for on demand signing makes authoritative servers vulnerable to a denial of service attack. Lastly, if the increment and decrement functions are predictable, on-demand signing may enable a chosen-plaintext attack on a zone's private keys. Zones using this approach should attempt to use cryptographic algorithms that are resistant to chosen-plaintext attacks. It's worth noting that while DNSSEC has a "mandatory to implement" algorithm, that is a requirement on resolvers and validators -- there is no requirement that a zone be signed with any given algorithm. If any "mandatory to implement" algorithm is found to be particularly vulnerable to chosen plaintext attack, a zone may which to switch to another algorithm or use less predictable increment and decrement function. The success of using minimally covering NSEC record to prevent zone walking depends greatly on the quality of the increment and decrement functions chosen. An increment function that chooses a name obviously derived from the next instantiated name may be easily reverse engineered, destroying the value of this technique. An increment function that always returns a name close to the next instantiated name is likewise a poor choice. A good choice of increment and decrement functions are the ones that produce the immediately following and preceeding names, respectively, though zone administrators may wish to use less perfect functions that return more human-friendly names than the functions described in section X above. Another obvious but misguided concern is the danger from synthesized NSEC records being replayed. It's possible for an attacker to replay an old but still validly signed NSEC record after a new name has been added in the span covered by that NSEC, incorrectly proving that there is no record at that name. This danger exists with DNSSEC as defined in [-bis]. The techniques described here actually decrease the danger, since the span covered by any NSEC record is smaller than before. Choosing better increment and decrement functions will further reduce this danger. Normative References (out of date versions) [I-D.ietf-dnsext-dnssec-intro] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 2004. [I-D.ietf-dnsext-dnssec-records] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-records-08 (work in progress), May 2004. [I-D.ietf-dnsext-dnssec-protocol] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in progress), May 2004. Acknowledgements Many individuals contributed to this design. They include, in addition to the authors of this document, Olaf Kolkman, Ed Lewis, Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, Jakob Schlyter, Bill Manning, and Joao Damas. Authors' Addresses Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 USA EMail: weiler@tislabs.com Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm, Sweden Mail: johani@autonomica.se -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: online signing draft Date: Tue, 09 Nov 2004 16:02:41 +0000 Lines: 15 References: <Pine.GSO.4.55.0411081817130.15465@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 09 17:17:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (X11/20041031) X-Accept-Language: en-us, en To: Samuel Weiler <weiler@tislabs.com> In-Reply-To: <Pine.GSO.4.55.0411081817130.15465@filbert> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > Better Increment & Decrement Functions Geoff and I have been working on a rigorous definition of these, which I hope he'll post later today. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: dee3@pothole.com Subject: Re: draft-ietf-dnsext-ecc-key-05.txt Date: Tue, 9 Nov 2004 17:53:44 -0500 (EST) Lines: 147 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert> <ilu3bznewbb.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Nov 10 00:08:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: dee3@localhost.localdomain To: namedroppers@ops.ietf.org In-Reply-To: <ilu3bznewbb.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Nov 2004, Samuel Weiler wrote: > Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST) > From: Samuel Weiler <weiler@tislabs.com> > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > On Tue, 12 Oct 2004 dee3@pothole.com wrote: > >> Please post any comments on these two drafts. I gave brief presentations >> on them at the last IETF and plan to do so again next month. If there are >> no substantial comments, I will ask that they be working group Last Called >> right after the upcoming meeting. > > I've only read parts of draft-ietf-dnsext-ecc-key-05. Here are some > comments on the bits I have read: > > This document needs to take into account the type code roll (RFC3755). > Examples: Section 1 refers to SIG, which has been largely, but not > entirely, deprecated. Section 2 says "key RRs", then cites > DNSSECbis-records. See RFC3755 IANA considerations, section 4.2. Be > much more explicit about which of DNSKEY and/or KEY you mean here. You are right. My only excuse, not very good, is that this draft has been around for many years in one form or another. It is meant to define algorithm code point 4 which has always been reserved for ECC. As originally posted, it also defined a signature format usable in RRSIG and SIG. There was lots of resistence due to fears of inability to handle a zone signed with more than one algorithm, and the like. So, quite some time ago, the draft was admitted as a WG draft only on condition that the signature date format be stripped out of it. I think that's silly and the signature format section should be reinserted. > Section 2, second paragraph: "with signatures..." is confusing. Just > say RRSIGs. Also: "key validity may not be in the RR with the > key...". First, just say KEY or DNSKEY. Also: I see no key validity > field in this RR -- why have the equivolcal phrasing with a "may"? I'd be happy to work on modernizing the wording. > IANA section: > > Should comment on whether any algorithm numbers need to be assigned > (and, if not, where they are assigned). See 3755 section 4.2. As I say, it is intended to be 4. > It looks like a new registry is being established. This text is > likely insufficient for that task. See > draft-narten-iana-considerations-rfc2434bis-01.txt Another case where I can bring the document up to the more recent standards. > Nits: > > Section 5 (Performance Considerations), second paragraph, third line: > s/ and and/, and/ > > Status of this memo: "This draft is intended to be become a Proposed > Standard RFC." is not allowed, per > http://www.ietf.org/ietf/1id-guidelines.txt I would agree that it would be better to remove this and the guidelines specifically prohibit certainly words, that imply status, from being in the title of an ID. But I don't actually see where the guidelines prohibit this sentence. Could you point it out to me? > Boilerplate looks incomplete (Acceptance of section 3 of 3667 is > missing). As above. On Thu, 4 Nov 2004, Samuel Weiler wrote: > Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST) > From: Samuel Weiler <weiler@tislabs.com> > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > On Thu, 4 Nov 2004, Samuel Weiler wrote: > >> Be much more explicit about which of DNSKEY and/or KEY ... > > Further comments after some more reflection. > > First, I'd like to thank Donald for his efforts to put this document > (and the HMAC SHA TSIG doc) together. There are very few people with > both the ability to follow the current crypto research and the > willingness to bring that knowledge back to the IETF in a useful form. > We should applaud Donald for his willingness to do that. > > I'd also like to say that I'm not particularly averse to storing > random data in the DNS. It certainly isn't particularly intended to be random data. It's original intent wass to provide ECC as another interoperable way to sign zones and store ECC keys for use by other protocols. > That said, it's not clear to me why we're trying to store ECC keys in > the DNS nor, given that uncertainty, what RR type we might want to use > to store them. Of late, we've been choosing to separate data into new > type codes based on the use of the data, not the content or format of > the data. For cryptographic keys, in particular, we've tried to reuse > key storage formats (we reused the 2536 and 3110 formats in DNSKEY and > IPSECKEY), but we've allocated new RR types for different data users. > See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt > section 2.6 (now at RFC-Editor). > > Since we're not defining a SIG nor RRSIG format for ECC, it would > appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG) > nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and > RFC3755. Who are they useful for? (Does anyone really want to store > ECC keys in the DNS?) And what does that suggest about what RR > type(s) they should be stored in? This all feeds into the IANA > section questions I posted earlier today. I removed the signature format, which was present in earlier versions, because that was made a condition by the chairs for consideration by the WG. I think it should be added back. The ECC / Algorithm 4 should, in my opinion, be allowed as widely as RSA, although of course it should only be a MAY for implementation. The compactness of ECC keys and signatures is particularly attractive for DNS and a code point was reserved for ECC from the beginning. > Looking further ahead, I also wonder if this record format's > flexibility might be dangerous. Can we imagine users of data that > can't effectively use all of the different types of eliptic curve keys > that can be stored in this RR? If so, we may be creating another > subtyping problem. This is a reasonable topic for discussion. > -- Sam Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: dee3@pothole.com Subject: RFC2538bis Re: draft-ietf-dnsext-ecc-key-05.txt Date: Tue, 9 Nov 2004 18:06:49 -0500 (EST) Lines: 74 References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> <Pine.GSO.4.55.0411041546200.16737@filbert> <Pine.GSO.4.55.0411042242340.27766@filbert> <iluzn1we2it.fsf@latte.josefsson.org> <Pine.GSO.4.55.0411051429350.8454@filbert> <ilu3bznewbb.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Nov 10 00:15:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: dee3@localhost.localdomain To: namedroppers@ops.ietf.org In-Reply-To: <ilu3bznewbb.fsf@latte.josefsson.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Nov 2004, Simon Josefsson wrote: > Date: Fri, 05 Nov 2004 23:59:52 +0100 > From: Simon Josefsson <jas@extundo.com> > Subject: Re: draft-ietf-dnsext-ecc-key-05.txt > > Samuel Weiler <weiler@tislabs.com> writes: > >>> If I remember correctly, RFC 2538 uses the same IANA name space as the >>> rest of DNSSEC for the key algorithms. Perhaps someone is using ECC >>> for X.509 or OpenPGP data. So a specification for ECC, and an entry >>> in the IANA DNSKEY key algorithm registry, seem useful. It's almost the same. RFC 2538 specifically allows zero for unknown cases. >> I'm surprised that no one caught this when we were bickering over the >> RFC3755 IANA registry format. I don't have any problems with CERT >> reusing the registry, but as you're working on 2538bis, you might want >> to check the IANA considerations section in 3755 and the registry >> itself to see if any changes are needed. I think it is a lot easier to have one registry. > It seems one new column, to specify applicability for CERT records > would have to be added. I can add this as a IANA consideration of > 2538bis. > > One could argue that this new IANA consideration in RFC 2538bis would > make it incompatible with RFC 2538, thus preventing it from > progressing to DRAFT STANDARD. This sort of thing is one reason why algorithms and their implementation requirements are increasingly being split out into separate documents. That way, if a protocol is reasonably algorithm independent, it can continue to advance along the standards track even if advances in cryptography requires the corresponding "crypto suites" document to keep changing. > On the other hand, the incompatibility is due to the changes > introduced by RFC 3755, not the original specification nor the > original DNSSEC specification. > > I would appreciate input on this issue, from people more familiar with > procedural issues. > >> 2538bis might want to cite 3755, too. > > Won't DNSSECbis obsolete 3755? I'd rather reference DNSSECbis. Yes, it does obsolete 3755. >> In any case, I think it would be good to add a note in the registry >> mentioning that CERT uses these numbers, also: >> >> http://www.iana.org/assignments/dns-sec-alg-numbers > > I agree. How can we make that happen? > > Thanks, > Simon Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Document advancement DNSEXT: Case Insensitive Date: Wed, 10 Nov 2004 11:04:00 -0500 Lines: 100 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: namedroppers@ops.ietf.org, Margaret Wasserman <margaret@thingmagic.com>, ogud@ogud.com, "Olaf M. Kolkman" <olaf@ripe.net>, iesg-secretary@ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 10 17:14:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: Thomas Narten <narten@us.ibm.com> X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thomas, Please advance Case Insensitive clarification on the standards track: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-04.txt. 1. Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes, we have read this document and it has been reviewed and revised. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, key members of DNSEXT a have read this document. As this document was created to address a narrow non-controversial issue that was from identified during the review of RFC3597, this issue has clear base and purpose. 3. Do you have concerns that the document needs more review from a particular (broader) perspective? In theory this document should be reviewed by people that are experts in non English languages as it border line touches on how these are represented in DNS. But as IDN has addressed that there is no further review needed. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? The only concern with the document, is that the educational/background sections may draw more interest and discussion than the actual DNS Protocol content of the document. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group consensus is solid. The WG has only raised issues with the semantics and structure of the document not content. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No 7. Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). The document adheres to most of the ID nits with the exception that some of the IPR statements required by RFC3668 are non compliant. There are no IPR issues possible with this document. We request that the editor fix the IPR statement at the same time as he addresses any nits brought up during AD review. 8. Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? References are split, and all normative references are RFCs. 9. For Standards Track and BCP documents, the IESG approval announcement includes a write up section with the following sections: Technical Summary: RFC1034/5 was written when US-ASCII was the only language used on on the Internet. For this reason some corner cases related to case folding where not thought out. This document nails down these corner cases. The action of the document is to explicitly say only case folding only applies to letters in the A-Z range. This is the only guaranteed 100% inter operable solution. Working Group Summary The document being advanced has been reviewed, it is non-controversial and will not change any implementations or practices. Protocol Quality: This is quality document. The protocol change is minimal. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: online signing draft Date: Thu, 11 Nov 2004 09:54:03 +0000 (GMT) Lines: 22 References: <4190EA21.8010205@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 11:07:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <4190EA21.8010205@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> wrote: > Samuel Weiler wrote: > > > Better Increment & Decrement Functions > > Geoff and I have been working on a rigorous definition of these, which I > hope he'll post later today. Now available at: http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-00.txt Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:10 2006 From: Simon Josefsson <jas@extundo.com> Subject: On dynamic NSEC Date: Thu, 11 Nov 2004 13:04:26 +0100 Lines: 52 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 13:13:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 45 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:7i4epkPKNXHMCFAu2EaTULZy/z0= Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > [13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it > on the fly. minimally cover. idea has been posted to ML. not in > archive. use NSEC mechanism, good things, can use current resolvers > to validate. would mean can deploy DNSSECbis without enumeration > properties, if can implement this in server.... ... > [13:07:54] <ggm> Proposed way forward: fast-track epsilon in this > group, review, try to see if will work, publish asap. so that things > can be deployed today. in same time, continue on other solutions, > without makeing choices. There seem to be some assumption that online signing of dynamically generated NSEC with "epsilon" domains coexist with DNSECbis. I'd like to remind people about section 2.3 of protocol-09: Each owner name in the zone which has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. ... An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner names nodes which were not the owner name of any RRset before the zone was signed. This text imply to me that you cannot invent new owner names for NSEC. I believe the above MUST's are not required for interoperability nor are they necessary for successful operation of DNSECbis. It seems the text may cause problems, if dynamic signing of NSEC with epsilon domain names is used together with DNSECbis. I raised this problem, in the context of lying NSEC, during the DNSECbis last call. It was apparently ignored. http://article.gmane.org/gmane.ietf.dnsext/5339 I maintain that the MUST cannot in general be verified by clients, and hence should not be part of the specification. Further I believe that the text prevent deployment of NSEC alternatives. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 13:10:45 +0000 Lines: 24 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 14:21:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 13:04 +0100 Simon Josefsson <jas@extundo.com> wrote: > I maintain that the MUST cannot in general be verified by clients, and > hence should not be part of the specification. Further I believe that > the text prevent deployment of NSEC alternatives. Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't be fiddling with DNSSEC-bis now (not sure we even can). Both epsilon-based dynamic signing, and hashed NSEC'-based mechanisms will require an alteration to/addition to DNSSEC-bis, and will need to make their own (separate) way down the standards track. The former alteration is clearly smaller, and hence progress should be quicker (though I suspect due to key exposure and other factors, its audience may be more limited). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 09:16:42 -0500 Lines: 33 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ed.lewis@neustar.biz X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 15:26:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:10 -0500 11/11/04, Alex Bligh wrote: >Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't >be fiddling with DNSSEC-bis now (not sure we even can). I'd put it this way - we shouldn't be fiddling with the DOCUMENTS that are in production. But don't let DOCUMENTS get in the way of RUNNING CODE. Proposed Standard status recognizes that there may need to be adjustments to the text to describe reality. I said in another group "it's never too late to comment on the protocol, but it's too late to comment on the document" in the context of a document that we had handed to the IESG. Simon is right about the passage. Alex is half right that fiddling with DNSSECbis - we ought not fiddle with docs so implementers and operators can get to work. But never let the bureaucracy of what's been written get in the way of real technical progress. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar I would have been at the meeting, but I was busy raking the leaves from the (now) empty non-terminals in my yard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 14:31:03 +0000 Lines: 60 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 15:43:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (X11/20041031) X-Accept-Language: en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-OriginalArrivalTime: 11 Nov 2004 14:33:05.0428 (UTC) FILETIME=[5B373540:01C4C7FB] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > > >>[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it >>on the fly. minimally cover. idea has been posted to ML. not in >>archive. use NSEC mechanism, good things, can use current resolvers >>to validate. would mean can deploy DNSSECbis without enumeration >>properties, if can implement this in server.... > > ... > >>[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this >>group, review, try to see if will work, publish asap. so that things >>can be deployed today. in same time, continue on other solutions, >>without makeing choices. > > > There seem to be some assumption that online signing of dynamically > generated NSEC with "epsilon" domains coexist with DNSECbis. > > I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. > ... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. > > This text imply to me that you cannot invent new owner names for NSEC. > > I believe the above MUST's are not required for interoperability nor > are they necessary for successful operation of DNSECbis. > > It seems the text may cause problems, if dynamic signing of NSEC with > epsilon domain names is used together with DNSECbis. > > I raised this problem, in the context of lying NSEC, during the > DNSECbis last call. It was apparently ignored. > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > I maintain that the MUST cannot in general be verified by clients, and > hence should not be part of the specification. Further I believe that > the text prevent deployment of NSEC alternatives. This is a known issue. In order to deploy NSEC+epsilon, we have to change the text. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 09:47:03 -0500 Lines: 42 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 15:56:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: namedroppers@ops.ietf.org In-Reply-To: <a06110402bdb92386847d@[10.20.30.22]> References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:16 11/11/2004, Edward Lewis wrote: >At 8:10 -0500 11/11/04, Alex Bligh wrote: >>Agree; DNSSEC-bis prohibits epsilon based dynamic signing, and we shouldn't >>be fiddling with DNSSEC-bis now (not sure we even can). > >I'd put it this way - we shouldn't be fiddling with the DOCUMENTS that are >in production. > >But don't let DOCUMENTS get in the way of RUNNING CODE. Proposed Standard >status recognizes that there may need to be adjustments to the text to >describe reality. > >I said in another group "it's never too late to comment on the protocol, >but it's too late to comment on the document" in the context of a document >that we had handed to the IESG. > >Simon is right about the passage. Alex is half right that fiddling with >DNSSECbis - we ought not fiddle with docs so implementers and operators >can get to work. But never let the bureaucracy of what's been written get >in the way of real technical progress. To amplify what Ed said, at this point we do not know the FULL extent of the changes needed to the DNSSECbis documents, when we know that we will issue an update to DNSSECbis documents. We also do not know at this time for sure that anyone will deploy the +/-epsilon changes, there might be engineering reasons not to do that in which case the updating the protocol is a mute point. Please start the discussion on what +/- epsilon will be like, once the WG understands and has consensus on the modified protocol, the appropriate changes to protocol described in DNSSECbis will be made. Olafur Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 15:53:12 +0100 (CET) Lines: 63 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <419377A7.3000906@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:01:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <419377A7.3000906@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Nov 2004, Ben Laurie wrote: > Simon Josefsson wrote: > > Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > > > > > >>[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it > >>on the fly. minimally cover. idea has been posted to ML. not in > >>archive. use NSEC mechanism, good things, can use current resolvers > >>to validate. would mean can deploy DNSSECbis without enumeration > >>properties, if can implement this in server.... > > > > ... > > > >>[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this > >>group, review, try to see if will work, publish asap. so that things > >>can be deployed today. in same time, continue on other solutions, > >>without makeing choices. > > > > > > There seem to be some assumption that online signing of dynamically > > generated NSEC with "epsilon" domains coexist with DNSECbis. > > > > I'd like to remind people about section 2.3 of protocol-09: > > > > Each owner name in the zone which has authoritative data or a > > delegation point NS RRset MUST have an NSEC resource record. > > ... > > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > > RRset at any particular owner name. That is, the signing process > > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > > not the owner name of any RRset before the zone was signed. > > > > This text imply to me that you cannot invent new owner names for NSEC. > > > > I believe the above MUST's are not required for interoperability nor > > are they necessary for successful operation of DNSECbis. > > > > It seems the text may cause problems, if dynamic signing of NSEC with > > epsilon domain names is used together with DNSECbis. > > > > I raised this problem, in the context of lying NSEC, during the > > DNSECbis last call. It was apparently ignored. > > > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > > > I maintain that the MUST cannot in general be verified by clients, and > > hence should not be part of the specification. Further I believe that > > the text prevent deployment of NSEC alternatives. > > This is a known issue. In order to deploy NSEC+epsilon, we have to > change the text. IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion path until DNSSEC-ter. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 15:11:20 +0000 Lines: 35 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> <6.1.2.0.2.20041111093020.049cbec0@localhost> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:18:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org In-Reply-To: <6.1.2.0.2.20041111093020.049cbec0@localhost> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 09:47 -0500 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 <ogud@ogud.com> wrote: > To amplify what Ed said, at this point we do not know the FULL extent > of the changes needed to the DNSSECbis documents, when we know that we > will issue an update to DNSSECbis documents. [***] > We also do not know at this time for sure that anyone will deploy > the +/-epsilon changes, there might be engineering reasons not to do that > in which case the updating the protocol is a mute point. Sorry to be an aspiring documentation-lawyer, but I presume what you mean is that (a) we should be developing a draft documentation which, if things run to completition will form a stand-alone set of documents which can be read as as update for the existing DNSSECbis protocol (i.e. that the two instances of the word "documentats" above should be "protocol"); and not (b) that we are going to be doing work now which will result is us asking the IESG to change the DNSSECbis documents themselves prior to further advance down the standards track. I would be worried if you did in fact mean (b) as I thought the entire purpose of sending DNSSECbis off to the IESG although quite a few people think it is far from perfect was so that further development would NOT disrupt code development deployment. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 02:14:39 +1100 Lines: 35 References: <Pine.BSO.4.56.0411111552060.749@trinitario.schlyter.se> Cc: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:21:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Arends <roy@dnss.ec> In-reply-to: Your message of "Thu, 11 Nov 2004 15:53:12 BST." <Pine.BSO.4.56.0411111552060.749@trinitario.schlyter.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > I raised this problem, in the context of lying NSEC, during the > > > DNSECbis last call. It was apparently ignored. > > > > > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > > > > > I maintain that the MUST cannot in general be verified by clients, and > > > hence should not be part of the specification. Further I believe that > > > the text prevent deployment of NSEC alternatives. > > > > This is a known issue. In order to deploy NSEC+epsilon, we have to > > change the text. > > IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion > path until DNSSEC-ter. Maybe temporary. Once implemented there is less pressure to implement other online signing solutions. To get rid of enumeneration in deep zones online signing appears to be the only solution. Once there is a online signing solution it is unlikely that a second solution will be implemented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Roy Arends <roy@dnss.ec> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 16:42:47 +0100 (CET) Lines: 56 References: <200411111514.iABFEdvi052278@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Ben Laurie <ben@algroup.co.uk>, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 16:50:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: roy@trinitario.schlyter.se To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200411111514.iABFEdvi052278@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 12 Nov 2004, Mark Andrews wrote: > > > > > I raised this problem, in the context of lying NSEC, during the > > > > DNSECbis last call. It was apparently ignored. > > > > > > > > http://article.gmane.org/gmane.ietf.dnsext/5339 > > > > > > > > I maintain that the MUST cannot in general be verified by clients, and > > > > hence should not be part of the specification. Further I believe that > > > > the text prevent deployment of NSEC alternatives. > > > > > > This is a known issue. In order to deploy NSEC+epsilon, we have to > > > change the text. > > > > IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion > > path until DNSSEC-ter. > > Maybe temporary. Once implemented there is less pressure > to implement other online signing solutions. Yes. So we can focus on nsec++. Online signing is not really optimal for high load servers. > To get rid > of enumeneration in deep zones online signing appears to > be the only solution. Not really. This can be solved using CNAME for these extremely long names. If you're referring to wildcards, I see the problem. Wildcard proofs using NSEC++ may have multiple NSEC++'s in contrast with current NSEC where there is a maximum of two. > Once there is a online signing solution it is unlikely that > a second solution will be implemented. No worries. Online signing is not an optimal solution. NSEC++ is not an optimal solution as well. We might need both. I do think that the larger TLD's might have a problem with dynamic signing, due to several critical deployment issues, like an online key, high response cost due to the crypto, key management between the authoritative servers. Typically, these larger TLD's do not have zones with very long, multiple labels. In general TLD's have just single label deep delegations, so the wildcard problem of > 2 NSEC++ does not apply. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 15:32:23 +0000 Lines: 43 References: <200411111514.iABFEdvi052278@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roy Arends <roy@dnss.ec>, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 17:07:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.8 (X11/20041031) X-Accept-Language: en-us, en To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200411111514.iABFEdvi052278@drugs.dv.isc.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-OriginalArrivalTime: 11 Nov 2004 16:00:31.0748 (UTC) FILETIME=[92441C40:01C4C807] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Andrews wrote: >>>>I raised this problem, in the context of lying NSEC, during the >>>>DNSECbis last call. It was apparently ignored. >>>> >>>>http://article.gmane.org/gmane.ietf.dnsext/5339 >>>> >>>>I maintain that the MUST cannot in general be verified by clients, and >>>>hence should not be part of the specification. Further I believe that >>>>the text prevent deployment of NSEC alternatives. >>> >>>This is a known issue. In order to deploy NSEC+epsilon, we have to >>>change the text. >> >>IMHO, this is a non-issue. It is a NSEC+epsilon is a temporary transistion >>path until DNSSEC-ter. > > > Maybe temporary. Once implemented there is less pressure > to implement other online signing solutions. To get rid > of enumeneration in deep zones online signing appears to > be the only solution. As I pointed out yesterday, deep zones are only an issue with hashed NSEC if you consider the hashes to be names. Clearly this is the simplest solution, but, equally clearly, it is not the only one. > Once there is a online signing solution it is unlikely that > a second solution will be implemented. Given that there are several TLDs (and probably others) that won't deploy online keys, nor NSEC, I think you're wrong. But there's little point debating it. It'll either happen, or it won't. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Rob Austein <sra@isc.org> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 11:09:54 -0500 Lines: 22 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 17:16:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 11 Nov 2004 13:04:26 +0100, Simon Josefsson wrote: > ... > I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. > ... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. > > This text imply to me that you cannot invent new owner names for NSEC. Um, no, at worst it means that when you synthesize an NSEC RR you also have to synthesize something else, eg, a NULL RR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 16:56:49 +0000 Lines: 39 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <20041111160955.764677C@thangorodrim.hactrn.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 18:05:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org In-Reply-To: <20041111160955.764677C@thangorodrim.hactrn.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 11:09 -0500 Rob Austein <sra@isc.org> wrote: >> This text imply to me that you cannot invent new owner names for NSEC. > > Um, no, at worst it means that when you synthesize an NSEC RR you also > have to synthesize something else, eg, a NULL RR. Nope don't think so - that changes wildcard behaviour. I think that's even trivially exploitable, EG $ORIGIN example.com foo IN MX mail-1.evilempire.com * IN MX mail-2.goodempire.com Two users (Evil Ed, and User Ursula), share the same caching resolver. Ursula wants to send mail to bill@fred.example.com Ed works out P(fred.example.com), S(fred.example.com), and queries for them and for fred.example.com. example.com's nameserver returns an NSEC record that mentions fred.example.com, and by your assumption synthesizes not only the NSEC record but also a NULL RR, for fred.example.com. The NULL RR is then cached by the caching nameserver. This means Ursula's mail will NOT go to mail-2.goodempire.com, it will either bounce (as an MX lookup will yield the NULL record), or possibly go to the mail-1.evilempire.com. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 19:03:35 +0000 Lines: 19 References: <DF9CAF5F337FBE901E49884A@[192.168.100.25]> <a06110402bdb92386847d@[10.20.30.22]> <6.1.2.0.2.20041111093020.049cbec0@localhost> <53726696A246CF93D3E31D55@[192.168.100.25]> <6.1.2.0.2.20041111105323.04b0a070@localhost> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 20:17:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org In-Reply-To: <6.1.2.0.2.20041111105323.04b0a070@localhost> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 13:55 -0500 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 <ogud@ogud.com> wrote: > DNSSECbis documents are set in stone. > > The WG can issue NEW documents that clearly, coherently and safely > specify changes in DNSSECbis protocol. Thanks :-) (& I agree). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Rob Austein <sra@isc.org> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 14:29:04 -0500 Lines: 52 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <20041111160955.764677C@thangorodrim.hactrn.net> <D0D2E3869BCF337EB20008BB@192.168.100.25> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 20:39:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <D0D2E3869BCF337EB20008BB@[192.168.100.25]> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 11 Nov 2004 16:56:49 +0000, Alex Bligh wrote: > > >> This text imply to me that you cannot invent new owner names for NSEC. > > > > Um, no, at worst it means that when you synthesize an NSEC RR you also > > have to synthesize something else, eg, a NULL RR. > > Nope don't think so - that changes wildcard behaviour. In what way does the existance of a synthetic NULL RRset change the wildcard behavior compared to the behavior if only the synthetic NSEC were present? At least one of us is confused. > > I think that's even trivially exploitable, EG > > $ORIGIN example.com > > foo IN MX mail-1.evilempire.com > * IN MX mail-2.goodempire.com > > Two users (Evil Ed, and User Ursula), share the same caching resolver. > > Ursula wants to send mail to bill@fred.example.com > > Ed works out P(fred.example.com), S(fred.example.com), and queries for them Queries with what QTYPE? > and for fred.example.com. example.com's nameserver returns an NSEC record > that mentions fred.example.com, and by your assumption synthesizes not > only the NSEC record but also a NULL RR, for fred.example.com. The NULL > RR is then cached by the caching nameserver. Given suitable definitions of the P() and S() functions and a suitable choice of RR type (something that is very unlikely to occur in normal use, eg, NULL), the name server in the above scenario has several hints that something evil is going on, and might choose to return RCODE 5 (refused) rather than participating in the attack. :) If for some reason it seems reasonable to return a synthetic NULL RR in such a case (unlikely) it should probably have a TTL of zero. In practice, the only real difference between this and the epsilon solution as already described is that the bit corresponding to the NULL RR type would be turned on in the NSEC bitvector. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 20:47:44 +0000 Lines: 119 References: <iluy8h8h9rp.fsf@latte.josefsson.org> <20041111160955.764677C@thangorodrim.hactrn.net> <D0D2E3869BCF337EB20008BB@192.168.100.25> <20041111192906.B53125A@thangorodrim.hactrn.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 21:58:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org In-Reply-To: <20041111192906.B53125A@thangorodrim.hactrn.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 14:29 -0500 Rob Austein <sra@isc.org> wrote: > At Thu, 11 Nov 2004 16:56:49 +0000, Alex Bligh wrote: >> >> >> This text imply to me that you cannot invent new owner names for NSEC. >> > >> > Um, no, at worst it means that when you synthesize an NSEC RR you also >> > have to synthesize something else, eg, a NULL RR. >> >> Nope don't think so - that changes wildcard behaviour. > > In what way does the existance of a synthetic NULL RRset change the > wildcard behavior compared to the behavior if only the synthetic NSEC > were present? At least one of us is confused. Yes. I am assuming that the reason for the assumption Simon Josefsson mentioned: under section 2.3 of protocol-09: Each owner name in the zone which has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. ... An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner names nodes which were not the owner name of any RRset before the zone was signed. is that NOT doing so would require a change to wildcard behaviour, and thus that in order to support epsilon NSECs, wildcard behaviour would be changed so presence of an NSEC record "only" would not "count" for the purposes of determining whether a wild-card was applicable. If this is the case (i.e. if the appropriate change is made to the wildcard treatment algorithm), then the restrictions in 2.3 can be lifted. However, if NO change to the wildcard processing stuff is made, then as you point out they are equivalent, and (as far as I can see) NSEC epsilons break wildcards. I seem to remember greater minds than mine pointed this out at the time when we were considering NSEC 'white lies' which is why the requirement in section 2.3 never got removed at the time (because we didn't want to fiddle with wildcard processing at that late stage). The reason for the breakage is quite simple: Under NSEC epsilon, every label must have an associated record returned on a query - either it "really" exists (in which case by definition there is a record), or it "really" does not (in which case by assumption - NSEC epilson) there is an epsilon record pointing to the records successor. Under such circumstances, the wildcard record is never the closest encloser of anything (as the closest encloser is either an epsilon NSEC or a real record). So I'd been working under the assumption the wildcard lookup would be changed to exclude NSEC only labels (hence NULL and NSEC aren't equivalent). If my assumption is wrong, then you are indeed right, NULL and NSEC *will* break wildcards - in exactly the same way, and, AFAICT, completely. But I may have missed something here. >> I think that's even trivially exploitable, EG >> >> $ORIGIN example.com >> >> foo IN MX mail-1.evilempire.com >> * IN MX mail-2.goodempire.com >> >> Two users (Evil Ed, and User Ursula), share the same caching resolver. >> >> Ursula wants to send mail to bill@fred.example.com >> >> Ed works out P(fred.example.com), S(fred.example.com), and queries for >> them > > Queries with what QTYPE? Not sure it particularly matters, but let's say ANY. >> and for fred.example.com. example.com's nameserver returns an NSEC record >> that mentions fred.example.com, and by your assumption synthesizes not >> only the NSEC record but also a NULL RR, for fred.example.com. The NULL >> RR is then cached by the caching nameserver. > > Given suitable definitions of the P() and S() functions and a suitable > choice of RR type (something that is very unlikely to occur in normal > use, eg, NULL), the name server in the above scenario has several > hints that something evil is going on, and might choose to return > RCODE 5 (refused) rather than participating in the attack. :) How does that work algorithmically? I can only see heuristic solutions to this, and it's a reasonable attack vector as far as I can see, with potentially disastrous results. If you are trying to change the use of NULL above in wildcard processing, you might as well just change the wording and the wildcard algorithm for NSEC instead and drop 2.3. NULL is actually USEFUL to indicate an exception to a wildcard, as someone (Ed Lewis I think) pointed out to me here not so long ago. > If for some reason it seems reasonable to return a synthetic NULL RR > in such a case (unlikely) it should probably have a TTL of zero. > > In practice, the only real difference between this and the epsilon > solution as already described is that the bit corresponding to the > NULL RR type would be turned on in the NSEC bitvector. Why not just except NSECs from the wildcard algorithm, and drop the text in 2.3? That's useful for both NSEC epsilon and NSEC' hashes. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 22:19:13 +0000 Lines: 55 References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Thu Nov 11 23:29:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Thu, 11 Nov 2004 13:04:26 +0100." <iluy8h8h9rp.fsf@latte.josefsson.org> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson <jas@extundo.com> wrote: > I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. > ... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. ... > I maintain that the MUST cannot in general be verified by clients, and > hence should not be part of the specification. Further I believe that > the text prevent deployment of NSEC alternatives. i agree with the first part of this. the specification should include no server constraints beyond those that will be invisible to clients. i do not agree with the second part of this. nsec alternatives will be developed, and they might take advantage of errors in the original specs (like proscriptions against server side activities which weren't distinguishable by clients). in other words, this is a loophole, let's drive a truck through it. Alex Bligh <alex@alex.org.uk> wrote: > So I'd been working under the assumption the wildcard lookup would > be changed to exclude NSEC only labels (hence NULL and NSEC aren't > equivalent). If my assumption is wrong, then you are indeed right, > NULL and NSEC *will* break wildcards - in exactly the same way, > and, AFAICT, completely. > > But I may have missed something here. i think you missed two things. first, see above. in this case the loophole created by the dnssec-bis spec error (that of outlawing something in the server that will not affect the client or be distinguishable to the client) allows you to simply say, in a later spec, that a server who "violates" this provision of dnssec-bis by creating on-the-fly NSECs for with epsilon names at nodes with no real (unsynthesized) rrsets, must treat the zone as having no rrsets at these synthetic names, for all purposes related to wildcards. second, your argument pertains to a zone signer, which changes zone content. in the case of an on-the-fly signer, which does not change zone content, it is very possible to get exactly the treatment we'll probably want, without invalidating any conforming clients of the dnssec-bis protocol. (i wish i wasn't such an expert at exploting loopholes in specifications...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Thu, 11 Nov 2004 23:19:43 +0000 Lines: 40 References: <20041111221913.26B5E13E69@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 00:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041111221913.26B5E13E69@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 11 November 2004 22:19 +0000 Paul Vixie <paul@vix.com> wrote: > second, your argument pertains to a zone signer, which changes zone > content. in the case of an on-the-fly signer, which does not change zone > content, it is very possible to get exactly the treatment we'll probably > want, without invalidating any conforming clients of the dnssec-bis > protocol. Assuming we cache NSEC records, which is presumably desirable, what prevents a caching resolver relying on a cached NSEC to fail to match an otherwise closest enclosing wildcard? IE how the wildcard spec is written at the moment, if a resolving client sees foo IN NSEC bar in example.com, it should not match a query for QNAME=foo.example.com., QTYPE=MX against * IN NSEC baz Right? In which case, if bar=S(foo) and foo does not exist in the unsynthesized zone, the above is easy enough for a miscreant to put in the nameserver yes? I agree if there is a hole in the original spec (i.e. the original spec is too prescriptive) we can drive a truck through it, but I thought the original prescription that NSEC records only exist where other non-NSEC labels exist was there for a well-defined reason (so not to break wildcards) - IE I don't think this /is/ a hole. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 01:00:47 +0000 Lines: 33 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 02:10:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Thu, 11 Nov 2004 23:19:43 GMT." <82B8F39F152DE9ED339E597A@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... your argument pertains to a zone signer, which changes zone > > content. in the case of an on-the-fly signer, which does not change > > zone content, it is very possible to get exactly the treatment we'll > > probably want, without invalidating any conforming clients of the > > dnssec-bis protocol. > > Assuming we cache NSEC records, which is presumably desirable, what > prevents a caching resolver relying on a cached NSEC to fail to match > an otherwise closest enclosing wildcard? caches don't match wildcards. only an authority server can do that. otherwise a server who had cached "*.dom" and "foo.dom" might decide that a query for "bar.dom" matched the while card, even if in the authority server, "bar.dom" actually exists. (not that a synthetic rr would have a nonzero ttl in the first place.) > I agree if there is a hole in the original spec (i.e. the original > spec is too prescriptive) we can drive a truck through it, but I thought > the original prescription that NSEC records only exist where other > non-NSEC labels exist was there for a well-defined reason (so not to > break wildcards) - IE I don't think this /is/ a hole. nope. it was an oversight. at least two editors admitted this to me in person when i said "hey wait, we can't ship this to the iesg without relaxing the parts that proscribe synthetic epsilon-named nsec rr's" but the second of the two was able to explain how, actually, we could and must. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 17:10:10 +0000 Lines: 53 References: <20041112010047.B87EA13E26@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 18:23:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041112010047.B87EA13E26@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 12 November 2004 01:00 +0000 Paul Vixie <paul@vix.com> wrote: > caches don't match wildcards. only an authority server can do that. > otherwise a server who had cached "*.dom" and "foo.dom" might decide > that a query for "bar.dom" matched the while card, even if in the > authority server, "bar.dom" actually exists. > > (not that a synthetic rr would have a nonzero ttl in the first place.) OK. Let me simplify a bit, drop the caching nameservers, and at the risk of looking stupid: Take a zone example.com: * IN MX foo bar IN MX baz dummy IN NULL dummy2 IN TXT "fred" It uses NSEC epsilon. That means for every possible label, there is a synthetic NSEC record, and per Rob's proposal, also a synthetic NULL record. Synthetic I am taking to mean "not in the original zone loaded into the nameserver, but created algorithmically so it appears under all other circumstances to be in the zone" I then make the following queries: 1. type=NSEC, label=xxx.example.com 2. type=MX, label=xxx.example.com 3. type=ANY, label=xxx.example.com 4. type=MX, label=dummy.example.com 5. type=MX, label=dummy2.example.com What do I get? Surely type 1 HAS to return (at least) xxx IN NSEC S(xxx) or the whole epsilon NSEC stuff doesn't work Surely (2) is indistinguishable from (4) if there is a NULL record synthesized? Surely (2) is indistinguishable from (4) and (5) unless NSECs are processed differently from NULL's in the wildcard algorithm? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Fri, 12 Nov 2004 17:34:37 +0000 Lines: 64 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri Nov 12 18:43:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Fri, 12 Nov 2004 17:10:10 GMT." <66805DF7731B03771BE327B8@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... > > (not that a synthetic rr would have a nonzero ttl in the first place.) > > OK. Let me simplify a bit, drop the caching nameservers: > > Take a zone example.com: > * MX foo > bar MX baz > dummy NULL > dummy2 TXT "fred" > > It uses NSEC epsilon. That means for every possible label, there is a > synthetic NSEC record, and per Rob's proposal, also a synthetic NULL > record. Synthetic I am taking to mean "not in the original zone > loaded into the nameserver, but created algorithmically so it appears > under all other circumstances to be in the zone" with the proviso that i didn't understand the need for a NULL RR, i'm tracking you so far. > I then make the following queries: > 1. type=NSEC, label=xxx.example.com > 2. type=MX, label=xxx.example.com > 3. type=ANY, label=xxx.example.com > 4. type=MX, label=dummy.example.com > 5. type=MX, label=dummy2.example.com > > What do I get? > > Surely type 1 HAS to return (at least) > xxx IN NSEC S(xxx) > or the whole epsilon NSEC stuff doesn't work given that there is a wildcard, there will be no NXDOMAINs for this zone. therefore every NSEC will have a real owner name. so, i'm with you so far. each of queries (1), (2), and (3) will produce the same NSEC result, but with different RRtypes claimed at the ownername. which is another very fine reason why client-side negative caching based on previously cached NSEC RRs won't work, and thus i renew my claim that wildcarding should be done on the client side rather than the server side. (but that's a different windmill.) > Surely (2) is indistinguishable from (4) if there is a NULL record > synthesized? i don't know why you'd ever synthesize a NULL RR. i don't like NULL RRs at all, but in your example you made the NULL RR a real RR, not a synthetic one. therefore query (4) would get a NOERROR/NODATA reply and the wildcard would not be part of the choice of what to return -- because the qname actually does exist. > Surely (2) is indistinguishable from (4) and (5) unless NSECs are > processed differently from NULL's in the wildcard algorithm? response to (5) would be NOERROR/NODATA as with (4). i appear to be lost. can we have this discussion over again, except this time can you do it without the synthetic NULL RRs, and can you explain the non-dnssec parts of each reply so i'll know what covering dnssec metadata will be applied? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Sat, 13 Nov 2004 15:16:18 +0000 Lines: 89 References: <20041112173437.0BB4813E64@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Nov 13 16:29:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041112173437.0BB4813E64@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul, >> OK. Let me simplify a bit, drop the caching nameservers: >> >> Take a zone example.com: >> * MX 10 foo >> bar MX 10 baz >> dummy NULL >> dummy2 TXT "fred" >> www IN A 1.1.1.1 >> zzz IN A 2.2.2.2 >> >> It uses NSEC epsilon. That means for every possible label, there is a >> synthetic NSEC record, and per Rob's proposal, also a synthetic NULL >> record. Synthetic I am taking to mean "not in the original zone >> loaded into the nameserver, but created algorithmically so it appears >> under all other circumstances to be in the zone" > > with the proviso that i didn't understand the need for a NULL RR, i'm > tracking you so far. OK, Rob Austein suggested synthesizing a NULL RR to avoid changing the requirements of 2.3 - I was pointing out that didn't help. So let us assume for the minute *NO* NULL RR's are synthesized (i.e. it operates in breach of 2.3 but we hope this doesn't cause any harm). >> I then make the following queries: >> 1. type=NSEC, label=xxx.example.com >> 2. type=MX, label=xxx.example.com >> 3. type=ANY, label=xxx.example.com >> 4. type=MX, label=dummy.example.com >> 5. type=MX, label=dummy2.example.com >> >> What do I get? >> >> Surely type 1 HAS to return (at least) >> xxx IN NSEC S(xxx) >> or the whole epsilon NSEC stuff doesn't work > > given that there is a wildcard, there will be no NXDOMAINs for this zone. > therefore every NSEC will have a real owner name. so, i'm with you so > far. ... > response to (5) would be NOERROR/NODATA as with (4). i appear to be lost. > can we have this discussion over again, except this time can you do it > without the synthetic NULL RRs, and can you explain the non-dnssec parts > of each reply so i'll know what covering dnssec metadata will be applied? OK, so I think what should happen WITHOUT epsilon signing - i.e. if normal NSEC records are put in (note I've stuck a couple more records in to make it obvious) is something like: 1. My mind is fried and I know can't work out what that returns but it's not relevant for the point 2. xxx IN MX foo 3. xxx IN MX foo 4. NOERROR/NODATA 5. NOERROR/NODATA With epsilon signing, there is an NSEC record for every possible label query (either synthesized or not). So, queries (2), and (3) should hit a zone with RR's against the label "xxx", something like xxx NSEC S(xxx) but no RR of type MX. Therefore, *if the current DNSSEC-bis lookup algorithm is followed*, the presence of an RR of any type (even NSEC) will result in that RR being the closest encloser for xxx, and (2) should thus return NOERROR/NODATA as the closest encloser has no RR of type MX. This thus breaks wildcard MX (and as far as I can tell this was the reason for 2.3). The solution of course is for the server NOT to count NSEC records (or at least synthetic NSEC records) as closest enclosers. If no NSEC records are considered closest enclosers (at least for QTYPES other than NSEC), then 2.3 can be dropped in its entirety as far as I can see, and this also helps with some of the arguments against hashed NSEC' sharing the same namespace and interfering with wildcards. Perhaps I'm making some mistake here. My point to Rob was that adding NULL RR's to give technical conformance of synthentic NSEC's to 2.3 does not help as they equally break wildcards and cannot be excepted in the same manner from closest encloser rules (i.e. it makes things worse). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Sat, 13 Nov 2004 20:43:51 +0000 Lines: 45 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat Nov 13 21:57:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sat, 13 Nov 2004 15:16:18 GMT." <96FDE9312D5CDA02D5DB2D65@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > With epsilon signing, there is an NSEC record for every possible label > query (either synthesized or not). no, it matters whether it's synthesized or not. if there's a real nsec rr then it would have an impact on the wildcard search algorythm. a synthetic nsec rr, being made from whole cloth, can be defined as having no impact on the wildcard search algorythm. this is possible only because the synthesis and the wildcard search are both done in the authority server. > ... The solution of course is for the server NOT to count NSEC records > (or at least synthetic NSEC records) as closest enclosers. yes. > If no NSEC records are considered closest enclosers (at least for > QTYPES other than NSEC), then 2.3 can be dropped in its entirety as > far as I can see, and this also helps with some of the arguments > against hashed NSEC' sharing the same namespace and interfering with > wildcards. not unless the hashed nsec's were synthetic. we REALLY needed slabs before security, to keep all the security metadata completely out of the dns world view. if you want to define NSEC2/NSEC3/whatever as having no effect on the wildcard search algorythm, you'll have to do so explicitly, and carefully. > Perhaps I'm making some mistake here. your thinking on this topic is very creative. i'm only able to fault you on matters of terminology and for occasionally forgetting which constraints will be in effect under which circumstances. please do continue. > My point to Rob was that adding NULL RR's to give technical > conformance of synthentic NSEC's to 2.3 does not help as they equally > break wildcards and cannot be excepted in the same manner from closest > encloser rules (i.e. it makes things worse). i don't think rob intended his offhand mention of NULL RRs to be given as much scrutiny as you have done. if it's not a helpful approach, abandon it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Niall O'Reilly <niall.oreilly@ucd.ie> Subject: Re: online signing draft Date: Sat, 13 Nov 2004 21:42:31 +0000 Lines: 56 References: <4190EA21.8010205@algroup.co.uk> <20041111095403.8ED62E7E50@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Niall O'Reilly <niall.oreilly@ucd.ie> X-From: owner-namedroppers@ops.ietf.org Sat Nov 13 22:50:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-reply-to: <20041111095403.8ED62E7E50@mx1.nominet.org.uk> To: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.619) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 11 Nov 2004, at 09:54, Geoffrey Sisson wrote: > Now available at: > > http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-00.txt IMO, a refinement to the notation " non-printable octet values are expressed as three-digit octal numbers preceded by a backslash " allowing a decimal repeat count in parens between the backslash and the first of the three octal digits would immensely enhance readability. As a consequence, any unwittingly-introduced errors would be more easily noticed. For example, in the first example in section 5.1, x' = \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377.\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377.\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377.fon\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ \377\377\377\377\377\377\377\377\377\377\377\377\377\377.exa\ mple.com. could then be represented as x' = \(50)377.\(63)377.\(63)377.fon\(60)377.example.com. if I've counted all those octal-encoded octets correctly. Best regards, Niall O'Reilly PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Andras Salamon <andras@dns.net> Subject: Re: online signing draft Date: Sun, 14 Nov 2004 13:32:08 +0200 Lines: 68 References: <Pine.GSO.4.55.0411081817130.15465@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 12:42:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <Pine.GSO.4.55.0411081817130.15465@filbert> User-Agent: Mutt/1.5.6i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Nov 08, 2004 at 06:28:08PM -0500, Samuel Weiler wrote: > Minimally Covering NSEC Records and DNSSEC On-line Signing > draft-weiler-dnsext-dnssec-online-signing-00.txt > > This document presents a way to prevent zone walking by > constructing NSEC records that cover fewer names. These records > can make zone walking take approximately as many queries as simply > asking for all possible names in a zone, making zone walking > impractical. Let n(Z) be the size of zone Z, f(Z) be the number of queries typically generated by a brute force enumeration of zone Z, and k(Z) be the number of enumerations sought each day by people trying to enumerate zone Z, and we have been told previously that k(Z) is likely to be a number in the hundreds (if not more). Usually f(Z) >> n(Z). With online-signing-00, we are then back to O(f(Z)*k(Z)) daily queries being sent to name servers authoritative for zones Z, just like today. However, today without DNSSEC each query costs O(1) time to generate and O(1+log n(Z)) time to answer. With online signing, we still have each query costing time O(1) but answers now costing O(q+1+log n), where q is a constant dependent on the length of the encryption key and the server's crypto hardware accelerator. As far as I can tell, this is at least an order of magnitude more work for the servers, given usual values of the constant q. This breaks requirement 15 (minimisation of asymmetry) in signed-nonexistence-requirements-00. Given requirement 15, shouldn't we also revisit increasing the time on the _query_ side of DNSSEC, so each query takes time O(q) to generate and process? As far as I can see, there will always be asymmetry if one can make a trivial distinction between positive and negative answers. After all, an enumerator isn't interested in verifying signatures on responses. Precomputed NSEC records are a way to keep the server side cost down to O(1), but allow enumeration if there are only O(n(Z)) precomputed records, or otherwise require infeasibly large space, approaching f(Z). In DNSSEC-ter, could we not drop this distinction, and instead always return responses to queries, accompanied by indicator records which have to be decrypted to determine if the response is actually a dummy? These records would indicate whether the response is a dummy, and if not they would serve the same function as NSEC records. A www.example.com? -> www.example.com. A 10.0.0.1 ISEC <encrypted indicator, null> A wwx.example.com? -> wwx.example.com. A 127.0.1.2 ISEC <encrypted indicator, cf. NSEC> However, I don't yet see how in the above scheme responses could be chosen to always be "harmless" without being identifiable by an enumerator as being negative responses (eg. IPv4 addresses in the block 127/8 as above). The other alternative seems to be to find a way to generate and store at least O([n(Z)]^2) precomputed signed NSEC responses. For zones with 1m domain names, this doesn't seem feasible either. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: On dynamic NSEC Date: Sun, 14 Nov 2004 13:07:23 +0000 Lines: 96 References: <20041113204351.9747013E1D@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 14:14:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20041113204351.9747013E1D@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 13 November 2004 20:43 +0000 Paul Vixie <paul@vix.com> wrote: >> With epsilon signing, there is an NSEC record for every possible label >> query (either synthesized or not). > > no, it matters whether it's synthesized or not. if there's a real nsec rr > then it would have an impact on the wildcard search algorythm. a > synthetic nsec rr, being made from whole cloth, can be defined as having > no impact on the wildcard search algorythm. this is possible only > because the synthesis and the wildcard search are both done in the > authority server. [1] > >> ... The solution of course is for the server NOT to count NSEC records >> (or at least synthetic NSEC records) as closest enclosers. > > yes. > >> If no NSEC records are considered closest enclosers (at least for >> QTYPES other than NSEC), then 2.3 can be dropped in its entirety as >> far as I can see, and this also helps with some of the arguments >> against hashed NSEC' sharing the same namespace and interfering with >> wildcards. > > not unless the hashed nsec's were synthetic. OK. I am now going to play your game of driving a truck but this time through a hole you created :-) If you are correct with [1] above, and there is no reason to doubt you, then your assertion works because the epsilon NSECs are created by the authority server according to a specific algorithm. Provided that the algorithm is used, the resolver would have no way of telling whether they are in fact synthetic NSECs, or whether they aren't. So, for example, the zone I create and give to the authority server could have (and I'm assuming S(foo)=foo\000, S(foo\000)=foo\000\000 etc.) * IN MX 2.2.2.2 foo IN A 1.1.1.1 foo IN NSEC foo\000 [A] foo\000 IN NSEC foo\000\000 [B] The authority server would produce synthetic NSECs (for instance foo\000\000 IN NSEC fooo\000\000\000 [C] But I can't see a resolver can tell the difference. That doesn't matter because (as you say) the wildcard search (which is the only thing it matters to we think) is carried out on the authoritative server. Now given these NSEC records have to be signed, there is nothing (it seems to me) to stop us saying hashed NSEC' records are the same. They could all be created on the authoritative server, and all signed on the authoritative server. In that way, the authoritative server can exclude them from the wildcard lookup algorithm. And if that's the case, then you can use the same argument I've used above to say that NSEC' records could IN FACT not be synthesized - they could come from the original zone, and still omitted from the wildcard lookup algorithm - the resolver wouldn't be able to tell the difference. IE, if you can get away with an authoritative server treating synthetic NSEC epsilon records differently in terms of the wildcard lookup algorithm, then as far as I can see, logically the same must be true of non-synthetic NSEC' hash records. In which case we know that removing the requirement in 2.3 and amending the wildcard search algorithm to remove hashed NSEC' records is not going to be problematic. I would add that you might as well remove the requirement for NSEC records (as opposed to hashed NSEC' records) to be treated that way, except that in the above example there is I suppose a theoretical need for a QTYPE=MX query on the zone to produce a different result for QLABEL=foo\000 and QLABEL=foo\000\000 (as only one is synthetic). [Note, side argument: I am not sure that we should not in that case not have put a note to the effect that resolvers should not rely on servers following 2.3: just as we are driving a truck through what we think an open hole in that 2.3 can be violated because the resolvers must fulfil other parts of the specification and not, for instance, do their own local optimizations for wildcard searches by relying on (say) cached records, others writing from the resolver end may conclude that in fact THAT restriction is a whole in the spec THEY can drive a truck through because it doesn't matter if they violate rule (X) because all servers will be following the restrictions in 2.3 so breaking rule X won't damage anything will it? - visions of 2 trucks driving through dark holes and colliding in the middle] Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: online signing draft Date: Sun, 14 Nov 2004 13:32:44 +0000 Lines: 92 References: <Pine.GSO.4.55.0411081817130.15465@filbert> <20041114113208.GA29061@dns.net> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 14:37:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net>, namedroppers@ops.ietf.org In-Reply-To: <20041114113208.GA29061@dns.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 November 2004 13:32 +0200 Andras Salamon <andras@dns.net> wrote: > With online-signing-00, we are then back to O(f(Z)*k(Z)) daily queries > being sent to name servers authoritative for zones Z, just like today. > > However, today without DNSSEC each query costs O(1) time to generate and > O(1+log n(Z)) time to answer. With online signing, we still have each > query costing time O(1) but answers now costing O(q+1+log n), where q is > a constant dependent on the length of the encryption key and the server's > crypto hardware accelerator. Actually a ratio of that constant to the processor time to do a lookup. IE as its O() it depends on the relative speed of lookups to crypto. > As far as I can tell, this is at least > an order of magnitude more work for the servers, given usual values of > the constant q. As you say, depends on q and log n, but yes. > This breaks requirement 15 (minimisation of asymmetry) > in signed-nonexistence-requirements-00. Yes. The other side of the same coin is it is trivial to perform an effective denial of service attack by querying random QNAMEs. Whilst one might chose to drop ones that don't (say) have LNH composition in high load environments, zones are normally sufficiently sparse that it would be possible to generate unique (i.e. uncachable authoritative server side) queries that are distinctly plausible. For instance, 6 letter strings have over 10^10 combinations, and [consonant][vowel][consonant][vowel][consonant][vowel] [consonant][vowel][consonant][vowel][consonant][vowel][consonant] has over 10^13 combinations. Cycling through those from sufficient parallelized zombies will, I would have thought, saturate any crypto processor. Whilst it's possible to start dropping synthetic NSECs (apparently acceptable to some as "authenticated denial is less important" - to them), that's a ridiculous argument as you might as well just go with opt-in if that were the case and drop the crypto processor requirements and script kiddie opportunity. > Given requirement 15, shouldn't we also revisit increasing the time on > the _query_ side of DNSSEC, so each query takes time O(q) to generate > and process? That assume that the solution you want on the resolver side does have an element that takes O(q) time to process! Whilst the latter is possible, I'm not sure it is desirable, not least because of the asymmetry problem. I'm not sure whether you are just suggesting this as a straw man, but saying we'll make all queries more resource intensive, because by only making minimal changes to the protocol we've been left with making some responses more resource intensive, and otherwise there will be asymmetry, to me suggests that we have to look beyond minimal changes to the protocol. > As far as I can see, there will always be asymmetry if one can make a > trivial distinction between positive and negative answers. After all, > an enumerator isn't interested in verifying signatures on responses. > Precomputed NSEC records are a way to keep the server side cost down to > O(1), but allow enumeration if there are only O(n(Z)) precomputed records, > or otherwise require infeasibly large space, approaching f(Z). > > In DNSSEC-ter, could we not drop this distinction, and instead always > return responses to queries, accompanied by indicator records which > have to be decrypted to determine if the response is actually a dummy? > These records would indicate whether the response is a dummy, and if > not they would serve the same function as NSEC records. > > A www.example.com? -> > www.example.com. A 10.0.0.1 > ISEC <encrypted indicator, null> > > A wwx.example.com? -> > wwx.example.com. A 127.0.1.2 > ISEC <encrypted indicator, cf. NSEC> Perhaps I am missing something here, but now rather than do f(Z) cheap queries, does the attacker not instead have to do n(Z) expensive queries? (i.e. he can work his way through the zone by enumeration, but has to decrypt each answer). Assuming the decryption is about as hard as the online signing, and f(Z) >> n(Z) (as you yourself posit), doesn't this make the job rather easier for the attacker? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: online signing draft Date: Sun, 14 Nov 2004 14:41:00 +0000 (GMT) Lines: 34 References: <EBCA3DAB-35BC-11D9-880A-000393B02BAC@ucd.ie> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 15:48:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <EBCA3DAB-35BC-11D9-880A-000393B02BAC@ucd.ie> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Niall O'Reilly <niall.oreilly@ucd.ie> writes: > IMO, a refinement to the notation > > " non-printable octet values are expressed as three-digit octal > numbers preceded by a backslash " > > allowing a decimal repeat count in parens between the backslash and the > first of the three octal digits would immensely enhance readability. . . . > could then be represented as > > x' = \(50)377.\(63)377.\(63)377.fon\(60)377.example.com. I'd considered using something similar to regexp notation to represent the examples, e.g.: x' = \377{50}.\377{63}.\377{63}.fon\377{60}.example.com. . . . but was reluctant to lose the `tangibility' of the unabridged examples. Your suggestion makes me think that the draft probably should have both; I'll change this in -01. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie <paul@vix.com> Subject: Re: On dynamic NSEC Date: Sun, 14 Nov 2004 20:02:36 +0000 Lines: 116 References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun Nov 14 21:14:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sun, 14 Nov 2004 13:07:23 GMT." <1C3176DB8286514F3DFFE7CC@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > no, it matters whether it's synthesized or not. if there's a real nsec rr > > then it would have an impact on the wildcard search algorythm. a > > synthetic nsec rr, being made from whole cloth, can be defined as having > > no impact on the wildcard search algorythm. this is possible only > > because the synthesis and the wildcard search are both done in the > > authority server. [1] > > OK. I am now going to play your game of driving a truck but this time > through a hole you created :-) If you are correct with [1] above, and > there is no reason to doubt you, ... every extension to every protocol relies on creative interpretation of what were previously undefined or illegal symbol patterns. EDNS depends on ADCOUNT>0 in initiatorgrams (queries, updates, etc), which was not a legal pattern in DNS. once you've figured out a way to signal something that will only be visible and valid to participants who understand it, you've got your loophole. everything after that is just whiteboarding. > ... then your assertion works because > the epsilon NSECs are created by the authority server according to > a specific algorithm. Provided that the algorithm is used, the resolver > would have no way of telling whether they are in fact synthetic NSECs, > or whether they aren't. now you're getting into the spirit of this thing. welcome to the dark side. what you have to define is how the authority servers will act. given dns's insane notion of authority-side-synthesis for wildcards, you just have to make sure that the synthesis of wildcards and the sythesis of NSECs are done in a way that queriers see what you want them to see. it will require that all authority servers for a given zone understand the same zone semantics, but DNSSEC-bis also has this requirement, so extending it to cover synthetic NSEC (and later, DNSSEC-ter) is completely reasonable. you may have to add some kind of format versioning, so that old-semantics authority servers will refuse to load and serve new-semantics zones. (we didn't do this in DNSSEC-bis, and a lot of master/slave relationships are going to become stressful as a result.) > So, for example, the zone I create and give to the authority server > could have (and I'm assuming S(foo)=foo\000, S(foo\000)=foo\000\000 etc.) > * IN MX 2.2.2.2 > foo IN A 1.1.1.1 > foo IN NSEC foo\000 [A] > foo\000 IN NSEC foo\000\000 [B] > > The authority server would produce synthetic NSECs (for instance > foo\000\000 IN NSEC fooo\000\000\000 [C] > > But I can't see a resolver can tell the difference. That doesn't matter > because (as you say) the wildcard search (which is the only thing it > matters to we think) is carried out on the authoritative server. yup. being able to take advantage of the authority-side wildcard synthesis insanity is a wonderful benefit after all the pain and cost that's been paid by DNSSEC for said insanity up until now. > Now given these NSEC records have to be signed, there is nothing (it seems > to me) to stop us saying hashed NSEC' records are the same. They could all > be created on the authoritative server, and all signed on the authoritative > server. In that way, the authoritative server can exclude them from the > wildcard lookup algorithm. yes. > And if that's the case, then you can use the same argument I've used above > to say that NSEC' records could IN FACT not be synthesized - they could > come from the original zone, and still omitted from the wildcard lookup > algorithm - the resolver wouldn't be able to tell the difference. yes. > IE, if you can get away with an authoritative server treating synthetic > NSEC epsilon records differently in terms of the wildcard lookup > algorithm, then as far as I can see, logically the same must be > true of non-synthetic NSEC' hash records. yes. > In which case we know that removing the requirement in 2.3 and amending > the wildcard search algorithm to remove hashed NSEC' records is not > going to be problematic. right. > I would add that you might as well remove the requirement for NSEC > records (as opposed to hashed NSEC' records) to be treated that way, > except that in the above example there is I suppose a theoretical need > for a QTYPE=MX query on the zone to produce a different result for > QLABEL=foo\000 and QLABEL=foo\000\000 (as only one is synthetic). also, it's too late. this is one of many ideas that might have improved DNSSEC-bis but would have added more years to its schedule, so while we will miss the functionality, we will not be sorry we shipped without it. > [Note, side argument: I am not sure that we should not in that case not > have put a note to the effect that resolvers should not rely on servers > following 2.3: just as we are driving a truck through what we think > an open hole in that 2.3 can be violated because the resolvers must > fulfil other parts of the specification and not, for instance, do > their own local optimizations for wildcard searches by relying on > (say) cached records, others writing from the resolver end may conclude > that in fact THAT restriction is a whole in the spec THEY can drive > a truck through because it doesn't matter if they violate rule (X) because > all servers will be following the restrictions in 2.3 so breaking > rule X won't damage anything will it? - visions of 2 trucks driving > through dark holes and colliding in the middle] the DNSSEC-bis documents overspecify a number of things, including this, and i expect they will be edited to be more minimal before they can reach the next bus-stop on the standards track. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Andras Salamon <andras@dns.net> Subject: Re: online signing draft Date: Mon, 15 Nov 2004 11:56:48 +0200 Lines: 57 References: <Pine.GSO.4.55.0411081817130.15465@filbert> <20041114113208.GA29061@dns.net> <0DB4EC63628DA3B1286BC1EF@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 11:07:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <0DB4EC63628DA3B1286BC1EF@[192.168.100.25]> User-Agent: Mutt/1.5.6i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Nov 14, 2004 at 01:32:44PM +0000, Alex Bligh wrote: > >Given requirement 15, shouldn't we also revisit increasing the time on > >the _query_ side of DNSSEC, so each query takes time O(q) to generate > >and process? > > That assume that the solution you want on the resolver side does have an > element that takes O(q) time to process! Whilst the latter is possible, I'm > not sure it is desirable, not least because of the asymmetry problem. It seems the way to fix asymmetry is either to reduce the server side time, or to increase the resolver side time: so why is increasing resolver side time not desirable? > I'm > not sure whether you are just suggesting this as a straw man, but saying > we'll make all queries more resource intensive, because by only making > minimal changes to the protocol we've been left with making some responses > more resource intensive, and otherwise there will be asymmetry, to me > suggests that we have to look beyond minimal changes to the protocol. I'm struggling to follow your reasoning here. I was trying to look at _how_ the resolver side could be made to incur O(q) time, without mandating major changes to resolvers which are uninterested in the additional DNSSEC information. Overall, I am tending toward your conclusion that major protocol changes may be required if asymmetry is to be avoided. The one solution I put forward relies on returning RRs for non-existent domain names, which seems to lead to unsafe values being returned, or otherwise allows trivial recognition. The other solution would require a very large number of precomputed signed negative answers. There may be other, smarter ways of going forward. Any further ideas for solving the asymmetry problem, or for rigorously showing it can't be solved while keeping backward compatibility? > >In DNSSEC-ter, could we not drop this distinction, and instead always > >return responses to queries, accompanied by indicator records which > >have to be decrypted to determine if the response is actually a dummy? > >These records would indicate whether the response is a dummy, and if > >not they would serve the same function as NSEC records. > > Perhaps I am missing something here, but now rather than do f(Z) cheap > queries, does the attacker not instead have to do n(Z) expensive queries? I should have explicitly mentioned that I was thinking of epsilon semantics for NSEC records when I wrote the above, ie. f(Z) expensive queries would be required. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: David Fort <david.fort@irisa.fr> Subject: Re: On dynamic NSEC Date: Mon, 15 Nov 2004 11:13:08 +0100 Lines: 125 References: <iluy8h8h9rp.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050501050400090705040300" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 11:20:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluy8h8h9rp.fsf@latte.josefsson.org> X-Virus-Scanned: by amavisd-new at irisa.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050501050400090705040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Simon Josefsson wrote: >Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>: > > > >>[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it >>on the fly. minimally cover. idea has been posted to ML. not in >>archive. use NSEC mechanism, good things, can use current resolvers >>to validate. would mean can deploy DNSSECbis without enumeration >>properties, if can implement this in server.... >> >> >... > > >>[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this >>group, review, try to see if will work, publish asap. so that things >>can be deployed today. in same time, continue on other solutions, >>without makeing choices. >> >> > >There seem to be some assumption that online signing of dynamically >generated NSEC with "epsilon" domains coexist with DNSECbis. > >I'd like to remind people about section 2.3 of protocol-09: > > Each owner name in the zone which has authoritative data or a > delegation point NS RRset MUST have an NSEC resource record. >... > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. That is, the signing process > MUST NOT create NSEC or RRSIG RRs for owner names nodes which were > not the owner name of any RRset before the zone was signed. > > > [...] Correct me if i'm wrong, but the current NSEC allows to prove that a domain is an Empty Non-Terminal domain. The dynamic NSEC proposed in that draft prevent from doing this. Isn't that a problem ? -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T�l: +33 (0) 2 99 84 71 33 --------------050501050400090705040300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title> Simon Josefsson wrote:

Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>:

[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it
on the fly. minimally cover. idea has been posted to ML. not in
archive. use NSEC mechanism, good things, can use current resolvers
to validate. would mean can deploy DNSSECbis without enumeration
properties, if can implement this in server....

...

[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this
group, review, try to see if will work, publish asap. so that things
can be deployed today. in same time, continue on other solutions,
without makeing choices.


There seem to be some assumption that online signing of dynamically
generated NSEC with "epsilon" domains coexist with DNSECbis.

I'd like to remind people about section 2.3 of protocol-09:

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record.
...
   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRset at any particular owner name.  That is, the signing process
   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
   not the owner name of any RRset before the zone was signed.

[...]
Correct me if i'm wrong, but the current NSEC allows to prove that a domain is an Empty Non-Terminal domain. The dynamic NSEC proposed in that draft prevent from doing this. Isn't that a problem ?

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33

--------------050501050400090705040300-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh Subject: Re: online signing draft Date: Mon, 15 Nov 2004 12:13:24 +0000 Lines: 82 References: <20041114113208.GA29061@dns.net> <0DB4EC63628DA3B1286BC1EF@[192.168.100.25]> <20041115095648.GB32055@dns.net> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 13:22:07 2004 Return-path: To: Andras Salamon , namedroppers@ops.ietf.org In-Reply-To: <20041115095648.GB32055@dns.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andras, > On Sun, Nov 14, 2004 at 01:32:44PM +0000, Alex Bligh wrote: >> > Given requirement 15, shouldn't we also revisit increasing the time on >> > the _query_ side of DNSSEC, so each query takes time O(q) to generate >> > and process? >> >> That assume that the solution you want on the resolver side does have an >> element that takes O(q) time to process! Whilst the latter is possible, >> I'm not sure it is desirable, not least because of the asymmetry problem. > > It seems the way to fix asymmetry is either to reduce the server side > time, or to increase the resolver side time: so why is increasing resolver > side time not desirable? Because reducing asymmetry is not the only objective. Having a protocol that requires minimal CPU both ends would be ideal. (Reductio ad absurdum: make name resolution NP-Complete both ends). >> I'm >> not sure whether you are just suggesting this as a straw man, but saying >> we'll make all queries more resource intensive, because by only making >> minimal changes to the protocol we've been left with making some >> responses more resource intensive, and otherwise there will be >> asymmetry, to me suggests that we have to look beyond minimal changes to >> the protocol. > > I'm struggling to follow your reasoning here. > > I was trying to look at _how_ the resolver side could be made to incur > O(q) time, without mandating major changes to resolvers which are > uninterested in the additional DNSSEC information. May be I misunderstood your changes - I thought you were proposing in essence that resolvers needed to decrypt replies? That's a pretty major change to resolvers isn't it? I guess what I am saying is that IF, in order to support something like NSEC-epsilon, we need to make major changes to the resolvers to prevent asymmetry (which make them slower), THEN we should be questioning whether or not NSEC epsilon is the right solution, because we can, with the same degree or lesser degree of intrusiveness both server side and resolver side, produce a solution that does not have asymmetry properties, and moreover avoids asymmetry by making the server faster rather than the resolver slower. > Any further ideas for solving the asymmetry problem, hashed NSEC' (arguably there is mild asymmetry here in terms of hash lookups, but probably no greater than say UDP checksum on inbound packets - a calculation which an attacker could simplify knowing how his packets change byte by byte). > or for rigorously > showing it can't be solved while keeping backward compatibility? I am thinking about that, but I think proving that in a rigorous sense may be hard. >> > In DNSSEC-ter, could we not drop this distinction, and instead always >> > return responses to queries, accompanied by indicator records which >> > have to be decrypted to determine if the response is actually a dummy? >> > These records would indicate whether the response is a dummy, and if >> > not they would serve the same function as NSEC records. >> >> Perhaps I am missing something here, but now rather than do f(Z) cheap >> queries, does the attacker not instead have to do n(Z) expensive queries? > > I should have explicitly mentioned that I was thinking of epsilon > semantics for NSEC records when I wrote the above, ie. f(Z) expensive > queries would be required. Doh! My bad. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Samuel Weiler Subject: Comments on dnssec-trans-01 Date: Mon, 15 Nov 2004 10:29:39 -0500 (EST) Lines: 37 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 16:41:40 2004 Return-path: X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I apologize for not thoroughly reviewing this doc -- I've only looked at small sections of it. First, as might be guessed from my comments on the dnsop list this morning, I suggest adding a section (2.2.4?) about using a different hash (digest) in the parent DS record. Second, I find the algorithm roll section (2.2.3) unsatisfying. I imagined that algorithm signaling would necessarily happen in a zone's DS record (in its parent), since algorithms can't be removed after that point. The section title and the below line, since they focus on RRSIG, seem misleading: The different interpretation would be signaled by use of different signature algorithms in the RRSIG records covering the NSEC RRs. Section 2.2.3.2 is very confusing, also. The first line talks about treating NSEC RRs as unsigned, when it's the zone that it treated as unsigned (unsecure, in the language of bis), not individual RRsets. This line: Also, all positive signatures (RRSIGs on RRSets other than DS, NSEC) appear insecure/bogus to an old validator. is very confusing for two reasons: first, the RRSIGs should appear as irrelevent, which is closer to unsecure than bogus (insecure and bogus are not the same thing in this context). Second, the parenthetical definition of "positive signatures" doesn't make sense to me: presumably the zone's own DS (in the parent) is signed with a known algorithm (so appears as secure) -- I don't know why DS's in the zone (for children) aren't "positive signatures". -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: James Snell Subject: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Mon, 15 Nov 2004 13:01:11 -0800 Lines: 102 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> <20041103150449.2285e598.olaf@ripe.net> <2bcdc7c404110308136be41e26@mail.gmail.com> Reply-To: James Snell Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 15 22:12:51 2004 Return-path: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eqqleu+daoSTF3/2bE1rGY1fIfgRFdle+FSSi9T+rNY85KMW9HuTc6b2qznGrSdqQpN99LLJ8ptsmpdWwZvuGXg2Mb1C6Qd7MR1OFgSJb71STVOkjkcN4IkCYBZgef1h/hh6Qc3C0NC3kBrDAlQ5KUVL30AvHhsEU0fvU1Cecpo= To: "Olaf M. Kolkman" In-Reply-To: <2bcdc7c404110308136be41e26@mail.gmail.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Coming out of the face-to-face in Washington, the two most significant issues was the current design of DNS-EPD's XML Resource Record and the potential of using NAPTR records as opposed to introducing our own new record types. Regarding the latter, after looking through the NAPTR spec again and going through a number of exercises with it, I'm not convinced that it can do everything that we need without introducing a significant amount of unwarranted complexity. I remain open to being convinced otherwise, but at this point I'd like to rule out use of NAPTR records. Regarding the XML RR, I would like to propose the following updates: 1. Rename the XML RR to EPX or "Endpoint Extension" RR. 2. Redefine EPX in such a way as to allow it to contain one of two types of information... XML or a Redirection 3. Limit EPX to only specific types of Web services related information 4. Move the WSDL Reference currently in our EPD RR to an EPX record The new EPR record format would look like: myservice._ws.example.com EPD FLAGS TARGET PATH QNAME_NSURI QNAME_LOCALPART * FLAGS: a single byte field with two meaningful bits and six reserved ones Bit 0x01: Indicates whether TARGET references an A/AAAA record or SRV record (no change from previous) Bit 0x02: Indicates whether or not EPX records are provided for the record All remaining bits are reserved * TARGET: Unchanged from current spec * PATH: Unchanged from current spec * QNAME_NSURI: In the current spec, a single QNAME field contains both the NSURI and LOCALPART, it is better to split these into separate fields * QNAME_LOCALPART : " The WSDL Reference Bit and WSDL_REFERENCE fieds are dropped from the EPD in the next version. The EPX (formerly XML) RR format would be: myservice._ws.example.com EPX TYPE_FLAG [XML|REDIRECT] * XML: ENCODING_FLAG CONTENT * REDIRECT: URL MEDIA_TYPE DIGEST DIGEST_ALGORITHM The EPX record will contain two types of information depending on the value of the TYPE_FLAG byte field. If the TYPE_FLAG is unset, the record will contain a redirection. If the TYPE_FLAG is set, the record will contain XML data directly. An EPX Redirect contains four fields in addition to the TYPE_FLAG: * URL: The fully qualified URL that should be used to get the data. MUST NOT be an empty string * MEDIA_TYPE: The MIME Media Type of the referenced data (e.g. application/wsdl+xml .... currently doesn't exist but could be defined). MAY be an empty string * DIGEST: A digest of the referenced content. MAY be an empty string * DIGEST_ALGORITHM : A URI identifying the algorithm used to generate the digest. MUST be specified if DIGEST is not an empty string. MUST be an empty string if DIGEST is an empty string An EPX containing XML specifies two fields in addition to the TYPE_FLAG: * ENCODING_FLAG : A single byte value specifying the encoding used for the XML * XML : A well-formed XML document with restrictions, e.g. no processing instructions, no formatting whitespace, etc.. all of the restrictions are discussed in the current spec. An example of each version of EPX: ; This one is a redirect myservice._ws.example.com EPX 0 http://example.com/services/myservice.wsdl application/wsdl+xml 1234567890 http://my.digest.algorithm ; This one contains XML directly. The 0 indicates UTF-8 character encoding myservice._ws.example.com EPX 1 0 ... Now, I know that the RDATA of the EPX record is not enforceable by the DNS infrastructure, so it will be up to the client to validate that the data contained in the RDATA is appropriate according to what is specified by the TYPE_FLAG. Inappropriately formatted EPX records would be discarded and ignored by the client. Thoughts? -- - James Snell IBM, Emerging Technologies jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Miek Gieben Subject: MagicType draft Date: Tue, 16 Nov 2004 10:07:16 +0100 Lines: 289 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 10:20:46 2004 Return-path: To: namedroppers Mail-Followup-To: namedroppers Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, this is the draft explaining the MagicType option we have for the new nsec. Draft is below. DNSEXT R. Gieben Internet-Draft NLnet Labs Expires: May 17, 2005 November 16, 2004 Online Signing of Negative and Wildcard Responses draft-gieben-bert-response-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft contains a number of loose ends and does not include any text on any (known) corner cases. Its primary goal is to document the choices the DNSEXT working group has on the subject of fixing the NSEC enumeration in DNSSEC. If at any point in time the working group feels this idea needs further work, this draft will be updated. DNSSECbis [RFC LIST] allow for zone enumeration by walking NSEC chains. It also has a large impact on the zone size at the initial Gieben Expires May 17, 2005 [Page 1] Internet-Draft BERT Resource Record November 2004 deployment stage. This draft proposes a method to address these issues by the use of online signing of negative and wildcard responses. 1. Method To achieve the goal of online signing we will introduce the Basic Error Response Type (BERT) meta record (type = TBD). We will sign the BERT meta record to indicate the type of negative response and the type(s) covered. The BERT record contains two fields. A Rcode field, 8 bits long. Which can hold two values: "No Error" or "Name Error" [RFC 1034/35]. The second is the type covered field, which is 16 bits. Rcode field: No Error: A No Error rcode indicates that the tuple exists in the DNS but the QTYPE does not. Name Error: A Name Error rcode indicates that the tuple does not exist. Type covered field: This is normally the QTYPE value from the original query but MUST be set to `*` (255) for Name Error response and No Data responses from empty non-terminal nodes. This record is signed with online DNSKEY(s) by the authoritative server for the zone with a TTL derived from the SOA MINIMUM field. The resulting RRSIG is included in the response to the client. Multiple signatures are allowed. Since this method requires online signing there is no longer the need to special case wildcard records. These will now be signed on the fly. This in turn simplifies negative responses, as there is no longer the need to prove that the original QNAME does not exist. 2. DNSKEY Considerations A zone can choose whether to share a common key for online signing or each authoritative server can have its own zone signing key or use a mixture. The key signing key should not be shared amongst the servers. Note: all public keys used to perform online signing MUST be in the DNSKEY RRset. [Loose end] Gieben Expires May 17, 2005 [Page 2] Internet-Draft BERT Resource Record November 2004 3. RRSIG Considerations Signatures generated by this method can be cached by the authoritative server as a aid against DoS attacks or broken clients. [Loose end] 4. Interaction with DNSSECbis To permit this online signing method to interact with DNSSECbis we will take the high bit from the algorithm field of the DS record and use it to indicate whether the child zone is signed with DNSSECbis or this online signing method, 0 indicates DNSSECbis, 1 indicates this method. [Editors Note: Needs more work, Loose End] Islands of trust need to know a priori which DNSSEC method is being used. They can tell this by looking at the ALG field of the DS records. 5. Security Zones signed with this online signing method will appear to be insecure to DNSSECbis servers. The DNSSECbis resolvers will not understand the algorithm. Then there are the usual risks associated with keeping keys online. One of the operational impacts of using online signing is that a primary server feeding a couple of slave servers is less easily setup. Because an administrators is faced with the problem of how to distribute the private keys(s) used to generate the BERT RRs. The DS BERT records can either be generated on the fly or be precomputed. 6. Acknowledgements 7. Loose Ends Some of the loose ends not covered in this draft are, SERVFAIL reponses, DoS attacks on nameservers. Key consideration for slave servers. General key usage issues; how long to use, what length. RRSIG considerations. Empty non terminals. Rcode of the BERT message itself. In which section should these RR be placed. If the working group decides so, these loose ends will be tied up. Gieben Expires May 17, 2005 [Page 3] Internet-Draft BERT Resource Record November 2004 Author's Address Miek Gieben NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands EMail: miek@nlnetlabs.nl URI: http://www.nlnetlabs.nl Gieben Expires May 17, 2005 [Page 4] Internet-Draft BERT Resource Record November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gieben Expires May 17, 2005 [Page 5] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Roy Arends Subject: Re: MagicType draft Date: Tue, 16 Nov 2004 14:51:34 +0100 (CET) Lines: 217 References: <20041116090716.GA21088@atoom.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 15:00:44 2004 Return-path: X-X-Sender: roy@trinitario.schlyter.se To: Miek Gieben In-Reply-To: <20041116090716.GA21088@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 16 Nov 2004, Miek Gieben wrote: > Hello, > > this is the draft explaining the MagicType option we have for > the new nsec. Draft is below. I _love_ the name. I don't like subtyping in DS records, why not a different type altogether. I don't understand the need for 8 bits to distinguish between noerror/no-data and nxdomain. 1035 specifies 4 bits, and 2671 specifies 8 more, so 12 in total. Furthermore, this implies you are able to sign rcodes such as SERVFAIL or NOTAUTH or NOTIMP. What is the purpose of that ? Why not use type=255 (ANY) to claim that no name exist (NXDOMAIN), while any other type denies the type. With that, you don't need a seperate BERT record to deny records. You can just use SIG(qtype,qname,qclass), as I proposed some months ago [see below]. If you really want to distinguish between these and static signatures, use the subtyping hack for the signature algorithm. Roy ---------------------------------- Date: Fri, 18 Jun 2004 12:50:25 +0200 (CEST) From: Roy Arends To: dnssec@cafax.se Subject: continued: rrsig(qtype) Hi, A short write-up for working with dynamically generated RRSIGs, for those who are interested. notes: (1) a signature for a non-existant name is generated as follows: sign(RRSIG_RDATA | QNAME | QCLASS ) where type covered field=ANY (2) a signature for a non-existant type is generated as follows: sign(RRSIG_RDATA | QNAME | QCLASS ) where type covered field=QTYPE (3) a signature for a expanded wildcard is generated as follows: sign(RRSIG_RDATA | RR(1) | RR(2) .. ) where RR(N) is the expanded wildcard. The resolver never has to consider proof of wildcards. Just as with vanilla DNS, a resolver is completely oblivious that this was a dynamically signed synthesised record using wildcard expansion instead of a pre-signed static record. Operational detail: It is recommended to use a unique zone-key per authoritative server. The apex keyset might look as follows: example. IN DNSKEY ksk 000 ; key-signing-key example. DNSKEY zsk 001 ; offline zsk for pre-signing. example. DNSKEY zsk 111 ; online zsk for dyn-signing by ns1.example. example. DNSKEY zsk 222 ; online zsk for dyn-signing by ns2.example. example. DNSKEY zsk 333 ; online zsk for dyn-signing by ns3.example. example. DNSKEY zsk 444 ; online zsk for dyn-signing by ns4.example. example. DNSKEY zsk 555 ; online zsk for dyn-signing by ns5.example. example. RRSIG DNSKEY 000 example. RRSIG DNSKEY 001 example. RRSIG DS 001 ; pregenerated denial for DS@child Responses coming from ns3.example would have dynamically generated RRSIGs by DNSKEY 333, etc. The RRSIGs which are dynamically signed are marked with '!!' for clarity. Note that it is not possible for the resolver/validator to notice the difference between a dynamically signed and a pre-signed RRSIG (which is good). Denial for DS for unsigned delegations and at the apex is pregenerated. In the response types below, only A.2 and A.3 have dynamically generated RRSIG's. A.1 might have one if this is an expanded wildcard. The set below covers the entire spectrum. A.1 Answer A successful query to an authoritative server. No dynamically generated RRSIG in this response type, unless this in an expanded wildcard. In that case the (!!) marked RRSIG record is dynamic. ;; Header: QR AA DO RCODE=0 ;; ;; Question x.w.example. IN MX ;; Answer x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 RRSIG MX .. (!!) ;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS .. ;; Additional xx.example. 3600 IN A xx.example. 3600 RRSIG A .. xx.example. 3600 AAAA .. xx.example. 3600 RRSIG AAAA ns1.example. 3600 IN A .. ns1.example. 3600 RRSIG A .. ns2.example. 3600 IN A .. ns2.example. 3600 RRSIG A .. A.2 Name Error An authoritative name error. The special RRSIG RR proves that the name does not exist. ;; Header: QR AA DO RCODE=3 ;; ;; Question ml.example. IN A ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ... example. 3600 RRSIG SOA ... ml.example. 600 RRSIG ANY ... (!!) ;; Additional ;; (empty) A.3 No Data Error A "NODATA" response. The special RRSIG RR proves that the name exists and that the requested RR type does not. ;; Header: QR AA DO RCODE=0 ;; ;; Question ns1.example. IN MX ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ... example. 3600 RRSIG SOA ... ns1.example. 600 RRSIG MX ... (!!) ;; Additional ;; (empty) A.4.1 Referral to Unsigned Zone Referral to an unsigned zone. The special RRSIG RR proves that no DS RR for this delegation exists in the parent zone. Not that the special RRSIG RR to signal absence of DS is not dynamically generated, hence no dynamic generation of RRSIG ;; Header: QR DO RCODE=0 ;; ;; Question mc.b.example. IN MX ;; Answer ;; (empty) ;; Authority b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns2.b.example. b.example. 3600 RRSIG DS .. ;; Additional ns1.b.example. 3600 IN A ns2.b.example. 3600 IN A A.4.2 Referral to Signed Zone Referral to a signed zone. The DS RR contains the data which the resolver will need to validate the corresponding DNSKEY RR in the child zone's apex. ;; Header: QR DO RCODE=0 ;; ;; Question mc.a.example. IN MX ;; Answer ;; (empty) ;; Authority a.example. 3600 IN NS ns1.a.example. a.example. 3600 IN NS ns2.a.example. a.example. 3600 DS ... a.example. 3600 RRSIG DS ... ;; Additional ns1.a.example. 3600 IN A ns2.a.example. 3600 IN A Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: "John S. Bucy" Subject: SRV resolver API? Date: Mon, 15 Nov 2004 21:35:51 -0500 Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 15:13:07 2004 Return-path: To: namedroppers@ops.ietf.org Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] It seems like the uptake on SRV has been very slow. As an application developer, on more than one occassion now, I've wanted to use SRV and been stymied by the unavailability of resolver implementations. To my knowledge, there are only 2 opensource implementations: RULI and adns which are both GPLed. In any case, there isn't one in libc/libresolv on any Unix platform that I know of. The DnsQuery() API in Windows appears to handle SRV as of Win2K/XP. I'd like to suggest that part of the problem -- at least on the Unix side -- is that there isn't a standardized resolver API for SRV. The IPv6 effort came up with getaddrinfo() and friends in rfc2553; its gone into POSIX as well. Why haven't we standardized a resolver API for SRV? john -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie Subject: Re: SRV resolver API? Date: Tue, 16 Nov 2004 14:43:44 +0000 Lines: 28 References: Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 15:49:55 2004 Return-path: To: "John S. Bucy" In-Reply-To: Message from "John S. Bucy" of "Mon, 15 Nov 2004 21:35:51 EST." <20041116023551.GD19813@tellurium.club.cc.cmu.edu> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It seems like the uptake on SRV has been very slow. As an application > developer, on more than one occassion now, I've wanted to use SRV and > been stymied by the unavailability of resolver implementations. To my > knowledge, there are only 2 opensource implementations: RULI and adns > which are both GPLed. In any case, there isn't one in libc/libresolv > on any Unix platform that I know of. The DnsQuery() API in Windows > appears to handle SRV as of Win2K/XP. bind8/contrib/srv/ contains arnt gulbrandsen's work in this area, which while inadequate as the basis for a POSIX API, is adequate for application work. it's been in bind8/contrib/ since 1998. > I'd like to suggest that part of the problem -- at least on the Unix > side -- is that there isn't a standardized resolver API for SRV. The > IPv6 effort came up with getaddrinfo() and friends in rfc2553; its > gone into POSIX as well. Why haven't we standardized a resolver API > for SRV? more broadly than that, a full dns client-side api is needed. we drafted one a couple of years ago but couldn't find the funding for it. c and c++ programmers should have the same high level access to the dns protocol that perl programmers have (through the excellent Net::DNS module). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Edward Lewis Subject: Re: MagicType draft Date: Tue, 16 Nov 2004 09:52:18 -0500 Lines: 27 References: <20041116090716.GA21088@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 16:01:34 2004 Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <20041116090716.GA21088@atoom.net> To: Miek Gieben X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:07 -0500 11/16/04, Miek Gieben wrote: > Online Signing of Negative and Wildcard Responses > draft-gieben-bert-response-00.txt >4. Interaction with DNSSECbis > > To permit this online signing method to interact with DNSSECbis we > will take the high bit from the algorithm field of the DS record and > use it to indicate whether the child zone is signed with DNSSECbis or > this online signing method, 0 indicates DNSSECbis, 1 indicates this > method. What happens if there is a mix of DNSSECbis and "this method" keys in a DS set? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar I would have been at the meeting, but I was busy raking the leaves from the (now) empty non-terminals in my yard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Miek Gieben Subject: Re: MagicType draft Date: Tue, 16 Nov 2004 16:02:05 +0100 Lines: 32 References: <20041116090716.GA21088@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 16:10:47 2004 Return-path: To: Edward Lewis Mail-Followup-To: Edward Lewis , namedroppers Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 16 Nov, @ 15:52, Edward wrote in "Re: MagicType draft ..."] > At 4:07 -0500 11/16/04, Miek Gieben wrote: > > Online Signing of Negative and Wildcard Responses > > draft-gieben-bert-response-00.txt > > >4. Interaction with DNSSECbis > > > > To permit this online signing method to interact with DNSSECbis we > > will take the high bit from the algorithm field of the DS record and > > use it to indicate whether the child zone is signed with DNSSECbis or > > this online signing method, 0 indicates DNSSECbis, 1 indicates this > > method. > > What happens if there is a mix of DNSSECbis and "this method" keys in a DS > set? I'm adding this to the "Loose Ends" section... :-) But I guess the answer is, you mustn't do that. If we say you MUST NOT do that, it would conflict with DNSSECbis. This shows IMO that using the algorithms field of DS is a hack, and maybe we should do what Roy suggested and use a new DS type for this all together, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: mayer@gis.net Subject: Re: SRV resolver API? Date: Tue, 16 Nov 2004 10:41:32 -0500 Lines: 26 Reply-To: mayer@gis.net Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 16:51:19 2004 Return-path: To: Paul Vixie ,"John S. Bucy" X-Mailer: Galaxy AstroMail used by mayer X-Originating-IP: 12.38.198.125 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ----- Original Message Follows ----- > > > I'd like to suggest that part of the problem -- at least on the Unix > > side -- is that there isn't a standardized resolver API for SRV. > > The IPv6 effort came up with getaddrinfo() and friends in rfc2553; > > its gone into POSIX as well. Why haven't we standardized a resolver > > API for SRV? > > more broadly than that, a full dns client-side api is needed. we > drafted one a couple of years ago but couldn't find the funding for > it. c and c++ programmers should have the same high level access to > the dns protocol that perl programmers have (through the excellent > Net::DNS module). > Paul, is the funding needed for the work to get the standardization pushed through the various standards bodies or for the implementation? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie Subject: Re: SRV resolver API? Date: Tue, 16 Nov 2004 16:51:27 +0000 Lines: 32 References: <419a1fac.1f9.48a3.3918@gis.net> X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 18:02:55 2004 Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from mayer@gis.net of "Tue, 16 Nov 2004 10:41:32 EST." <419a1fac.1f9.48a3.3918@gis.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul, is the funding needed for the work to get the standardization > pushed through the various standards bodies or for the implementation? depends on which standards body you mean. the advanced bsd api rfc for ipv6 seems to have resulted, for the first time ever, in portability of socket-api applications. the posix socket api wasn't able to achieve this in the ipv4 days -- there were way more #ifdef's then than now. i believe two things. first, in the power of implementation. the glibc project has created a defacto standard that's a superset of ansi/posix, and the original bsd socket api (by which i intend to include things like gethostbyname) and the original bsd dns api (by which i mean to include things like res_query()) have been wildly successful, widely emulated on non-unix platforms, and generally acceptable. second, in the danger of the power of implementation. more reviewers and more creative minds would have caught a lot of errors and omissions early on which are still painful today because implementation was so powerful. while ietf's charter is all about on-the-wire protocols and formats, it did good work with the advanced bsd api rfc for ipv6, and i think that doing an advanced dns api rfc would be just as successful. isc's original funding request to the "bind vendors" on this topic included both an openly-developed api, and an open-source implementation of it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Niall O'Reilly Subject: Re: online signing draft Date: Tue, 16 Nov 2004 17:08:55 +0000 Lines: 42 References: <4190EA21.8010205@algroup.co.uk> <20041111095403.8ED62E7E50@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Niall O'Reilly , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 18:15:05 2004 Return-path: In-reply-to: <20041111095403.8ED62E7E50@mx1.nominet.org.uk> To: geoff@nominet.org.uk (Geoffrey Sisson) X-Mailer: Apple Mail (2.619) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 11 Nov 2004, at 09:54, Geoffrey Sisson wrote: > Ben Laurie wrote: > >> Samuel Weiler wrote: >> >>> Better Increment & Decrement Functions >> >> Geoff and I have been working on a rigorous definition of these, >> which I >> hope he'll post later today. > > Now available at: > > http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-00.txt in which may be found the following text. > 3. If the least significant (right-most) octet in the least > significant (left-most) label is the minimum sort value, remove > that octet; otherwise decrement the value of the octet, skipping > any values which correspond to upper-case US-ASCII letters, and > then append the label with as many octets as possible of the > maximum sort value. In either case, continue to the next step. I think there's one other special character you have to guard against! > ... skipping > any values which correspond either to upper-case US-ASCII > letters > or to the dot (\056), and ... /Niall -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Edward Lewis Subject: Re: online signing draft Date: Tue, 16 Nov 2004 12:35:57 -0500 Lines: 26 References: <32614B85-37F2-11D9-BAA4-000393B02BAC@ucd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ed.lewis@neustar.biz, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 18:46:58 2004 Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <32614B85-37F2-11D9-BAA4-000393B02BAC@ucd.ie> To: "Niall O'Reilly" X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:08 -0500 11/16/04, Niall O'Reilly wrote: >I think there's one other special character you have to guard against! > >> ... skipping >> any values which correspond either to upper-case US-ASCII >> letters >> or to the dot (\056), and ... I couldn't find the source of the included text...are you saying that "." can't be in a label? (It can. Needs to be escaped in text format, no problem in wire format.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar I would have been at the meeting, but I was busy raking the leaves from the (now) empty non-terminals in my yard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: "Scott Rose" Subject: RE: MagicType draft Date: Tue, 16 Nov 2004 14:40:58 -0500 Lines: 50 References: <20041116150205.GA29427@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 20:53:27 2004 Return-path: To: "namedroppers" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20041116150205.GA29427@atoom.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Miek Gieben > > > > What happens if there is a mix of DNSSECbis and "this method" > keys in a DS > > set? > > I'm adding this to the "Loose Ends" section... :-) > > But I guess the answer is, you mustn't do that. If we say you MUST NOT > do that, it would conflict with DNSSECbis. > Really? I would think that it would almost work. Wouldn't it be the same as having 2 DS RRs, and one having an unknown algorithm type? A DNSSECbis validator would still be able to validate positive responses, it's negative responses that would cause some errors (unknown algorithms code). Depending on local policy, the validator might resend the query in an attempt to get an RRSIG it can understand. > This shows IMO that using the algorithms field of DS is a hack, and > maybe we should do what Roy suggested and use a new DS type for this > all together, > Another option, but does that mean that there would be a DS RR and this new type? That would cause the same issues as 2 DS RRs. Scott PS - this post may be the result of a flu induced haze. > grtz Miek > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Niall O'Reilly Subject: Re: online signing draft Date: Tue, 16 Nov 2004 21:40:05 +0000 Lines: 19 References: <32614B85-37F2-11D9-BAA4-000393B02BAC@ucd.ie> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Niall O'Reilly , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Nov 16 23:17:20 2004 Return-path: In-reply-to: To: Edward Lewis X-Mailer: Apple Mail (2.619) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 16 Nov 2004, at 17:35, Edward Lewis wrote: > are you saying that "." can't be in a label? > > (It can. Needs to be escaped in text format, no problem in wire > format.) I was. Thanks for the correction. /Niall -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh Subject: Re: online signing draft Date: Wed, 17 Nov 2004 19:07:34 +0000 Lines: 21 References: <32614B85-37F2-11D9-BAA4-000393B02BAC@ucd.ie> <148443B2-3818-11D9-A195-000393B02BAC@ucd.ie> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh X-From: owner-namedroppers@ops.ietf.org Wed Nov 17 20:26:25 2004 Return-path: To: Niall O'Reilly , Edward Lewis In-Reply-To: <148443B2-3818-11D9-A195-000393B02BAC@ucd.ie> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 16 November 2004 21:40 +0000 Niall O'Reilly wrote: >> are you saying that "." can't be in a label? >> >> (It can. Needs to be escaped in text format, no problem in wire >> format.) > > I was. Thanks for the correction. Heh you can even have "*" and NULL :-) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Andras Salamon Subject: Re: MagicType draft Date: Wed, 17 Nov 2004 22:41:45 +0200 Lines: 35 References: <20041116090716.GA21088@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Nov 17 23:28:21 2004 Return-path: To: namedroppers Content-Disposition: inline In-Reply-To: <20041116090716.GA21088@atoom.net> User-Agent: Mutt/1.5.6i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Nov 16, 2004 at 10:07:16AM +0100, Miek Gieben wrote: > Since this method requires online signing there is no longer the need > to special case wildcard records. These will now be signed on the > fly. This in turn simplifies negative responses, as there is no > longer the need to prove that the original QNAME does not exist. I don't understand this text. RFC 2535: In particular, when a non-existent name response is returned, an NXT must be returned showing that the exact name queried did not exist and, in general, one or more additional NXT's need to be returned to also prove that there wasn't a wildcard whose expansion should have been returned. >From wcard-clarify-00: When synthesizing a negative answer that is derived from a wild card, meaning that a wild card matched the QNAME (no exact match happened for QNAME) but that there is no match for QTYPE there, at most two negative answers are needed, possibly one. As in 6.2.1, a proof that the exact match failed is needed. A second proof is needed to show that the wild card domain name does not have the QTYPE. Why does the online signing of wildcard records remove the need to prove the original QNAME does not exist? -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Mark Andrews Subject: Re: MagicType draft Date: Thu, 18 Nov 2004 09:48:00 +1100 Lines: 46 References: <20041117204145.GA7375@dns.net> Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Wed Nov 17 23:55:54 2004 Return-path: To: Andras Salamon In-reply-to: Your message of "Wed, 17 Nov 2004 22:41:45 +0200." <20041117204145.GA7375@dns.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Tue, Nov 16, 2004 at 10:07:16AM +0100, Miek Gieben wrote: > > Since this method requires online signing there is no longer the need > > to special case wildcard records. These will now be signed on the > > fly. This in turn simplifies negative responses, as there is no > > longer the need to prove that the original QNAME does not exist. > > I don't understand this text. > > RFC 2535: > > In particular, when a non-existent name response is returned, an NXT > must be returned showing that the exact name queried did not exist > and, in general, one or more additional NXT's need to be returned to > also prove that there wasn't a wildcard whose expansion should have > been returned. > > >From wcard-clarify-00: > > When synthesizing a negative answer that is derived from a wild > card, meaning that a wild card matched the QNAME (no exact match > happened for QNAME) but that there is no match for QTYPE there, at > most two negative answers are needed, possibly one. As in 6.2.1, > a proof that the exact match failed is needed. A second proof is > needed to show that the wild card domain name does not have the QTYPE. > > Why does the online signing of wildcard records remove the need to prove > the original QNAME does not exist? > > -- Andras Salamon andras@dns.net You are dealing with different threats and accepted risks. * Relay of wildcard proofs to different qnames. * Server compromise. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Edward Lewis Subject: Re: MagicType draft Date: Wed, 17 Nov 2004 21:18:29 -0500 Lines: 50 References: <20041117204145.GA7375@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Thu Nov 18 03:30:18 2004 Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: <20041117204145.GA7375@dns.net> To: Andras Salamon X-Scanned-By: MIMEDefang 2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:41 -0500 11/17/04, Andras Salamon wrote: >Why does the online signing of wildcard records remove the need to prove >the original QNAME does not exist? On-line signing of authenticated denials tailored to the query removes the need to worry about wildcards. This is because the proof can be tied to the query. E.g., If you want to prove that foo.example doesn't exist, you'd need: bar.example. NSEC example. RRSIG NSEC example. NSEC bar.example. RRSIG NSEC First shows that foo.example. isn't there, the latter that there's no wildcard. The reason two are needed is that's how many it takes to show that all of the places to look as specified in RFC 1034/4.3.2/step 3/part C. If you tailor the answer, you'd only need: fon.example. BERT fop.example. RRSIG BERT .... by appropriate key .... The difference is that that validator knows that the response was generated on the fly. If there was a wildcard, that record would not have been generated, replaced by an answer (if appropriate). For client-server protocols to work - you have to assume the other side is complying to the protocol. DNSSEC doesn't protect against non-compliant implementations, it protects on modifications "in transit." So, it's not important that the server 'prove' all its steps as it had to with NSEC - it's only important that the answer is signed by the holder of the secret needed. Hopefully the secret is only available to the (authoritatively answering) server. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar I would have been at the meeting, but I was busy raking the leaves from the (now) empty non-terminals in my yard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Ben Laurie Subject: Re: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Mon, 22 Nov 2004 10:29:44 +0000 Lines: 27 References: <2bcdc7c404102513103b6b1891@mail.gmail.com> <20041103150449.2285e598.olaf@ripe.net> <2bcdc7c404110308136be41e26@mail.gmail.com> <2bcdc7c404111513017dabc8aa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 22 11:39:45 2004 Return-path: User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en To: James Snell In-Reply-To: <2bcdc7c404111513017dabc8aa@mail.gmail.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk James Snell wrote: > 1. Rename the XML RR to EPX or "Endpoint Extension" RR. Since XML is self-describing, why not leave it as a general XML RR? However, I still can't see why any of this data belongs in the DNS. Since one needs to know a domain name to fetch this data, I can't see why you wouldn't allocate a port number and serve the XML over TCP on that port. In the WG meeting you said this was because DNS is a defined protocol, but I can't find that a compelling argument - HTTP would seem a far better protocol for serving this data. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie Subject: Re: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Mon, 22 Nov 2004 16:04:05 +0000 Lines: 33 References: X-From: owner-namedroppers@ops.ietf.org Mon Nov 22 17:19:13 2004 Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from Ben Laurie of "Mon, 22 Nov 2004 10:29:44 GMT." <41A1BF98.9030107@algroup.co.uk> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > 1. Rename the XML RR to EPX or "Endpoint Extension" RR. > > Since XML is self-describing, why not leave it as a general XML RR? because the rrtype has to not only describe the rdata format, but also the use to which it will be put. there was some thought in early dns that the rrtype would describe the rdata and the rrclass would describe the use; however, rrclass ended up as a zone qualifier, and so the only remaining ways to distinguish use cases is to make a subdomain (as was done in the SRV RR) or have more than one rrtype describe the same format of rdata but with different uses (MX and RP come to mind here.) there might be any number of later rrtypes whose rdata is self-describing XML, but they may be used differently than this one. i therefore agree with the proposal to call this EPX rather than XML. > However, I still can't see why any of this data belongs in the DNS. > Since one needs to know a domain name to fetch this data, I can't see > why you wouldn't allocate a port number and serve the XML over TCP on > that port. In the WG meeting you said this was because DNS is a defined > protocol, but I can't find that a compelling argument - HTTP would seem > a far better protocol for serving this data. i don't think there's a connectionless XML bearer in common use. http/tcp is a harsh prescription for some real time or embedded applications i can think of, both at the server end and the client end. xml over dns makes perfect sense to me. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: James Snell Subject: Re: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Mon, 22 Nov 2004 11:21:25 -0800 Lines: 75 References: <41A1BF98.9030107@algroup.co.uk> <20041122160405.D842913E12@sa.vix.com> Reply-To: James Snell Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 22 20:32:46 2004 Return-path: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=DCNiUTI5ED9S/xHC5eSMH7tPdzL9eiUeYEiJ591lhdr99+bheAxOOE1cmo1f3x1r9fwthXf282TkJUCXG4r1DD2eLFqXyNzvfutsNGm0MKaNZNrcDmxc6bpcdvyqeBOSBP0+veqwlvyzu/2BJJPhOA4iQ0WY1RsDPJjybdwHXEc= To: Paul Vixie In-Reply-To: <20041122160405.D842913E12@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 22 Nov 2004 16:04:05 +0000, Paul Vixie wrote: > > > 1. Rename the XML RR to EPX or "Endpoint Extension" RR. > > > > Since XML is self-describing, why not leave it as a general XML RR? > > because the rrtype has to not only describe the rdata format, but also > the use to which it will be put. there was some thought in early dns > that the rrtype would describe the rdata and the rrclass would describe > the use; however, rrclass ended up as a zone qualifier, and so the only > remaining ways to distinguish use cases is to make a subdomain (as was > done in the SRV RR) or have more than one rrtype describe the same format > of rdata but with different uses (MX and RP come to mind here.) there > might be any number of later rrtypes whose rdata is self-describing XML, > but they may be used differently than this one. > > i therefore agree with the proposal to call this EPX rather than XML. > Exactly. In the draft update that I am preparing to submit today, We've taken the further step of requiring that the EPX records only be used in conjunction with an associated EPR record. That is, a client MUST only query for EPX records if a EPD record says that EPX records are available. This will further constrain potential abuse and ambiguity with other rr types that happen to also contain XML (e.g. the Server ID stuff from Microsoft). > > However, I still can't see why any of this data belongs in the DNS. > > Since one needs to know a domain name to fetch this data, I can't see > > why you wouldn't allocate a port number and serve the XML over TCP on > > that port. In the WG meeting you said this was because DNS is a defined > > protocol, but I can't find that a compelling argument - HTTP would seem > > a far better protocol for serving this data. > > i don't think there's a connectionless XML bearer in common use. http/tcp > is a harsh prescription for some real time or embedded applications i can > think of, both at the server end and the client end. xml over dns makes > perfect sense to me. > Again, this is spot on. Additionally... we actually already tried the HTTP GET model with WS-Inspection. I am actually a fan of that approach (heck, I helped develop it in the first place) and may actually be spending some time in the near future working on an update of that spec that brings it in line with WS-Addressing. The challenge, however, is that the approach never achieved any form of success. So now we're trying this. At this point in time, please keep in mind that we are not making any claims that DNS-EPD is THE absolutely best way to do this stuff. We're putting it on the table as A way to do this stuff that leverages existing infrastructure and has some potentially interesting qualities. Once we figure out the best way to define the records from a DNS perspective, we fully intend to engage the Web services community to see if they feel this qualifies as a "Good Thing" or not. Our task right now is simply to make sure we're not causing any problems for the DNS infrastructure and are leveraging that infrastructure properly from a technical point of view. > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- - James Snell IBM, Emerging Technologies jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Samuel Weiler Subject: RE: MagicType draft Date: Mon, 22 Nov 2004 20:16:01 -0500 (EST) Lines: 33 References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Nov 23 03:07:55 2004 Return-path: To: Scott Rose In-Reply-To: X-X-Sender: weiler@filbert Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 16 Nov 2004, Scott Rose wrote: > Really? I would think that it would almost work. Wouldn't it be > the same as having 2 DS RRs, and one having an unknown algorithm > type? A DNSSECbis validator would still be able to validate > positive responses, it's negative responses that would cause some > errors (unknown algorithms code). Depending on local policy, the > validator might resend the query in an attempt to get an RRSIG it > can understand. What does the auth server do when it's advertising (via DS/DS') that both kinds of non-existence proofs are available? On name errors, return both a BERT RR and an NSEC RR (proving that the BERT RR doesn't exist)? It doesn't know whether the resolver asking the query wants NSEC-type proofs or BERT-type proofs -- it has to provide an answer that works for both. And that answer has to be completely backwards-compatible with DNSSECbis resolvers. I think the answer to Ed's question of "What happens if there is a mix of DNSSECbis and 'this method' keys in a DS set" is: the world ends. Depending on the resolver's mood, do something either kind and gentle (treat the zone as unsigned), colorful (treat the zone as not existing), or punitive (see draft-ietf-dnsop-bad-dns-res-03.txt, now in WGLC, for creative ideas). -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Samuel Weiler Subject: Re: MagicType draft Date: Mon, 22 Nov 2004 19:57:58 -0500 (EST) Lines: 33 References: <20041116090716.GA21088@atoom.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Nov 23 03:14:08 2004 Return-path: X-X-Sender: weiler@filbert To: namedroppers In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 16 Nov 2004, Roy Arends wrote: > I don't like subtyping in DS records, why not a different > type altogether. Another type that exists only at the parent side of a delegation? And that will require special parent-finding code? (Remeber the DS lameness and grandparent problems from two years ago?) This would add noticable new logic to resolvers, especially if we try to allow both types to coexist at one delegation. Imagine a referral answer that includes a DS but not one of these new RR types -- would you want the auth server to include the NSEC to prove that the new type isn't there? If not, resolvers will have to go issue another query to every parent at every delegation, specifically looking for those new types. And there are interesting backwards compatibility issues: an auth server that speaks DNSSECbis will only include an NSEC record in a referral (proving lack of other types at a delegation) when there's no DS. What's a poor resolver that groks this new type to do? Go pound that parent with more queries looking for the new type? As much as I'm a fan of changing type codes, using a new DS type scares me. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Samuel Weiler Subject: Re: MagicType draft Date: Mon, 22 Nov 2004 20:38:06 -0500 (EST) Lines: 31 References: <20041116090716.GA21088@atoom.net> <20041116150205.GA29427@atoom.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Nov 23 06:00:30 2004 Return-path: X-X-Sender: weiler@filbert To: Miek Gieben In-Reply-To: <20041116150205.GA29427@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 16 Nov 2004, Miek Gieben wrote: > > What happens if there is a mix of DNSSECbis and "this method" keys in a DS > > set? ... > But I guess the answer is, you mustn't do that. If we say you MUST NOT > do that, it would conflict with DNSSECbis. I don't see the conflict with DNSSECbis. A co-existence restriction makes it difficult if not impossible to change between the non-existence proof mechanisms without going through an unsecure state, which would not satisfy an identified requirement[1]. Other than that, I think the restriction would be fine to add, even if it means a change to DNSSECbis. -- Sam [1] This may or may not be a problem. Our requirements document doesn't tell us whether any of those who are unwilling to do on-line signing (the epsilon approach or the MagicType approach) also need to be able to transition from enumerable NSEC to something new without going unsecure. I'd still like to see that analysis. For clarification: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01994.html http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01823.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: "Scott Rose" Subject: RE: MagicType draft Date: Tue, 23 Nov 2004 12:36:28 -0500 Lines: 39 References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Nov 23 18:52:36 2004 Return-path: To: "namedroppers" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Samuel Weiler [mailto:weiler@tislabs.com] > > What does the auth server do when it's advertising (via DS/DS') that > both kinds of non-existence proofs are available? On name errors, > return both a BERT RR and an NSEC RR (proving that the BERT RR doesn't > exist)? It doesn't know whether the resolver asking the query wants > NSEC-type proofs or BERT-type proofs -- it has to provide an answer > that works for both. And that answer has to be completely > backwards-compatible with DNSSECbis resolvers. > I don't know, kind of why I asked. If I read that correctly, you believe that magic type and DNSSECbis can't co-exist in a zone? I think that might be the case as well. My comment was that it would be nice to have a way for a DNSSECbis resolver to get/validate positive DNSSEC responses from a zone that does magic type. If we use an algorithm code in the DS, the resolver will make the zone as "unsecure" (I hope) and continue, but be unable to verify even if the response was positive and uses a RRSIG algorithm the validator understands normally. > I think the answer to Ed's question of "What happens if there is a mix > of DNSSECbis and 'this method' keys in a DS set" is: the world ends. > Depending on the resolver's mood, do something either kind and gentle > (treat the zone as unsigned), colorful (treat the zone as not > existing), or punitive (see draft-ietf-dnsop-bad-dns-res-03.txt, now > in WGLC, for creative ideas). > > -- Sam > Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Edward Lewis Subject: RE: MagicType draft Date: Tue, 23 Nov 2004 14:42:30 -0500 Lines: 62 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Nov 23 20:54:18 2004 Return-path: X-Sender: edlewis@127.0.0.1 In-Reply-To: To: Scott Rose X-Scanned-By: MIMEDefang 2.48 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Why can't a zone that purports to do both in the DS RRSet do both? Why can't both a BERT RRSet and a NSEC RRSet be returned? (Will a non-BERT RR verifier choke on the presence of an unknown type in the authority section?) What would the size of a message containing both be (order of magnitude)? Always keep in mind that DNSSEC is for the benefit of the resolver - doing anything punitive would be shooting itself in the bootstrap loader. IMHO - if someone gave me a package which indicated multiple ways to verify it's authenticity and included all of the credentials for each of the multiple paths, you can bet that I would try the easiest verification first, trying successively harder ones until I succeed or run out of options. The last thing I'd want to do is throw away an accepted package - that's why I'd progress through them all. At 12:36 -0500 11/23/04, Scott Rose wrote: >> -----Original Message----- >> From: Samuel Weiler [mailto:weiler@tislabs.com] >> >> What does the auth server do when it's advertising (via DS/DS') that >> both kinds of non-existence proofs are available? On name errors, >> return both a BERT RR and an NSEC RR (proving that the BERT RR doesn't >> exist)? It doesn't know whether the resolver asking the query wants >> NSEC-type proofs or BERT-type proofs -- it has to provide an answer >> that works for both. And that answer has to be completely >> backwards-compatible with DNSSECbis resolvers. >> >I don't know, kind of why I asked. If I read that correctly, you believe >that magic type and DNSSECbis can't co-exist in a zone? I think that might >be the case as well. My comment was that it would be nice to have a way for >a DNSSECbis resolver to get/validate positive DNSSEC responses from a zone >that does magic type. If we use an algorithm code in the DS, the resolver >will make the zone as "unsecure" (I hope) and continue, but be unable to >verify even if the response was positive and uses a RRSIG algorithm the >validator understands normally. > >> I think the answer to Ed's question of "What happens if there is a mix >> of DNSSECbis and 'this method' keys in a DS set" is: the world ends. >> Depending on the resolver's mood, do something either kind and gentle >> (treat the zone as unsigned), colorful (treat the zone as not >> existing), or punitive (see draft-ietf-dnsop-bad-dns-res-03.txt, now >> in WGLC, for creative ideas). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar I think my jabber client and SMS phone are talking about me behind my back. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: James Snell Subject: Re: DNS-EPD Updates [was Re: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt)] Date: Tue, 23 Nov 2004 12:56:31 -0800 Lines: 92 References: <41A1BF98.9030107@algroup.co.uk> <20041122160405.D842913E12@sa.vix.com> <2bcdc7c404112211215d62904b@mail.gmail.com> Reply-To: James Snell Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Nov 23 22:08:21 2004 Return-path: DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZRLD2KKt0gEVY2Xo9lDWCRhl0/1mxlannsNLGcj1/jaary+6RYIeI+ijRknX9i8/Vf0I5gBmSEEp1+LnpY1eTtZ/t68RDrYnwP4FOy5a2EJvIqMHe/+wJWNt1trAhLJ4OqCnBHZoYZVdIWpcz4XGQEnfix2gM/zchLeCwUH4sNI= To: namedroppers@ops.ietf.org In-Reply-To: <2bcdc7c404112211215d62904b@mail.gmail.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk FYI... the -01 version of the DNS-EPD specification has been posted. http://www.ietf.org/internet-drafts/draft-snell-dnsepd-01.txt On Mon, 22 Nov 2004 11:21:25 -0800, James Snell wrote: > On Mon, 22 Nov 2004 16:04:05 +0000, Paul Vixie wrote: > > > > > > 1. Rename the XML RR to EPX or "Endpoint Extension" RR. > > > > > > Since XML is self-describing, why not leave it as a general XML RR? > > > > because the rrtype has to not only describe the rdata format, but also > > the use to which it will be put. there was some thought in early dns > > that the rrtype would describe the rdata and the rrclass would describe > > the use; however, rrclass ended up as a zone qualifier, and so the only > > remaining ways to distinguish use cases is to make a subdomain (as was > > done in the SRV RR) or have more than one rrtype describe the same format > > of rdata but with different uses (MX and RP come to mind here.) there > > might be any number of later rrtypes whose rdata is self-describing XML, > > but they may be used differently than this one. > > > > i therefore agree with the proposal to call this EPX rather than XML. > > > > Exactly. In the draft update that I am preparing to submit today, > We've taken the further step of requiring that the EPX records only be > used in conjunction with an associated EPR record. That is, a client > MUST only query for EPX records if a EPD record says that EPX records > are available. This will further constrain potential abuse and > ambiguity with other rr types that happen to also contain XML (e.g. > the Server ID stuff from Microsoft). > > > > > > However, I still can't see why any of this data belongs in the DNS. > > > Since one needs to know a domain name to fetch this data, I can't see > > > why you wouldn't allocate a port number and serve the XML over TCP on > > > that port. In the WG meeting you said this was because DNS is a defined > > > protocol, but I can't find that a compelling argument - HTTP would seem > > > a far better protocol for serving this data. > > > > i don't think there's a connectionless XML bearer in common use. http/tcp > > is a harsh prescription for some real time or embedded applications i can > > think of, both at the server end and the client end. xml over dns makes > > perfect sense to me. > > > > Again, this is spot on. Additionally... we actually already tried the > HTTP GET model with WS-Inspection. I am actually a fan of that > approach (heck, I helped develop it in the first place) and may > actually be spending some time in the near future working on an update > of that spec that brings it in line with WS-Addressing. The > challenge, however, is that the approach never achieved any form of > success. So now we're trying this. > > At this point in time, please keep in mind that we are not making any > claims that DNS-EPD is THE absolutely best way to do this stuff. > We're putting it on the table as A way to do this stuff that leverages > existing infrastructure and has some potentially interesting > qualities. Once we figure out the best way to define the records from > a DNS perspective, we fully intend to engage the Web services > community to see if they feel this qualifies as a "Good Thing" or not. > Our task right now is simply to make sure we're not causing any > problems for the DNS infrastructure and are leveraging that > infrastructure properly from a technical point of view. > > > -- > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- > - James Snell > IBM, Emerging Technologies > jasnell@gmail.com > -- - James Snell jasnell@gmail.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Stuart Cheshire Subject: EDNS0 numbers Date: Wed, 24 Nov 2004 12:37:54 -0800 Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Wed Nov 24 21:54:35 2004 Return-path: x-sender: cheshire@mail.apple.com X-Mailer: Claris Emailer 2.0v3, January 22, 1998 To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In an upcoming Mac OS X release, we have code that implements two EDNS0 extensions. Before we ship we obviously need to get official EDNS0 numbers allocated for these. RFC 2671 says: > OPTION-CODE (Assigned by IANA.) However, when I look at I cannot find any registry for EDNS0 OPTION-CODEs. Where do we have to go to apply for an EDNS0 OPTION-CODE? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Mark Andrews Subject: Re: EDNS0 numbers Date: Thu, 25 Nov 2004 09:25:49 +1100 Lines: 36 References: <200411242037.iAOKbssf021395@relay4.apple.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Nov 24 23:36:51 2004 Return-path: To: Stuart Cheshire In-reply-to: Your message of "Wed, 24 Nov 2004 12:37:54 -0800." <200411242037.iAOKbssf021395@relay4.apple.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In an upcoming Mac OS X release, we have code that implements two EDNS0 > extensions. Before we ship we obviously need to get official EDNS0 > numbers allocated for these. RFC 2671 says: > > > OPTION-CODE (Assigned by IANA.) > > However, when I look at I cannot find > any registry for EDNS0 OPTION-CODEs. Where do we have to go to apply for > an EDNS0 OPTION-CODE? I would just write an ID and request a option code in IANA Considerations. It also looks like "Domain Name System (DNS) IANA Considerations" needs to be revised as this should be covered there. > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Samuel Weiler Subject: Re: EDNS0 numbers Date: Wed, 24 Nov 2004 20:05:23 -0500 (EST) Lines: 37 References: <200411242225.iAOMPnMn070752@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 25 02:20:07 2004 Return-path: X-X-Sender: weiler@filbert To: Stuart Cheshire In-Reply-To: <200411242225.iAOMPnMn070752@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... RFC 2671 says: > > > > > OPTION-CODE (Assigned by IANA.) > > > > However, when I look at I cannot find > > any registry for EDNS0 OPTION-CODEs. Where do we have to go to apply for > > an EDNS0 OPTION-CODE? I can't find the registry either. (IANA, where are you?) But section 7 of RFC2671 says: IESG approval should be required to create new entries in the EDNS Extended Label Type or EDNS Version Number registries, while any published RFC (including Informational, Experimental, or BCP) should be grounds for allocation of an EDNS Option Code. While very clear, this metric doesn't fall into any of the buckets in RFC2434. It sounds closest to "IETF Consensus" (or "IETF Review", as used by draft-narten-iana-considerations-rfc2434bis-01.txt), but one could argue that it was intended to be "Specification Required". As Mark suggested, write an RFC and submit it for publication as informational, experimental, or even standards track. If you really don't want to do an RFC for your option code assignments, then propose a revision to RFC2929 that includes text on EDNS0 option codes and makes the registry "specification required". In either case, the "where do we go" seems to be "the RFC Editor". In the meantime, take a look at RFC3692. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Mark Andrews Subject: Re: EDNS0 numbers Date: Thu, 25 Nov 2004 12:33:18 +1100 Lines: 48 References: Cc: Stuart Cheshire , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 25 02:40:23 2004 Return-path: To: Samuel Weiler In-reply-to: Your message of "Wed, 24 Nov 2004 20:05:23 CDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > ... RFC 2671 says: > > > > > > > OPTION-CODE (Assigned by IANA.) > > > > > > However, when I look at I cannot find > > > any registry for EDNS0 OPTION-CODEs. Where do we have to go to apply for > > > an EDNS0 OPTION-CODE? > > I can't find the registry either. (IANA, where are you?) But section > 7 of RFC2671 says: > > IESG approval should be required to create new entries in the EDNS > Extended Label Type or EDNS Version Number registries, while any > published RFC (including Informational, Experimental, or BCP) > should be grounds for allocation of an EDNS Option Code. > > While very clear, this metric doesn't fall into any of the buckets in > RFC2434. It sounds closest to "IETF Consensus" (or "IETF Review", as > used by draft-narten-iana-considerations-rfc2434bis-01.txt), but one > could argue that it was intended to be "Specification Required". > > As Mark suggested, write an RFC and submit it for publication as > informational, experimental, or even standards track. If you really > don't want to do an RFC for your option code assignments, then propose > a revision to RFC2929 that includes text on EDNS0 option codes and > makes the registry "specification required". In either case, the > "where do we go" seems to be "the RFC Editor". > > In the meantime, take a look at RFC3692. > > -- Sam Stuart you may even need a new EDNS version. RFC 2671 doesn't state what the correct handling, as of EDNS0, of unknown / unsupported options. A new version, with associated options, however is well defined (return BADVERS). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Paul Vixie Subject: Re: EDNS0 numbers Date: Thu, 25 Nov 2004 01:44:38 +0000 Lines: 14 References: X-From: owner-namedroppers@ops.ietf.org Thu Nov 25 02:50:32 2004 Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from Mark Andrews of "Thu, 25 Nov 2004 12:33:18 +1100." <200411250133.iAP1XIjH020431@drugs.dv.isc.org> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Stuart you may even need a new EDNS version. RFC 2671 doesn't > state what the correct handling, as of EDNS0, of unknown / > unsupported options. A new version, with associated options, > however is well defined (return BADVERS). that's overkill. any option not understood should just be ignored; use of a new version should be reserved for occasions where the new signalling is not in fact optional. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Michael Richardson Subject: Re: another's view on zone enum & on-line signing Date: Fri, 26 Nov 2004 17:33:57 -0500 Lines: 82 References: <1704.1095931561@gromit.rfc1035.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Cc: Edward Lewis X-From: owner-namedroppers@ops.ietf.org Fri Nov 26 23:46:43 2004 Return-path: To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis of "Thu, 23 Sep 2004 11:38:09 BST." X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [catching up on old threads] >>>>> "Edward" == Edward Lewis writes: Edward> Let's assume that you have a zone with a mix of critical Edward> data and (for lack of a better word) vanity data. Critical Edward> would be the address record of your mail server. Vanity Edward> would be a CNAME to the entry you are using at a conference. Edward> E.g. ---> Edward> smtp AAAA Edward> marco.polo CNAME host-ripe49-139.example.net. (...lots of discussions...) Edward> Ultimately we determined (!= "and that's the way it is") Edward> that without a way to express to resolver/verifiers a policy Edward> that includes "these records can only be signed with this Edward> kind of key" and "those with the weaker key" it is useless Edward> for the server to use more than one key (per algorithm at a Edward> time). The above is simply accomplished. zone1: example. SOA ... DNSKEY offlinekey $ORIGIN example. smtp AAAA DNSSIG(offlinekey) marco.polo CNAME marco.polo.online.example. DNSSIG(offlinekey) online NS name. DS on-line-key DNSSIG(offlinekey) zone2 online.example SOA ... DNSKEY on-line-key marco.polo CNAME host-ripe49-139.example.net. DNSKEY marco.polo.SIG(0).key DNSSIG(on-line-key) The only downsides are: a) chain of CNAMEs b) dyndns client has to either know about subzone. maybe some kind of enhanced ACL would permit the master for zone1 to figure out to forward the update. c) it would be nice if marco.polo's SIG(0) key could be in the parent zone. d) lots of stupid (BROKEN) resolvers do not follow CNAMEs when they should. Upside is that zone1 is probably big, and rewriting it is a pain. zone2 is almost entirely dynamic data... if you get in trouble, empty it out again ;-) {... I keep thinking that I should spend the time to get a law degree, so that I can win all flame wars involving security policy, by default} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQaevOYqHRg3pndX9AQHsPwQAkE4GvGK2f1XEp6olIAy92aKtjsbtHTdh YIHvRAOMt5YGGVLWkS6gv+f5wilyebLjM41nEAZ1KmLFE30JgKgL9AMU0D21O+dD vnfWqQE1MNngxshNSkw5YtmpxNp8MY+q7Rxz2f8qcA+TDExC+URJCzB/0UrB7YCc JTkOHOUUtQs= =Zjnj -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: "Olaf M. Kolkman" Subject: NSEC+-epsilon (whitelies server) proof of concept. Date: Mon, 29 Nov 2004 12:29:15 +0100 Organization: RIPE NCC Lines: 128 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Nov 29 12:43:20 2004 Return-path: To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.155060 / -5.9 X-RIPE-Signature: f9c257eabba27775cc5da5d9e70d5d5e Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, I have implemented a "proof-of-concept" server for the "white lies" scheme. Although there are a number of optimizations one can do I have found this server to interoperate with a bind verifying nameserver. Rough outline. The sever itself is a proxy implemented in perl. After applying some local policy it will forward all its queries to a BIND nameserver that serves a specially prepared zone. Based on the answer being a wildcard match, a NOERROR/empty answer match or an NXDOMAIN match the proxy will cook up the appropriate NSEC white lies that "surround" the query. The nearest successor and predecessor are determined as in draft-sisson-dnsext-dns-name-p-s (with specification bugs corrected and reported to the author) without any possible optimizations. In more detail. The zone preparations is done as follows. An input zone is stripped from all its security related RRs (RRSIG, NSEC, and DNSKEY). For each domain name "dname" in the zone that is not a delegation a "dname+epsilon TXT " RR is created. To this zone the keyset needs to be appended an then the zone is signed through the regular BIND dnssec-signzone signer. After the signing process all RRs with owner name "dname+epsilon" are stripped. The result is a signed zone with NSEC RRs pointing to "dname+epsilon" instead of the next dname. This zone is loaded on a BIND nameserver running on a private address. When the proxy receives a query it will return a "REFUSE" if the query name contains "\000" or "\255" in one of its labels. This policy is not strictly needed but it is to address the issue that the the NSEC next name should be part of the zone. By refusing queries for the names that contain the "maximum and minimum sort values" that have been inserted in the +-epsilon process, we "weasel" our way out of the question if these names are or are not in the zone, the client will just never be able to know because of our policy. The proxy will forward its question to the BIND nameserver. If the answer returned from the authoritative BIND server is a "No Data" error: - the server take the packet coming from the BIND backend server and strip all NSECs and their RRs if the owner name is not the same as the qname and which are not owned by wildcard names (this preservers the NSEC RRs generated in the preprocessing phase and that are relevant for the proof). - It will then assess if the query was terminated in a wildcard match and add proof for non-existence of the direct match against the qname (it generates a name error) and return the answer to the client. - If the no data error was due because of a match against an empty non-terminal then a qname-epsilon NSEC qname+epsilon RR will be added to the proof to the client. If the answer returned from the authoritative BIND server is a "name error" (NXDOMAIN). - A proof qname+epsilon NSEC qname+delta NULL proof will be supplied. the delta is somewhat bigger than the epsilon, that is qname+delta is the first successor of qname that does not prepend a label. More detail you can find in the source which is available at http://www.kolkman.org/NSECepsilon/ The proxy runs at 193.0.3.29. It is authoritative for eg.secret-wg.org. There exists a secure delegation from secret-wg.org. Some of the zone content (not all, the challenge is to enumerate it and provide me with the zone content :-) ) *.foo 10 TXT "Wildcard match *.foo" bla.foo 10 TXT "direct match bla.foo" *.bla.foo 10 TXT "direct match *.bla.foo" hidden.foo 10 TXT "direct match hidden.foo" foo 10 TXT "direct match foo" ifeelso.empty 10 A 10.0.0.1 Please let me know if you think I overlooked an important protocol feature or you find incorrect proofs. The whole point of this exercise is to proof this can be done. TODO: There are a number of optimizations one can do based on the zone content and structure. This has not been done yet. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: Alex Bligh Subject: Re: NSEC+-epsilon (whitelies server) proof of concept. Date: Mon, 29 Nov 2004 12:43:58 +0000 Lines: 90 References: <20041129122915.0c621b43.olaf@ripe.net> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh X-From: owner-namedroppers@ops.ietf.org Mon Nov 29 13:53:06 2004 Return-path: To: "Olaf M. Kolkman" , namedroppers@ops.ietf.org In-Reply-To: <20041129122915.0c621b43.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf, Apologies for replying without reading the perl first, but I am trying to understand your thinking here --On 29 November 2004 12:29 +0100 "Olaf M. Kolkman" wrote: > When the proxy receives a query it will return a "REFUSE" if the query > name contains "\000" or "\255" in one of its labels. I am presuming you *do* in fact mean "\000" or "\255" *in* any one of its labels, not "\000" or "\255" *as* any one of its labels. If so, then this is a pragmatic rather than a purist approach (that isn't a criticism, that's an observation), as it effectively prevents any existing labels with "\000" or "\255" in from working (obviously). But if that's the case, i.e. if one is prepared to consider certain octet values as reserved (and thus unavailable for the raw zone file), then I think it's possible to construct far more simple successor and predecessor functions than those in draft-sisson-dnsext-dns-name-p-s, (especially if one enforces one octet stricter length restrictions) which are much simpler to code, understand and debug. For instance, in terms of successor functions, if one limits the function's domain[*] to labels not containing \000 and \255, less than 63 (not 64) octets, and with a similar change to the total name length restriction, then one could define the successor function as simply concatenating "\000" to the label. The result of the successor function is not going to need a successor itself, as you'll be returning REFUSE as the QNAME had a \000 in a label. All the complexity in draft-sisson-dnsext-dns-name-p-s is because it needs to support all possible values in the "original" zonefile (i.e. all legal domain[*]. [* = 'domain' in the mathematical sense, i.e. set of legal input values to a function - terminological overload - arrrgghh ] > This policy is > not strictly needed but it is to address the issue that the the NSEC > next name should be part of the zone. By refusing queries for the > names that contain the "maximum and minimum sort values" that have > been inserted in the +-epsilon process, we "weasel" our way out of the > question if these names are or are not in the zone, the client will > just never be able to know because of our policy. Yes-ish. I think you can generalize that concept as follows: If it is permissible to place further restrictions on valid label names by a set of rules (X), then by defining the successor/predecessor functions S', P' as ones which for any input value compliant with rules (X) generate a near successor/predecessor which are not compliant with rule (X), and refusing queries for QNAMEs breaching rule (X), we avoid the wildcard / existence problem. I am not ENTIRELY sure your approach conforms to the above for all cases (I am thinking of maximal DNS length) in that I think the successor might under certain circumstances not have a \000 or \255 in it. From the draft: DNS name is the maximum DNS name length: y = fooooooooooooooooooooooooooooooooooooooooooooooooo.ooooooooo\ oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\ oo.example.com. y' = foooooooooooooooooooooooooooooooooooooooooooooooop.ooooooooo\ oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\ oo.example.com. which does not have a \000 or a \255 in it. You can solve that trivially by putting a one lower limit of maximum DNS name length in the input zone. I note that for the purists, names with \000 and \255 in labels, and (I think) labels between epsilon and delta, are restricted in their use (i.e. either must not exist or it cannot be shown securely either that they do or don't exist). I do not think that is a practical issue for most users. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: NSEC+-epsilon (whitelies server) proof of concept. Date: Mon, 29 Nov 2004 14:04:55 +0000 (GMT) Lines: 93 References: <513CFCA5C6BDE3F95E79B2F5@[192.168.100.25]> X-From: owner-namedroppers@ops.ietf.org Mon Nov 29 15:28:49 2004 Return-path: To: namedroppers@ops.ietf.org In-Reply-To: <513CFCA5C6BDE3F95E79B2F5@[192.168.100.25]> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh writes: > --On 29 November 2004 12:29 +0100 "Olaf M. Kolkman" wrote: > > > When the proxy receives a query it will return a "REFUSE" if the query > > name contains "\000" or "\255" in one of its labels. > > I am presuming you *do* in fact mean "\000" or "\255" *in* any one > of its labels, not "\000" or "\255" *as* any one of its labels. > > If so, then this is a pragmatic rather than a purist approach (that isn't a > criticism, that's an observation), as it effectively prevents any existing > labels with "\000" or "\255" in from working (obviously). But if that's the > case, i.e. if one is prepared to consider certain octet values as reserved > (and thus unavailable for the raw zone file), then I think it's possible to > construct far more simple successor and predecessor functions than those in > draft-sisson-dnsext-dns-name-p-s, (especially if one enforces one octet > stricter length restrictions) which are much simpler to code, understand > and debug. For instance, in terms of successor functions, if one limits the > function's domain[*] to labels not containing \000 and \255, less than 63 > (not 64) octets, and with a similar change to the total name length > restriction, then one could define the successor function as simply > concatenating "\000" to the label. The result of the successor function is > not going to need a successor itself, as you'll be returning REFUSE as the > QNAME had a \000 in a label. I've added a comparable optimisation to sisson-dnsext-dns-name-p-s-01. A copy of the `draft' draft is available at: http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-01pre2.txt However in a delegation-only domain, the owner names of glue RRs may still be 255 octets in length. Any optimisation involving restriction of maximum length would require ensuring that no owner name of any glue RR exceeded the restriction. However I don't believe such a restriction would be unpopular with registrants: at the moment there are only two glue RRs in the co.uk zone which are longer than the maximum label size alone. > > This policy is > > not strictly needed but it is to address the issue that the the NSEC > > next name should be part of the zone. By refusing queries for the > > names that contain the "maximum and minimum sort values" that have > > been inserted in the +-epsilon process, we "weasel" our way out of the > > question if these names are or are not in the zone, the client will > > just never be able to know because of our policy. > > Yes-ish. I think you can generalize that concept as follows: > > If it is permissible to place further restrictions on valid label names by > a set of rules (X), then by defining the successor/predecessor functions > S', P' as ones which for any input value compliant with rules (X) generate > a near successor/predecessor which are not compliant with rule (X), and > refusing queries for QNAMEs breaching rule (X), we avoid the wildcard / > existence problem. > > I am not ENTIRELY sure your approach conforms to the above for all > cases (I am thinking of maximal DNS length) in that I think the > successor might under certain circumstances not have a \000 or \255 in > it. From the draft: > > DNS name is the maximum DNS name length: > > y = fooooooooooooooooooooooooooooooooooooooooooooooooo.ooooooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\ > oo.example.com. > > y' = foooooooooooooooooooooooooooooooooooooooooooooooop.ooooooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\ > oo.example.com. > > which does not have a \000 or a \255 in it. You can solve that trivially > by putting a one lower limit of maximum DNS name length in the input > zone. Note that you will always be able to devise a QNAME which will result in a predecessor or successor which not only doesn't contain \255 or \000, but is also a valid owner name in the zone. These are unlikely to occur in normal practice, though. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: "Olaf M. Kolkman" Subject: Re: NSEC+-epsilon (whitelies server) proof of concept. Date: Mon, 29 Nov 2004 14:58:33 +0100 Organization: RIPE NCC Lines: 149 References: <20041129122915.0c621b43.olaf@ripe.net> <513CFCA5C6BDE3F95E79B2F5@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 29 15:34:25 2004 Return-path: To: Alex Bligh In-Reply-To: <513CFCA5C6BDE3F95E79B2F5@[192.168.100.25]> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000749 / -5.9 X-RIPE-Signature: 45bbf0b050e5b4fded4bdb2aa5620f68 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex, I think we agree, comments in-line --Olaf On Mon, 29 Nov 2004 12:43:58 +0000 Alex Bligh wrote: > Olaf, > > Apologies for replying without reading the perl first, but I am > trying to understand your thinking here > > --On 29 November 2004 12:29 +0100 "Olaf M. Kolkman" wrote: > > > When the proxy receives a query it will return a "REFUSE" if the query > > name contains "\000" or "\255" in one of its labels. > > I am presuming you *do* in fact mean "\000" or "\255" *in* any one > of its labels, not "\000" or "\255" *as* any one of its labels. > Acknowledged. > If so, then this is a pragmatic rather than a purist approach (that isn't a > criticism, that's an observation), as it effectively prevents any existing > labels with "\000" or "\255" in from working (obviously) I have taken the "REFUSE" approach more to proof that one can never "proof" that the generated owner names are not in the zone, which is AFAIK the only objection against this scheme. I honestly think that the client side does not care about that language in the specs. > But if that's the > case, i.e. if one is prepared to consider certain octet values as reserved > (and thus unavailable for the raw zone file), then I think it's possible to > construct far more simple successor and predecessor functions than those in > draft-sisson-dnsext-dns-name-p-s, (especially if one enforces one octet > stricter length restrictions) which are much simpler to code, Well.. eh this code is pretty simple :-) .... > understand > and debug. Absolutely correct !!!! I am not saying this is the final product. I think we can do a lot on optimization. > For instance, in terms of successor functions, if one limits the > function's domain[*] to labels not containing \000 and \255, less than 63 > (not 64) octets, and with a similar change to the total name length > restriction, then one could define the successor function as simply > concatenating "\000" to the label. The result of the successor function is > not going to need a successor itself, as you'll be returning REFUSE as the > QNAME had a \000 in a label. Correct, Geoffry has documented this in his next version. > All the complexity in draft-sisson-dnsext-dns-name-p-s is because it needs > to support all possible values in the "original" zonefile (i.e. all legal > domain[*]. > > [* = 'domain' in the mathematical sense, i.e. set of legal input values > to a function - terminological overload - arrrgghh ] > > > This policy is > > not strictly needed but it is to address the issue that the the NSEC > > next name should be part of the zone. By refusing queries for the > > names that contain the "maximum and minimum sort values" that have > > been inserted in the +-epsilon process, we "weasel" our way out of the > > question if these names are or are not in the zone, the client will > > just never be able to know because of our policy. > > Yes-ish. I think you can generalize that concept as follows: > > If it is permissible to place further restrictions on valid label names by > a set of rules (X), then by defining the successor/predecessor functions > S', P' as ones which for any input value compliant with rules (X) generate > a near successor/predecessor which are not compliant with rule (X), and > refusing queries for QNAMEs breaching rule (X), we avoid the wildcard / > existence problem. > > I am not ENTIRELY sure your approach conforms to the above for all > cases (I am thinking of maximal DNS length) in that I think the > successor might under certain circumstances not have a \000 or \255 in > it. From the draft: > > DNS name is the maximum DNS name length: > > y = fooooooooooooooooooooooooooooooooooooooooooooooooo.ooooooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\ > oo.example.com. > > y' = foooooooooooooooooooooooooooooooooooooooooooooooop.ooooooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\ > oo.example.com. > > which does not have a \000 or a \255 in it. You can solve that trivially > by putting a one lower limit of maximum DNS name length in the input > zone. Ack.. that may be a cornercase. > > I note that for the purists, names with \000 and \255 in labels, > and (I think) labels between epsilon and delta, are restricted in > their use (i.e. either must not exist or it cannot be shown securely > either that they do or don't exist). I do not think that is a practical > issue for most users. > I think they can exist, they are just not obfuscated (and my "stripper" script would need a patch too :-) ). If we were to drop the refuse on the "\255" and the "\000" match I think I would still refuse on queries for the "NULL" RRs itself, as these do simply not exist, while we have NSEC RRs that can "proof" their existence. There is still some corner case for direct NSEC queries for owner names dname+epsilon, but have not been able to word that. On the other hand I can not think of a query that would result in an NSEC RR that can be used to deny existing data. --Olaf PS. I will remove the "REFUSE" on '\000' and '\255' in a day or two. Please remind me if you found this "not-done". ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: "Olaf M. Kolkman" Subject: Re: NSEC+-epsilon (whitelies server) proof of concept. Date: Mon, 29 Nov 2004 18:14:12 +0100 Organization: RIPE NCC Lines: 31 References: <513CFCA5C6BDE3F95E79B2F5@[192.168.100.25]> <20041129140455.413BCE7E73@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Nov 29 18:28:35 2004 Return-path: To: geoff@nominet.org.uk (Geoffrey Sisson) In-Reply-To: <20041129140455.413BCE7E73@mx1.nominet.org.uk> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.019268 / -5.9 X-RIPE-Signature: 43f8f5112ad0578798a7d72ab74ea1e6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 29 Nov 2004 14:04:55 +0000 (GMT) geoff@nominet.org.uk (Geoffrey Sisson) wrote: > However in a delegation-only domain, the owner names of glue RRs may > still be 255 octets in length. Any optimisation involving restriction > of maximum length would require ensuring that no owner name of any > glue RR exceeded the restriction. However I don't believe such a > restriction would be unpopular with registrants: at the moment there > are only two glue RRs in the co.uk zone which are longer than the > maximum label size alone. Glue is just glue and since it is not part of your zone it will not be signed and there will not be NSEC RRs generated for the glue ownernames. In any of the optimization you perform you do not have to do any magic that takes into acount the glue RRs. I think :-) .... -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 10:46:11 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: NSEC+-epsilon (whitelies server) proof of concept. Date: Tue, 30 Nov 2004 10:49:25 +0000 (GMT) Lines: 21 References: <20041129181412.343dacfc.olaf@ripe.net> X-From: owner-namedroppers@ops.ietf.org Tue Nov 30 12:02:46 2004 Return-path: To: namedroppers@ops.ietf.org In-Reply-To: <20041129181412.343dacfc.olaf@ripe.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" writes: > In any of the optimization you perform you do not have to do any magic > that takes into acount the glue RRs. Yes, of course. Hmm, then if all the owner names in a zone are one label longer than the owner name of the zone apex, then another possible optimisation is the omission of the last step of the derivation of DNS name predecessor, i.e. prepending labels. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: