meeting summary: 23 June 2004
James M Galvin
galvin at elistx.com
Thu Jun 24 18:17:30 EDT 2004
23 June 2004
Mike St. Johns
Steve Crocker asked for an up-to-the-minute update on the status of the
The short answer is the working group is converging and we need to give
it time, time on the order of a few weeks.
The longer answer is that July 15 may be doable. It is within days of
the internet-draft cut-off for the San Diego IETF. If that deadline is
missed the drafts will be delayed for at least month.
The goal is to not to change anything at this point. However, zone
enumeration through NSEC is still a substantial topic. An alternate
proposal (called NSEC2) has surfaced, which has some merit, but we are
trying very hard to prevent further delay at this time. We would prefer
to move forward with DNSSEC-bis and later introduce NSEC2 (or whatever
else might turn up and be more applicable). We would permit some small
changes to ensure forward compatibility if could identify them.
A component of the discussion is concern over changing the security
model. There are folks who are suggesting fundamental changes that
affect the security model, which is something we do not want to do.
Consider that it took us almost 15 years to get where we are and a
change such as that is likely to delay us for a period equal to some
significant fraction of that. Obviously we would need time to
understand the new security model.
One relatively new data point in the discussion is the desire for
private domains. There are TLDs asserting that they have customers with
domains that are private that they do not want to be public. Private in
this context means that if you don't know it exists then you can not
However, technically speaking, this is nonsense. Domains can be found
with a dictionary attack against a name server. [ Editor's note: I
thought I heard someone suggest there was an 85% probability of being
found this way but there was no reference to go with it so I just
mention it as a footnote unless someone wants to clarify the point. ]
More to the point, a dictionary attack against a server will use far
more resources and be far more operationally devastating than permiting
the NSEC enumeration. The reality is privacy or confidentiality is
simply not supported in this version and we need to accept that and move
on. We can consider adding that as a requirement in the next version,
if there is one. Also, those who support NSEC and who are concerned
about its performance should just "publish" the contents of their zones.
-- DNSSEC Deployment Roadmap
Discussion will continue with the matrix proposed last week. The
following people will be providing content for the indicated
1. Manual - Rob Austein
2. Revoke Bit - Olafur Gudmundsson would get Mike St. Johns to
do it, or write something himself
3. M-of-N - Johan Ihren, Olaf Kolkman, Bill Manning
4. DLV - Paul Vixie
For each of the schemes, we want answers to the following questions.
a. Is it a protocol change?
This answers the in-band versus out-of-band issue.
b. Is it permanent?
This answers the "do we need to get it right the first time" issue.
c. Applicable to the root or other trust anchors?
Roll-over is important throughout the DNS hierarchy and a more
broadly applicable mechanism would be preferred.
d. Impact of non-attention?
This answers the "is it automated or manual" issue. We
recognize that people will simply install "whatever" and expect
it to work.
e. How to recover?
This answers the "what to do when the system (particularly the
automated parts) fails" issue, and we know it will fail for
reasons we can not even imagine right now.
Very little input was received for the matric this week. The lateness
of last week's meeting summary was cited as the primary reason.
Consensus was to carry this agenda item forward to next week's
Steve Crocker would also like to make more progress on the roadmap
document itself. He enlisted Scott Rose and Russ Mundy to help progress
Mike St. Johns asked if there would be keying information "published"
other than the root public key, a la the Paul Vixie suggestion? Paul
Vixie said he hoped not.
Rob Austein noted that the specification now talks about 0 or more trust
anchors. Zero, of course, is not useful and the only case where 1 is
useful is when it is the root. Trust flows downward and you can trust
anything as long as a superior node is a trust anchor. What constitutes
a trust anchor is a matter for local policy.
Steve Crocker asked what the VeriSign position was on DNSSEC but Mark
Kosters was no longer with us. Paul Vixie noted that in the past Mark
has said that VeriSign's position is that it is a business decision. At
the point in time that "selling" DNSSEC exceeds the "cost" of offering
it in some measurable amount of time they will offer it.
Paul added that DLV was created expressly to enfranchise people in just
such a situation, i.e., zones could participate in DNSSEC even when
their parent was not participating.
Steve closed the meeting by getting a recommitment from folks to provide
text for the matrix.
More information about the Dnssec-deployment