Subject: Draft DNSEXT @ IETF62 Minutes

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 21 Mar 2005 12:05:18 +0100

[ Moderators note: This post needed manual approval.

   Either it was posted by a non-subscribed address, or the posting
   was too large ( > 20000bytes ) for this list.

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please use your subscribed address to post, or shorten your
   postings by using links instead of attachments. ]

Dear Colleagues,

Below are the draft minutes of the DNSEXT Working Group meeting at
IET62.

Thanks to Kim Davies who did an excelent and timely job!

If you have any issues with these draft minutes please let us know in
the next couple of days. I will forward these minutes to go into the
IETF62 proceedings somewhere next week.

--Olaf

Minutes of the DNSEXT working group
62nd IETF, Minneapolis, USA
9 March 2005

Chairs:
Ólafur Guðmundsson
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 answering 
“a.example” and the qtype is “NS”. What is would do in that situation 
is go through the zone and fine no a, then I’d go to star and then I’d 
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, 
I cant put the signature in there. To make this legal I have to change 
the 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. Then I 
answer with a wildcard, no wildcard etc. When I come down I  don’t see 
the cut point, it is not on my search point, so B doesn’t work.

This is written in the draft when we enter step (a), (b) or (c), we 
don't jump across.

Rob Austein: You are going to have to have a case in the ordinary 
processing for the authorittive 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.

If the type is not NS, there is no problem. Only when it is an NS or a 
DS do we get anything back and there is where there is a concern.

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”.

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
=========

Ólafur Guðmundsson 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
===============

Ólafur 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.

-- 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>