Last Modified: 2005-02-09
| Done | Forward NSEC rdata to IESG for Proposed Standard | |
| Done | Forward RFC2535-bis to IESG for proposed standard | |
| Done | Forward Case Insensitive to IESG for Proposed Standard | |
| Done | Forward LLMNR to IESG for Proposed Standard | |
| Feb 05 | Update boilerplate text on OPT-IN | |
| Feb 05 | Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard | |
| Mar 05 | Finalize Zone Enumeration Requirements | |
| Mar 05 | Forward Wildcard clarification to IESG for proposed standard | |
| Apr 05 | Start of process of reviewing the following RFCs and to move them to Draft Standard status | |
| May 05 | Submit to IESG RFC2845 (TSIG)to Draft standard | |
| Jun 05 | RFC2671 (EDNS0) to Draft Standard | |
| Jun 05 | RFC2672 (DNAME) to Draft Standard or revision | |
| Jul 05 | RFC2136 (Dynamic Update) to Draft Standard | |
| Jul 05 | RFC3007 (Secure Update) to Draft Standard | |
| Jul 05 | RFC1995 (IXFR) to Draft standard | |
| Jul 05 | RFC1996 (Notify) to Draft Standard | |
| Sep 05 | RFC2930 (TKEY) to Draft standard | |
| Sep 05 | RFC2181 (Clarify) to Draft Standard | |
| Sep 05 | RFC2308 (Neg Caching) to Draft Standard | |
| Nov 05 | RFC2782 (SRV RR) to Draft Standard | |
| Nov 05 | RFC1982 (Serial Number Arithmetic) | |
| Nov 05 | RFC2538 (CERT RR) to Draft Standard | |
| Nov 05 | FRC2539 (DH Key RR) to Draft Standard | |
| Nov 05 | RFC3226 (Message Size) to Draft Standard |
| RFC | Status | Title |
|---|---|---|
| RFC2782 | PS | A DNS RR for specifying the location of services (DNS SRV) |
| RFC2845 | Standard | Secret Key Transaction Authentication for DNS (TSIG) |
| RFC2929 | BCP | Domain Name System (DNS) IANA Considerations |
| RFC2930 | PS | Secret Key Establishment for DNS (TKEY RR) |
| RFC2931 | PS | DNS Request and Transaction Signatures ( SIG(0)s ) |
| RFC3007 | PS | Secure Domain Name System (DNS) Dynamic Update |
| RFC3008 | PS | Domain Name System Security (DNSSEC) Signing Authority |
| RFC3090 | PS | DNS Security Extension Clarification on Zone Status |
| RFC3110 | PS | RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) |
| RFC3123 | E | A DNS RR Type for Lists of Address Prefixes (APL RR) |
| RFC3197 | I | Applicability Statement for DNS MIB Extensions |
| RFC3225 | PS | Indicating Resolver Support of DNSSEC |
| RFC3226 | PS | DNSSEC and IPv6 A6 aware server/resolver message size requirements |
| RFC3363 | I | Representing IPv6 addresses in DNS |
| RFC3364 | I | Tradeoffs in DNS support for IPv6 |
| RFC3425 | PS | Obsoleting IQUERY |
| RFC3445 | PS | Limiting the Scope of the KEY Resource Record out |
| RFC3596 | Standard | DNS Extensions to support IP version 6 |
| RFC3597 | PS | Handling of Unknown DNS Resource Record (RR) Types |
| RFC3645 | Standard | GSS Algorithm for TSIG (GSS-TSIG) |
| RFC3655 | Standard | Redefinition of DNS AD bit |
| RFC3658 | Standard | Delegation Signer Resource Record |
| RFC3755 | Standard | Legacy Resolver Compatibility for Delegation Signer |
| RFC3757 | Standard | KEY RR Secure Entry Point Flag |
| RFC3833 | I | Threat Analysis Of The Domain Name System |
| RFC3845 | Standard | DNSSEC NSEC RDATA Format |
|
Minutes of the DNSEXT working group
62nd IETF, Minneapolis, USA 9 March 2005 Chairs: Olafur Gudmundsson Olaf Kolkman Scribes: Kim Davies (minutes) Mark Andrews (jabber) Previous Minutes ================ Previous minutes were posted, no comments were received. Agenda Bashing ============== Agenda is the same as posted to the mailing list with some minor reorganisation. Ed Lewis will discuss wildcards for alittle longer than 20 minutes, following from a "design team" meeting held on Monday which examined the wildcard document and denial-of-existance work. Wildcard Document ================= Ed Lewis reported on the progress of the wildcard document, with version -05 current in the draft respository: The title has changed, no longer a "clarifications" documents as the document now changes things in the spec. Reorganised text based upon feedback. The document also considers DNSSEC implementation on wildcards - this is why the document is no longer only for clarifications as it considers new tings. There will be further changes following the meeting earlier in the week, so this document should not be considered ready for WGLC. The document clarifies the definition of wildcards as far as RFC 1034 is concerned. It defines four concepts: "asterisk label"; "wildcard domain name"; "closest encloser" - which defines where in the tree wildcards come into play, impacting DNSSEC and negative proofs; and "source of synthesis" - when a wildcard does wildcarding. In -06 there will be changes to the signing rules: * If a wildcard domain name owns EITHER an NS RRSet or a DNAME RRSet * It is NEVER a source of synthesis * Queries return NXDOMAIN * The RRSIG label count treats the records as non-wildcards One of the debates was whether to outlaw it. One comment was that www.*.example couldn't be a reasonable domain name. However the name is legal and don't want to throw it out because we found some weirdness. Decided not to synthesise anything for that example, just return a name error - NXDOMAIN. In the context of DNSSEC, if one looked for a.example, could obtain the NS record through synthesis - but could not sign it with DNSSEC. (Discussion) Rob Austein: In what way couldn't DNSSEC sign it? Ed Lewis: Lets say I am going through the algorithm for QNAME "a.example." and the QTYPE is NS. What would be done in that situation is go through the zone and fine no "a" label so I'd go to star("*") and match the * NS. According to wildcard normal rules, "a.example NS" will expand into the answer section. I am required to have a signature there, but there is no signature to put there. To make this legal I have to change the DNSSECbis protocols document so that signers would have to sign this particular case. If there was a signature there, the problem is the sig would be signed by the wrong authority. Rob Austein: My problem is this seems to be a special case to deal with garbage input. I'd rather not have special case rules to handle zones like these. Lars Liman: What you're looking at is an NS record in the parent zone, and you are worrying about the signature of that, but it is not going to be signed in the parent zone. If you ask the parent server for a deleg NS, are you supposed to get an answer, or a referral? Ed Lewis: If you look at the algorithm, there are three parts: (a) a direct match, (b) a delegation point, and (c) a closest encloser., where I answer with a wildcard or no wildcard. When I come down I don't see the cut point, it is not on my search point, so B doesn't work. The reason that the "* NS" does not result in a referral message when seeking "a.example. NS" is this. Following the 4.3.2 algorithm, I would fall into part C, which is the part in which my last matching label is at the closest encloser, so I am in a "wildcard or not situation." Referrals are in part B, but I didn't enter there. Rob Austein: You are going to have to have a case in the ordinary processing for the authoritative nameserver "I know what is supposed to be in the zone but it wasn't there". As far as I can tell this covers this mess. It is general purpose error processing. I don't see why we need a special case. Ed Lewis: I see what you mean, in Washington we talked of the same thing. I made a mistake then thinking there would be a signature there. With no sig there we would have to let the validator know it is a weird case. We have to do some editing somewhere and the group on Monday felt this is the best place to do the edits. Text will be coming to describe it. This is how the rule would be changed in 1034. If some label has an impossible match, look for existence of the star label, and does not own an NS RRSet nor a DNAME RRSet. Treat a * NS or * DNAME as "not there". This is how the rule would be changed in 1034. If some label has an impossible match, look for existence of the star label, and does not own an NS RRSet nor a DNAME RRSet. Treat a * NS or * DNAME as name "not there". Why NXDOMAIN? NXDOMAIN lets the caches stop asking, as it will get negatively cached. DS is not considered by this discussion. Another example as * DNAME - was going to treat it as CNAME synthesis but it has its own special properties. Only a few people genuinely understand it, and hope Mark Andrews can provide text. David Conrad: Agree with Rob, it is garbage input, should be indicated as so. It is easier to document it as something you shouldn't do than to screw with the signer and force other issues. Olafur: Should take the three alternatives to the mailing list. Would like those who advocate no change to advocate how to handle certain * types. Mark Andrews: One option is to make nameservers refuse to load the content. Steve Crocker: Is there any specification that defines what is a well-formed zone? Ed Lewis: There doesn't seem to be a clear idea. Rob Austein: It has never been defined as it is an implementation specific issue. Ed Lewis: On this issue, I tried to load such a zone in two different name servers. One implementation had a bug, and the other refused to load the zone. One problem with DNS is we have never been clear how to treat errors that are not on the wire - there is no concise way of saying what is a legal zone to load. Peter Koch: There is another precedent for refusing to load a zone. BIND introduced a "check names" feature. You could have a situation where the master loads a zone that contains underscores, but the slaves refuse to accept it, resulting in inconsistency. Would rather have a defined behaviour. Dont see * as a special case, but a canonical description on how the * label becomes a source of synthesis is needed. Wes Hardaker: In my experience, if you let people use something without it generating an error, it will be used. Even if 1 in 100000 DNS operators use it, given the number of zones out there, it will be an issue. Only elite operators will know its a bad case if it is not documented. Either make it a protocol error, make the tool generate an error, or it will occur in the wild. Bill Manning: Would like to see a decision by the group on whether it is legal or illegal with documents describing how to treat it, but preference is that it stays legal. Steve Crocker: Looking at it from the other end of the wire - being conservative in what you send: zone creators shouldbe able to see if they are safely within reasonable margins. You can make those margins tight, and if people want to cross them they cros a religious boundary of not being strictly illegal. Mark Andrews: I hope everyone realises that if you add * NS, you lose the ability to wildcard apart from * NS. We haven't defined how you can have a wildcard for NS and other records at the same level - this is an inconsistency. Conversation will continue on the mailing list. DNS SHA-1 ========= Olafur Gudmundsson reported that two weeks ago an attack was announced on the SHA-1 algorithm. SHA-1 is designed to have a work factor of 2**80, and the attack claims to shrink it to 2**69 - which is still a big effort to calculate. Currently it is unknown if the attack works on structured or unstructured data - i.e. structured data like a DNS record. However, attacks only get better with time. The good news is HMAC is resistant to the attack. SHA-1 is used in two places - RRSIG and DS, with TSIG usage in last call. When signing data, the data is converted to a canonical form, and a SHA-1 digest is calculated over it. There are a number of things in that a hacker may not be able to control, and data has a limited lifespan, so it is not clear if an attack can be based on this. The risk is considered low. For TSIG the issue is similar. It has a HMAC on top of it, is valid for a short time (300 seconds), and there is a fair amount of random data that goes into it. There is one use of TSIG that potentially could be under complete control of an attacker and that is dynamic updates. The risk is considered extremely low. DS represents where the real problem may exist - the long lived simple SHA-1 digest. There are some mitigating factors, such as that it covers the name. For it to be really useful the attack needs to generate keys. The reason to attack DS is to create a denial-of-service attack. The risk is low to medium, but the risk will likely increase over time. The proposal to treat this is to ignore RRSIG and TSIG; go ahead with the TSIG extension to support other SHAs - getting SHA-256 into codebases is useful. For RRSIG the working group can wait for advice on what digest algorithm will replace SHA-1. For DS a new algorithm is probably needed faster than anywhere else, but there is no security advise on what to choose. When developing DNSSEC there was a view the DS record would change infrequently - but this issue may be the first thing that needs to be rolled in DNSSEC so consideration of the transition issues is required. Sam Weiler posted a draft to the list earlier in the week and would like people to read it and comment. DNSSEC Key Rollover IPR ======================= The chairs were notified on February 6 that Diversinet Corp. that they hold intellectual property rights relevant to key rollover. The claimant has been responsive to queries and the discussion has been cordial. The patent has been awarded in one country, and a patent application has been filed in another. RFC3979 describes the IPR process. The working group needs to discuss whether to continue with these proposals given the existence of an IPR claim or work around it. It becomes an issue for implementors and users whether they want to risk lawsuits if they decide to ignore the IPR claim. Terms of license: Diversinet's position at this time is that it is worthwhile, from a public relations perspective, for it to license its technology on terms that are reciprocal, reasonable and royalty free, if such technology is incorporated into a specification. Our general license would contain terms that are typical in a commercial intellectual property license, and would include a requirement that any organization using the technology covered by our patent would have to disclose prescribed language indicating that the licensee's service or product incorporates intellectual property owned by Diversinet, and that such organization would agree to be referenceable by Diversinet in any publicity regarding Diversinet's patent portfolio. Mike St Johns, one of the authors of the affected documents, noted that the terms differed from other IP licences, in that it has the last sentence. He believed it would be unacceptable to many implementers. Bill Manning, another affected author, believed the chairs should continue the dialogue with the IP holders until there was complete disclosure. David Conrad noted that the last sentence refered to those "using" rather than "implementing" the technology, and end-users would have issue being referenced by this requirement. The chair said that if the working group didn't believe that running code could be created with this IP restriction, then we are missing one half of "rough consensus and running code". If the licensing prohibits getting code then there is an issue for the working group. Mike St Johns suggested they be asked to accept the same terms as others without the advertising clause. Others get patents just for self defense, and allow others to use their patents without using them against anyone. Sam Weiler suggested the group participants engage in a search for prior art for the claims in the IPR disclosure. DNSSEC Denial of Existance ========================== Olaf reported a number of drafts are in circulation. draft-ietf-dnsext-signed-noneixstance-requirements-01 was reported to the previous meeting in a presentation. The comments made in that presentation did not get integrated in the new version due to some time constraints. The document will be revised after the meeting and updated with inputs from the Washington meeting. Essentially two methods have been devised, one with an online key, and another is sought that does not require an online key. For online signing, the epsilon signing approach (draft-weiler-dnsext-dnssec-online-signing-01) is being fast-tracked. For offline signing, work on NSEC3 is ongoing. Sam Weiler asked for the requirements documents to be resorted to show which requirements coexist. Ben Laurie responded that this was already done in slides and would be introduced into the document in the next draft. Geoff Sisson reported he has done a draft that detailed the specifics of finding the nearest successor and predecessor of a given name. It was realised this "absolute" method was not trivial to accomplish, so it was published as an informational overview. Work on a more simplified version which assumes a single zone, with single owner names and no empty non terminals was devised. This approach reduces alot of size and computational complexity. The document will soon be in the I-D repository, and a proof of concept has been created operating with the technique. Sam Weiler explained the epsilon draft's approach. The concept is to make NSEC records cover less of the zone, resulting in attacks that are almost as difficult as dictionary attacks. The benefit is there are no resolver changes and almost no protocol changes. Some wordings need to be relaxed but they are on things not known to be checked by resolvers. In principle, you generate an NSEC which is the owner name plus a small increment. This is interesting when you want a negative answer proof. You generate this on the fly using the query name minus a small increment, for example: ).com NSEC +.com covers *.com You don't need to have a perfect epsilon function, just one that does not cover existing records. Any function will work, including those considered by Geoff's draft. Sam would like the working group to adopt this as a working group item. Olaf noted that there were no objections to this at the last meeting, and believed the document was ready for working group last call. Peter Koch said he didn't see why the perfect epsilon function detailed by Geoff and Ben was not covered in Sam's document. If it is going to be a standards track document, what are the implications if Geoff's draft only became informational? Olaf responded that Sam's document just documented a concept, whereas Geoff's draft was one of potentially numerous implementations of that concept. Roy Arends explained work on draft-ietf-dnsext-nsec3-01. At the previous meeting there were two drafts - NSEC2 and DNSNR. The two drafts have now been combined into a single draft that do roughly the same thing. In NSEC2 there was an EXIST record, needed to make empty non terminals visible. In the new draft this was replaced with additional NSEC3 RRSets. The draft also switched from hashed labels to hashed owner names, and the salt can be variable in length. There had been a large discussion on changing the salt. If you change the salt, you need to change every NSEC3 record in the zone. However, to a validator, if it is doing a single query it doesn't see all the other salts. There was also a large discussion on namedroppers that you can't roll the hash value without a protocol roll. However, you cant in the future roll a hash value to an undefined one - as implementors may not have implemented the new hash function. So the question is, do we mandate a single hash algorithm (SHA-xyz?) and drop the algorithm field? An outstanding issue is what to do if there are hash collisions. If this occurs between existing names in the zone, you can increment the salt or iterations before publishing the zone and resign. The other type of collision may occur between a qname and a hash of an owner name. If that happens, you can no longer prove non existence of the qname. Steve Crocker asked what the probabilities of hash collisions were. Roy responded he saw then as astronomically infeasible, and if they occured it was far morelikely to be a broken hashing algorithmm. Steve noted in that case he felt that discussions about deficient hash algorithms were out of scope, and that the group just had to trust that they would do their job. Roy agreed, but said he was responding to requests to address this issue. Mark Andrews added collisions will occur because the qname space is bigger than the hash space. Steve Crocker responded that the whole point of hashes was that probability was so small that in practicality you don't worry about it. If it is an issue, you use chaining algorithms, etc. Roy posed another question on hashing - whether or not hash truncation would be allowed. If it is not allowed, then the protocol can't be designed for the most extreme name. If a name is, for example, 250 characters long, there is no space to add a hash. It may be an idea to have truncation, but if so, the likelihood of collisions increases. Another issue is that with NSEC you need 2 records for authenticated denial, NSEC3 you need 3: two to prove the closest encloser and a third to prove absence of wildcards. Ed Lewis suggested reword to "showing the encloser you are giving is the closest" to prevent the term being misused. Mark Andrews noted for the discussion on hash collisions, another solution opposed to changing salt and recomputing, is the server holding different NSEC3 records with different bitmaps and returning the correct one based on the query. Mark Andrews then gave an overview of a solution he had thought of to the issue, dubbed NSEC4. This solution tries to solve the issue of appending hashes, and the consequential inability to sign all possible zones, by moving the zone into the RDATA format. This adds one extra byte to what an NSEC3 would otherwise have. The side-effect is NSEC4 would no longer be directly retrievable with a query, instead, you would only get them as the side effect of another query or AXFR. Their existence could be detected using the precondition tests in UPDATE. This effectively results in precomputed metadata on the zone that is kept in a different namespace for all zones except ".". Extra words could be added to explain this, so "." is treated the same way, hanging off the side in a separate database. The RDATA format is <HASH> NSEC4 <ZONE><A><HASH-ALG><ITERATION><SALT><HASH> A comment was received that the proposal had "serious layer 9 issues", and the chairs suggested the proposal be written up as a draft. Jaap Akkerhuis reported on a draft on "Basic Error Response Type (BERT)" developed by Miek Gieben. The draft is a protocol change designed to make signing easier by introducing simplified negative wildcard responses. It allows for a fairly simple signing model, and satisfies the universal signing requirement. The downside is the use of online keys, which means additonal operational requirements for key management. It also represents a protocol change not backward compatible with DNSSECbis. The concept is very sketchy and would like to see whether the working group is interested in the author taking this any further. Mark Andrews noted he believed it should be written up so the group can consider all the choices available. Ed Lewis noted there were many different proposals floating around but few concrete implementations. He believed it would be more useful to be workshopping prototypes to get real experience on concrete usage before having discussions on their merits. DNSSEC Experiments ================== David Blacka explained draft-ietf-dnsext-dnssec-experiments-00 was a simple technique that the working group had discussed regarding transition mechanisms needed for NSEC3. It tries to discuss how to conduct experiments without protocol changes, i.e. conducting experiments in public that are not backward compatible with DNSSEC. The draft uses the "unknown algorithm" technique to avoid IANA getting involved in every experiment, recommending a private algorithm naming scheme. The document discusses how you might transition from the experiment to a standard, but like other transitons it is not very pretty. Sam Weiler noted the DNSSEC implementation notes discussed how private algorithms might be used, and if anything is unclear in that document then he wants to be informed. Olaf enquired whether the draft was targeting an experimental, informational or standard designaton. David said he thought it needed to be standard so it gets used, but that the experiments themselves would be experimental. Opt-in Status Update ==================== Olaf noted it has been with the chairs for some time to publish Opt-in as an informational document with a boiler-plate. It has had some minor revisions and would like the group to review the document - not the technique itself, but the minor edits it has had. It has a normative reference so it will remain the queue for the time being. LLMNR Changes ============= Bernard Aboba reported on draft-ietf-dnsext-mdns-38. It was reviewed by AD Thomas Narten, and they are in the process of resolving the comments received back. Those issues are being tracked at www.drizzle.com/~aboba/DNSEXT/llmnrissues.html 25% of the issues are still outstanding, relating to conflict resolution. Issue 78 related to uniqueness probing, originally considered to be a corner case when multiple nodes seek the uniqueness of a name. However it was conceived a vendor could ship products with default names, so you could have a room full of devices called "PRINTER" etc. Therefore a mechanism is needed to resolve these conflicts quickly. Proposed solution is a "tentative" bit, which returns a response which is not verified for uniqueness. Issue 80 on multiple-protocol conflicts forsees weird conflicts when a responder responds to a query for an A record, even though it only supports LLMNR over IPv6. This conflict is unresolvable as the don't speak the same protocol. Responders need to only respond with addresses reachable using the protocol LLMNR runs over. Issue 81 on the healing of a network partition. This refers to a corner case that didn't try to solve previously. This occurs when uniqueness has been verified in a partition of a network, but then conflicts occur, how are they resolved? A conflict bit was added if the responses are not believed to be unique. A sender receiving multiple responses, and the conflict bit is clear in one or more, it knows there is a conflict. Conflict resolution is decided by "lowest address wins". Issue 82 on response merging, given that it makes sense to merge responses where the RRs are not expected to be unique, how do you merge responses for hosts that are in conflict? For example, merging SRV RRs from conflicting responders will result in inconsistent weighting, which can stay in the cache until the TTL runs out. The conflict could exist for a small period, but a polluted cache could persist longer. The proposed solution is if multiple responses are received, only those with the conflict-bit set are merged. Bernard reported that once it was believed the document was settled it would be run by the group again for WGLC. TSIG SHA etc ============ Donald Eastlake reported that the current standard only defined how to do things with HMAC, and whilst people were worried about MD5, MD5 vulnerabilities should not affect HMAC. Others want to use government approved algorithms, other algorithms, and truncate hashes. The -00 draft specified the names, syntax, and how to specify truncation. The -01 draft made SHA-1 and SHA-256 mandatory in additon to HMAC-MD5. The -02 draft is based on comments from Mark Andrews, specifying an error code for "signature too weak" to be the same as a missing signature. It specifies that a truncated signature value in a request should be used for calculating the signature for a reply; and that policies should accept longer signatures than they require and should reply with a signature at least as long as the corresponding query. A little more information was added about recent hash breaks, and policies are constrained a little so that if you accept some truncation, you should also accept longer hashes. Based on comments from Steve Bellovin, the draft repeats some advice in the HMAC-MD5 RFC. The ECC Key Draft, after some discussion at the last meeting, has had ECC signatures re-inserted into it, as well as some background. A general format format is given for expressing a vast variety of ECC keys and signatures, but the only real feedback is whether the format was too general. Donald would appreciate feedback on this draft. There are also two drafts on DSA and Diffie-Hellman keys and signatures, expected to be WGLC'd. 2538bis CERT RR =============== Olafur reported this document is in last call, and has received no comments so far. Would like some affirmation that the document is acceptable. Needs to consider whether an interop report is needed to advance it to draft standard. A meeting will be held in the afternoon to discuss interop requirements to advance the 20+ RFCs that are at proposed standard status today. Those who wish to actively participate in advancing the drafts are welcome. Cross fertilisation =================== Sam Weiler reported that the IPSEC work that began in Atlanta has been completed. No other input was received. Close of Meeting. |