Subject: Brief summary of Oslo DNSIND/DNSSEC meeting

From: Robert Elz <[email-masked]>
Date: Mon, 12 Jul 1999 19:53:03 +0200

This message is not the minutes of the meeting.  Nor is anything reported
here binding in any way of the group, we will discuss issues on the list.
That can be done now (please start a new thread though, don't just reply
to this message, and keep such discussions on namedropeprs alone), or you
can wait for the minutes (or at least the first draft of them) to appear.

Also, a reminder of the request to all who attended the meeting.
If you took any notes, please send me a copy, now.   Please don't
wait to clean them up, etc - I'd prefer to have them as they first
appeared (I also don't care if they contain references to how useless
I am as a WG chair, etc ... I won't be resending your notes anywhere,
just using them to assist in preparation of the minutes).

Also, if anything below doesn't agree with your recollection of what
the meeting did, please say so now, so the real minutes can be as accurate
as possible.   Say so on the list, so everyone can see, and respond.

First announcements: edns0 has passed the IESG, it ought appear as an
RFC sometime (the announcement to the RFC Editor from the IESG probably
won't happen until after this meeting is over, and Steve Coya returns
to his office).   That will also release dname and binary-labels from
the RFC editor's hold queue (or the IESG's hold queue, or something).

An IETF last call of tsig-09 should appear soon (you will probably have
seen the request for that in your mailbox sometime around the time that
you see this message).

The proposed charter for the new combined group was discussed briefly.
Since the last version posted on the list, it has had a sentence added
includig TSIG along with the DNSSEC in the "what the group does", as
requested by Ed Lewis.  The people in the room were generally happy to
call the new group dnsext.   No new issues were raised, though the
"work in progress" and "milestones" will need to be revised as a result
of this meeting, and then again as the result of discussions anticipated
on the list.

Matt Crawford asked (again) whether there were any more comments on
draft-ietf-ipngwg-dns-lookups-04.txt - that is the definition of A6
records.   That (ipngwg) draft should be going to IETF last call soon.
There are suggestions that the IESG are looking for DNS review.

What ought be done with 2052bis was discussed.   General opinion favoured
continuing to push it as PS.   A long list of IESG requested changes were
discussed (these to appear on the list soon).   Aside from a bunch of
trivial changes, the two of most substance concerned the definition of
the weight field, and its processing - the suggested wording for that will
still need some more work (either rephrasing, or a complete new method)
but was generally considered acceptable.   The other concerned the examples.
There was much feeling that giving examples using protocols that don't
use SRV records was not a good idea (and that the examples/test that relate
to SMTP was particularly bad).   What to replace them with wasn't
as obvious.   There were two basic suggestions - either use some of the
protocols/usages that are now being created (there are a few in drafts
scattered about, I will probably find some of them for the next, longer,
message on 2052bis, but please, everyone, send pointers if you know them).
Or, create a fictitious protocol, the foobar protocol, or something, and
use that for the examples.   I detected no consensus on which is the best
approach.

edns1 was very briefly mentioned.   Discussion of it ought take place
on the list.   This is one of our major work items - please read it
and comment.

Some discussion on tkey.   It has been waiting on tsig, but that is done
now.  Question on whether it ought be simplified, and whether as a mechanism
it belongs in the DNS at all.  Opinion expressed that as a bootstrap
method it might be needed - it provides a way to get somekeys initially,
without depending upon some other protocol, which is likely to be depending
upon the DNS.   After that, if better keys are needed,  other mechanisms
can be used.   Opinion: this leads to multiple ways existing of doing much
the same thing.   More discussion of tkey on the list is needed.

Some discussion on simple-secure-update.   A list of the changes in the
draft was given (without explanations in all cases, the draft author was
not at the meeting).   Dynamic update needs this or update2 (next draft
to be discussed).   Q: are there any implementations of this, or is it all
just theory?  A: so far, theory.   But BIND9 is to implement this it was
reported (but not update2).

On update2 - this is the intended replacement for rfc2137,  which has
been obsoleted by 2535, but not yet replaced.   As it stands it is too
complex.  A new draft, rather simpler, will eventually appear.   General
opinion that a mechanism like update2 is required, but not update2 as
it stands.   Not recommended for anyone to implement as it is.

Also suggested that "simple-secure-update" and "secure-update" are loaded
names, and that "shared key update" and "public key update" might be
better terms.

List discussion is needed on how we go about authenticating dynamic update,
both in the local area, and over the internet as a whole.

Brief discussions on rollover - mechanism to allow automated key-resigning
requests (nb: not the signing itself, necessarily, just the notification that
a resigning is required, if I understood it correctly).  There has been little
comment on this draft, comments were solicited.   Q raised on how all this
relates to a parent zone with shared administration, might it not be complex?
A: yes.   Series of questions/answers related to whether this is a good
mechanism to request a key-signing, that might then take days to actually
occur.   More discussion of this needed on the list.

Brief discussions on sec-rr (and on keyreferral, which was not on the
agenda itself, but which is a related draft).   Explanation of the
motivation for these drafts, and then statement that perhaps the problems
they were addressing weren't such great problems as had originally been
thought.   The author who spoke to them suggested that these drafts be
left to stew while more experience with dnssec is gained.

The kitchen-sink rr - an idea which has been percolating for a while now.
Intended as a place in which those who desire a new rr, but don't want to
standardise it (perhaps who cannot get an RR type code from IANA, because
they won't reveal the details of the internals of the RR).   That is, this
is suggested as an alternate to the use of TXT records as a place to put
junk, but with a bit more structure that should make it safer to use.
There should be a new draft of this within about a month, after which it
will be considered for advancement as an Experimental RFC.

A new draft on the apl-rr has been published, has accounted for earlier
concerns, no new issues have been raised - this one considered ready for
WG last call, whether it is ready to be advanced as a PS RFC.

Discussions on the DDDD draft (deferred delete).  Another idea which
keeps coming back, over and over again.   General agreement that there's
the essence of a problem here that there should be a way found to solve.
General agreement that this draft is not the way - considered to be much
too complex, especially in dealing with all kinds of failure cases that
don't really matter anyway.   Overall consensus to avoid further work
on this draft.

Then the verify and local-compression drafts.   These largely are alternatives,
both attempt to solve the basic problem of dealing with compressed names in
RR types which are unknown to the server processing them.   local-compression
deals with that by not requiring the server to know thee's a name there
(unless it is the end user of the RR, in which case it had better understand
the type).   Verify deals with it by requiring that all RR types (except a
list of known existing ones, whose characteristics are assumed known to all
servers) explicitly declare where any embedded names can be found.
There was no enthusiasm in the meeting for proceeding any further with
verify.   local-compression seems to be ready for WG last call for PS.
But it was also asked whether we really need to allow compression in the RDATA
field of any RRs at all, other than NS records (and particularly for the
root domain).   Would anyone suffer much if all compression was prohibited.
No-one could think of any cases where anything much would be lost.  The A6
record was the one suggestion where it might matter, but it was also considered
that compression (of any kind) might not often save much there - being able
to negotiate bigger payloads was a much more important issue.

Some discussion on local-names.   Author says that the draft contains two
distinct issues, the first of which is just a "how to" (of I understood
that correctly), and is relatively non-controversial.  The second (which
includes creating a "local" TLD - which to be effective needs to actually
be implemented in the root zone) is more so.   Q: is there any demand for
this draft at all?   Author reported some contacts indicating that it was
already in use.   Author suggests BCP as preferred target.   A new draft will
appear, after which the WG will discuss this draft again.  Comments welcome
any time of course.

On other business:   Don Eastlake suggested that a doc of IANA considerations
for DNS RR's needs to be written.   Bill Manning said that he had also been
asked to put some effort in that direction.   They will co-author a draft.

No-one had looked at the dnssec-external-keys draft that recently appeared.
If that is to progress anywhere, some motivation will need to be established,
and then it be resubmitted as a dnsind draft (if agreed by the WG).

On the question of whether there had been any consideration of the
global location RR (GLOC) there was nothing but laughter.

A new policy for dnsind (whatever) was announced as a trial for the next
IETF meeting (the 46th, in Washington).   Drafts to be considered at the
dnsind (or dnsext if it exists then)  will be required to be submitted at
least 2 weeks before the ietf secretariat's draft deadline.  Any that
miss this earlier deadline will be considered in the meeting only if time
permits - discussion of other drafts will not be squeezed to make time for
them.   This will be reviewed at/after the Washington meeting for future
meetings.

The meeting actually managed to end on time, or even a couple of minutes
early.   That's why the "brief discussion" phrase occurs so much, many of
the "discussions" truly were brief.

kre