DNSEXT IETF64 Meeting Minutes (draft)
Scribe: Wes Griffin
Chairs: Olafur Gudmundsson & Olaf Kolkman
IETF Last Call comments have been incorporated. Chairs will go over
latest version and check against comments and then post a summary
to the mailing list with a request for review.
In RFC-Editors queue.
Advanced to IESG, waiting for IETF Last Call.
The chairs expect IETF Last Call shortly on most of these documents.
Passed Working Group Last Call, waiting on write-up from chairs to
advance to IESG.
The documents passed Working Group Last Call, will be advanced.
Sam Weiler asked the chairs whether there was any evidence these
document had been reviewed. The chairs said that no comments at all
were received during the Last Call and the default action to advance
was in effect. Thomas Narten feels there is an issue with the default
action of advancing work that no one seems to care about. At the end
of the meeting (see later minutes) a discussion was held about the
default action. The chairs still felt that advancing these specific
documents was fine.
From the editor, these documents do not change the RDATA format. They
only update the specifications to refer to DNSKEY and RRSIG instead
of the old 2535 RRs. Additionally, rfc2539bis-dhk updates the list
of Diffie-Hellman groups to match the IPSEC DH groups.
There are no drafts currently in Working Group Last Call.
One draft has been "lost": draft-ietf-dnsext-axfr-clarify
This draft will be resurrected by the chairs.
There are some drafts that are queued for Working Group Last Call. These
drafts have been queued so as not to overload the working group with work.
Peter Koch said this draft is ready for Last Call.
This document has been on the table for a while and will be Last
The editor requested more feedback on this document, specifically
from implementors. Olafur Gudmundsson asked if the current loose
specification for key format could cause interoperability
problems? Donald Eastlake felt that implementors are better suited
to answer that question. A handful of people in the room have read
the draft and one person has attempted implemented it.
This is a running request for implementors to document design
decisions and provide input to this document.
This document is attempting to address the perceived problem that
it is difficult to get IETF Consensus or Specification Required
for allocation of new RR Type Codes. The -00 version liberalized
the early allocation process and also included a number of other
updates to the IANA Considerations for the various DNS IANA
Registries. This version met with considerable negative feedback
The new version changes the allocation to half requiring Expert
Review and half requiring Specification Required. The Expert
Review process begins with a DNS RR Type Allocation template being
filled out and posted to the namedroppers mailing list for 3
Rob Austein asked if the latest version had Specification Required
for RCODE Types. The answer was yes it does, and he asked that
those be removed, as having RCODEs that implementations don't know
about is bad.
Thomas Narten asked if there were criteria for reviewing new RR
Type Codes. He thinks there are a set of valid criteria for
determining if new RR Type Codes can be allocated. He will prepare
a document discussing these and post it to the mailing list.
This document has been updated and needs reviewing.
See later minutes.
Possible New Work
During implementation of dynamic update clients, it's been found that
if a client only has the name needing an update and not the enclosing
zone, there is no easy way for the client to determine the zone.
Additionally, if the name doesn't exist, there are major negative
caching issues with trying to determine the zone. The editor asked
the working group to adopt this work.
A handful of people have reviewed this document. The chairs asked
how many people feel this document is solving a real problem, a few
raised their hands. A handful of people said they would review this
document. The chairs will propose to the mailing list to adopt it.
Interoperability Testing Report
Nobumichi Ozoe is part of the TAHI DNS Interoperability Testing project.
They tested one DNS client and found some bugs in the client and some
bugs in the testing tool. They did not find any issues with the basic
Version 0.1 of the test tool was released 2005/11/01 and is a free
download. Current coverage includes the client functionality, basic
extensions and TCP/UDP over IPv4. Future coverage will include server
functionality and IPv6 transport. The next scheduled TAHI testing event
is end of January 2006.
There is now a mailing list: firstname.lastname@example.org and interested people can
subscribe via email@example.com
NSEC3 Report and Discussion
There is an issue tracker available for NSEC3:
Issues, both open and closed:
Issue 1: Signaling NSEC3 to NSEC3-unaware resolvers.
Mark Andrews strongly objected to a flag day and so we need signaling.
Ben Laurie answered that if we're going to do signaling, we need to
decide how to do it.
Issue 2: Transition from NSEC to NSEC3 by being insecure is fine.
Issue 3: RFC2932 Base32 encoding is used to solve the sort order issue.
Issue 4: NSEC3 hashes have owner names whose existence is denied.
No one has yet to present a technical argument on how this is a
problem. Peter Koch felt that we don't know yet whether this will be
a problem and as such we can't summarily dismiss it. Especially
considering we have a precedent of ignoring "problems" that have come
back to haunt us. He has half-seriously proposed on the mailing list
a solution involving using a new label type.
Olafur Gudmundsson felt that we should do some experimentation to
better determine if this will be a problem and keep this issue open
until then. Olaf Kolkman said that the working group has agreed that
for this document, it will not proceed until and engineering workshop
has occurred and code has been tested. Ben Laurie stated that there
are 3 implementations close to being completed.
Ed Lewis said he won't consider this issue closed until he sees it in
working operation. Russ Mundy said he wants the working group to
figure out a way we can move forward.
Mark Andrews stated that there is a way to do this that will have
zero impact on the namespace of the zone.
Issue 5: NSEC3 hash name and legitimate zone name collision is okay.
The editor believes this is not an issue.
Rob Austein said that he's 3/4 close to leaning towards Peter Koch's
half-serious new label type proposal. He feels this is a much cleaner
solution to all this collision stuff and has the added benefit that
it can be defined as a binary-only label type which removes the sort
order issue as well.
Ben Laurie asked how this would interact with caches that don't grok
the new label type. Rob replied that dnssec-bis doesn't work through
dnssec-oblivious middle boxes, so this might just be a non-issue.
Paul Vixie stated that the original idea behind the separate label
type was to provide a way to store the various sets of metadata that
aren't truly dns data and hence don't really belong in the actual
database proper. This data we're talking about here is also not dns
data and so a separate label type would go a long way to helping this.
Ben asked if people were okay waiting until implementations were done
before deciding on this.
Issue 6: There is a potential DoS attack on resolvers.
Evil editoritative servers can select such a high number of iterations
that resolvers are overwhelmed. The proposal is to allow resolvers to
specify an upper limit for iterations that it will accept and if a
response has a higher number the resolver will treat is as bogus.
Olafur Gudmundsson asked why we can't get rid of iterations and just
use the salt. Ben explained that the iterations are designed to
increase the cost of a dictionary attack, while the salt is used to
increase the cost of a pre-computed dictionary attack. Olafur
rephrased his question to is the salt sufficient for the threats
people are seeing? Ben feels this is no, as a single iteration is
very easy to handle with a network probe.
Olaf expressed a concern that leaving this up to resolvers will cause
some resolvers to set a low number and some a high number causing a
zone to appear secure or bogus to different resolvers. Ben answered
that by picking a sufficiently high number this shouldn't be a
problem. It should be a single number and not in the draft.
Mike St.Johns said that if a number is going to be chosen, please put
it in the draft and be nice to implementors and users, don't make it
configurable, just set it across the board. Ben says if the working
group feels strongly about this it will be done.
Someone asked if a mechanism could be added such that parent zones
can set limits for the iterations. The room response was highly
Issue 7: How secondaries know the NSEC3 parameters a zone is using.
The solution is that any parameter set present at the apex will be
present in the entire zone.
Issue 8: The next version of the document will include additional detail
about the design choices and rationale.
Issue 9: The next version will have the hash algorithm field set to 8
bits so that it can share the hash algorithm registry with the DS RR.
Sam Weiler asked about his proposal to get rid of the algorithm field
in the NSEC3 RR and just inherit the algorithm used by the DS RR.
Olaf Kolkman asked how this would work if there was no parent.
Mike St.Johns asked what if a zone is using multiple hash algorithms.
Trust Anchor Management Reports and Discussion
This space is rapidly growing with drafts and there has been very little
review by non-involved participants. The chairs urge the working group to
pay attention because this item is very important to deployment.
A co-editor stated that this update was primarily to boilerplate to
refresh the draft so that it would be available for consideration.
A prototype implementation is currently being worked on. This and the
following 2 drafts have IPR claims on file with the IETF. The
co-editor stated that he's been working with his university lawyer
and can proceed on a prototype implementation. He expects it will be
ready by the end of the year and will make it available to a select
group of people who will not be affected by the IPR.
The editor said this version is almost a boilerplate change to
refresh the document. He has started an implementation in dnsjava.
The author presented slides on some basics of trust anchor management
including some discussion of requirements and how the TAKREM proposal
Ben Laurie asked why, since emergency key rollover doesn't depend
on key revocation and there will be some other mechanism to do
revocation, why not just use that?
Mike St.Johns asked about how previous keys are revoked. The author
said the TTL would revoke the keys, it was pointed out that there is
no built-in lifetime on keys. He said this would be addressed.
Bill Manning asked about one slide bullet that said change control
had been handed over to the IETF and if this meant the IPR claim no
longer applied? The author said no.
Steve Crocker said it would be much easier if the technology was
unencumbered so that we could get on with implementation and testing.
The editor said there was already an licence for GPL implementations.
Ben Laurie, Paul Vixie, Matt Larson and a Cisco gentleman all said
GPL was insufficient for their needs. Olaf Kolkman summed this as a
requirement for the trust anchor management requirements document.
The author stated a requirements document by the working group would
The author said the original idea behind this proposal was to do it
with x.509, but that x.509 has some issues with cross-signing and so
a future version will use PGP signatures. This is the only proposal
on the table that has no known IPR issues.
Bill Manning asked about what transport this will use, as the user
is expected to visit a URL and follow a signature chain. His concern
is that the end-to-end assumption is increasingly wrong. Also, how
does the proposal cope when data can't be pulled from the URL? The
editor responded that http is the current transport, but really
anything can be used. Also, the data can be pulled from any location
so this shouldn't be an issue.
Russ Housley asked why this is solving the problem, as he thinks it
doesn't. Also, this looks exactly like what x.509 was designed to do.
The author said that x.509 doesn't support multiple certificates with
the same DN, Russ said it did.
Michael Richardson asked if there could be some sort of cross
signature threshold mechanism added so that resolvers only trust
what's going on when there are a minimum number of signatures.
The author said that this proposal was such that if a resolver
trusts a zone, then it trusts what the zone signs (and cross-signs).
Paul Vixie: Simple Key Rollover
All of the current mechanisms seem overly complicated. This method:
Adds a new zone apex RR that expresses H(keyset).
This is included in the authority section in replies.
Interested validators can track this RR.
When it changes, the validators can fetch the new keyset.
If the new keyset validates it becomes the new trust anchor.
Interested validators can also pull.
This pulling is based on the half-life of the current keyset
signature lifetime and the half-life of the current keyset
The pulling is obviated by the new zone apex RR if seen.
This new zone apex RR is an opportunistic optimization.
This differs from the N-of-M proposal:
N is now a per-algorithm constant, and 2 seems to be fine.
Removes a policy knob from the client.
The new zone apex RR trumpets new keysets.
Most validators won't have to pull.
Revocation is by omission only.
It is always good to have more than one key.
This is very lightweight, but doesn't solve emergency rollover.
Puts most of the policy on the server-side.
Validator policy is simple.
All a validator does is track static configured trust anchors.
Possible Server Side Policy:
Never use a key without also publishing the next one (or the next
Never use a key without also publishing a backup at the same time
(for revocation purposes).
Overlap current/next key lifetimes by 50%.
Start using a new key at the second half-life (25% remaining) of
the existing key.
Roy Arends asked why we need to add a new zone apex RR, why not just
publish the keys? Olaf Kolkman responded that there are size issues
with publishing all the keys.
Ed Lewis noted that while server side policy may not be an issue,
DNSSEC has always been about the view of the DNS at the resolver.
Margaret Wasserman stated that all of these mechanisms appear to be very
different in everything that they're trying to do. For example, do we
have consensus on needing emergency key rollover, or do we have ideas on
requirements or threat models?
Olafur Gudmundsson asked what do we have to do with trust anchors? For
example, should a trust anchor management protocol be able to turn off
DNSSEC for a zone? We need a better handle on the key rollover requirements.
Olaf Kolkman stated that this work has come up through the mailing list
and the solution space is expanding without the working group knowing
which metrics we want to apply to make a choice. He asked for a volunteer
to start a draft outlining the requirements. He also asked if this is work
that interests the working group. If there is no work currently being done
in the working group do we care about the work? A room hum is
overwhelmingly in favor of the work.
Olafur says we need volunteers to work on requirements, review documents,
and do work. The chairs will ask on the mailing list for a deadline for
requirements being done.
Thomas Narten is troubled in that there seems to be some sort-of interest
in this work, but the work itself is not getting done. Perhaps the wrong
questions are being asked, how about asking something like "What are our
3 top priorities, the 3 most important things to get off the table?"
Ed Lewis stated that as a consumer of an ISP, I don't care about what
keys zone operators are pushing out, but I do care about my ISP and
what keys they are using.
Olaf felt that we can't make further decisions here on a way forward. We
need requirements and metrics on what is sensible and what the group
Default Action For Document Review Discussion
The chairs ask if the best way to handle review is to set a lower limit,
on the order of 4 or 5 people, that must review a document before it is
advanced. The room hums consensus.
Peter Koch asks what will happen if the document doesn't reviewed, will
it get dropped or will it remain on the work items list indefinitely?
The chairs state that the document will be dropped and authors will have
to do a personal submission.
Sam Weiler asks that before the drop occurs, we keep it as a work item
and have a review by name and then if there is still no movement, drop it.
The chairs see 3 major work items:
Trust Anchor Management
Work dealing with forwarding documents along the standards track
This includes rewriting any documents that need clarification.
The chairs ask for a hand show of what is more important:
The chairs asked if there is a reason we should NOT do this work in
parallel? Sam Weiler said that as long as there is a critical mass of
people working on each item, then we should do the work in parallel.
Thomas Narten mentioned that even thought requirements documents have bad
reputations, without them, important discussions are often side-stepped
and not resolved. The requirements documents should be short-fused, if
one cannot be completed in 3 months, the work has a serious problem.
The chairs responded by saying that requirements are needed, and if the
requirements are not completed in a timely manner the work will be