Subject: 
       DNSIND/DNSSEC minutes for Oslo IETF
   Date: 
       Sat, 07 Aug 1999 23:18:54 +1000
  From: 
       Robert Elz <kre@munnari.OZ.AU>
    To: 
       minutes@ietf.org




Minutes for DNSIND / DNSSEC joint meeting, Monday July 12, 1999, Oslo

Chaired by Randy Bush and Robert Elz.   Minutes taken by Robert Elz
with the assistance of M.T. Hollinger, Mark Gritter, and Ed Lewis.

One agenda addition from previously published agenda: added a brief
slot for Matt Crawford to talk about ipngwg's A6 record draft.

The proposed charter for the proposed new merged dnsind/dnssec WG was
shown, no comments received.  "dnsext" received no objections as the new
WG name.   The charter will now have its milestones updated reflecting
the outcomes of this meeting, will then be sent to the list for review,
and then, assuming there are no problems, will be sent to the ADs for
IESG approval.

The list of dnsind & dnssec RFCs in PS status was reviewed, with brief
comments on what their next steps might be, and when.  RFC1982 is, and
has been for some time, ready to advance.  RFCs 1995 and 1996 still
need some interoperability testing.  RFC2136 must wait until there is a
security mechanism ready to advance to DS along with it, which won't be
RFC2137, which is obsolete already.  RFC2181 will be a little difficult
to deal with, because of its nature.   No interoperability reports yet
exist on RFC2308.   None of the newer RFCs (2535-9, 2541) have been at
PS long enough to advance yet.  And there are three more approved by
the IESG, but not yet published (edns0, binary-labels, and dname).

All known current internet-drafts in dnsind and dnssec were then
listed, and briefly discussed.    The group suggested possible outcomes
for the various documents, more detailed discussion of many of which
was on the agenda anyway.  Of the ones not on the agenda for this
meeting, it was felt that draft-skwan-gss-tsig-*.txt should advance as
PS, draft-ietf-dnsind-indirect-key-*.txt may proceed as either PS or
Experimental, that to be determined later.  Discussion of
draft-ietf-dnsind-keyreferral-*.txt was merged into the agenda item on
draft-ietf-dnsind-sec-rr-*.txt.  It was felt that
draft-skwan-utf8-dns-*.txt needed to be compared against UTF5 proposals
(of which no draft was known at the meeting, though the name of one was
subsequently sent to the list).

Draft-ietf-dnssec-as-map-*.txt has been sent to the routing area so
often over the years that no-one has kept count, it kept returning to
dnssec when no-one from routing showed much interest.   The group
resolved, once again, that this draft is not work for this working
group.   No-one had any information on draft-ietf-dnssec-secfail-*.txt
and it was consequently dropped (it is an old draft and should most
probably have expired by now anyway).   A draft just recently submitted
with a dnssec label (draft-ietf-dnssec-externalkeys-*.txt) was also
unknown to the group, and not considered to be a work item.

One additional draft, draft-ietf-urn-naptr-rr-*.txt (from the URN
group) was noted as being one that this group should keep an eye on, if
not actually take over from that group.   This is intended to become a
standards track RFC.

Finally, draft-ietf-dnsind-tsig-09.txt had completed its working group
last call, and was considered ready to be sent to the ADs for review
and IETF last call for PS.   Being (apparently) completed no
discussions of this draft were held.

Matt Crawford spoke on the A6 record draft from the ipngwg group.  That
is draft-ietf-ipngwg-dns-lookups-*.txt.   He was asked about the
potential explosion of lookups that could possibly be required.  The
answer was that resolvers should limit the amount of work they're
willing to do - anyone who makes an unreasonably complicated zone (too
many indirect A6 records) will not have their names resolved.  They
will be the ones to suffer.   This is much the same as that which
limits chains of CNAME records, etc.

There was discussion on the current status of
draft-ietf-dnsind-rfc2052bis-*.txt, the planned replacement of the
experimental RFC 2052.   This draft completed its working group last
call and IETF last calls early in the year, after which it was rejected
by the IESG.   Subsequent discussions, on the namedroppers list, and in
private between the chairs, ADs, IESG, and IAB, have so far failed to
arrive at a compromise position.

The most recent list of 11 requested changes were discussed.  Some of
those were considered as trivial, some had been previously agreed by
the working group, just have not yet appeared in a new draft while other
open issues remain.  Most discussion centered upon what protocols (or
non-protocols) should be used as examples of the SRV RR that this draft
defines.   Using examples of well known protocols which do not in fact
actually use SRV was objected to by the IESG.  The group made no actual
progress on resolving this issue during the limited time available in
the meeting.   Aside from some requested wording changes there were
less objections to other proposed changes, except that some members of
the group felt that prohibiting the use of SRV records in protocols
other than where their use was specified by an RFC was going to far,
and claimed to be already using them for applications like telnet.  One
wording change requested, and generally agreed with, was to replace the
phrase "load balancing" anywhere it appears (an in one place in
particular) by the phrase "server selection".   It was felt that
attempts to read the SRV record as a mechanism by which load could
really be balanced in any meaningful interpretation of the term may be
one of the causes of some of the difficulties this draft has
experienced.  The attendees felt that pressing ahead with attempting to
get this published on the standards track was worth while - it was
noted that it has already been implemented, and our attention was drawn
to draft-ietf-cat-krb-dns-locate-00.txt.   More discussions will be
held on the mailing list.    The milestone for the charter on finishing
this document is still way out into next century however (and
receding).

There was a very brief mention of draft-ietf-dnsind-edns1-*.txt, and
its aims.  It was requested that discussion continue (start really) on
the list.

Donald Eastlake III spoke on draft-ietf-dnsind-tkey-*.txt.   It has
been waiting upon tsig to be finished before any real attempts to push
it forward.   This is a scheme for agreeing upon keys (to use for
tsig).  He was asked if this belonged in the DNS at all.  The answer
was that a mechanism is needed, and it needs to be one which does not
rely upon the DNS being functional, he was loath to depend upon any
other mechanisms necessarily being available.   It was pointed out that
this would mean there would be (could be) multiple different mechanisms
to obtain essentially the same information.   Don asked the group
whether all of the options that currently exist in the tkey draft are
required, and whether it should perhaps be simplified.   More
discussion on this draft is needed on the list.   It is currently
intended as a standards track document.

Edward Lewis, as proxy for for Brian Wellington, spoke on
draft-ietf-dnsind-simple-secure-update-*.txt.   He went through the
changes in the latest version of the document (which has moved from a
dnssec doc).   Authorisation for the dynamic update transaction has
been separated from the security of the data being updated.   That is
(as your reporter understands it) the key needed to perform an update
of data in a zone will not be the same key used to sign that data.
Only the zone key is now permitted to sig, not user keys.  Ed was asked
why this change had been made - he didn't have the answer.  This will
be explained on the list.  The new doc also now allows the use of
SIG(0) as an alternative to TSIG as a signing mechanism.  There are no
current known implementations, though it was stated that one was
planned for Bind version 9.

Donald Eastlake spoke on draft-ietf-dnssec-update2-00.txt.  RFC2137
should be considered obsolete, it is incompatible with RFC2535.  This
draft was the intended replacement for RFC2137.   That is the public
key secure update method, whereas simple-secure-update is the shared
key secure update method.   Other methods could also be defined.  It
was asked whether all these could be combined into one document.  Don
stated that he couldn't defend update2 as currently proposed, it is too
complicated.   It was also asked which method should people
implement.   The answer was that this depends, public key methods are
more general, but have higher overhead.   None of the methods have
actually been implemented yet.   Randy Bush said that for the global
internet public key was the way to go, for small clouds, shared key,
but that doesn't scale to the internet as a whole.

It was suggested that the names should be changed, so instead of
suggesting "simple" and "complex" updates, that names suggesting
public, and shared, key updates be used, to avoid loading the names.
This is to be discussed on the mailing list.

Donald Eastlake also spoke on draft-ietf-dnsind-rollover-00.txt.  This
is a mechanism for zones to deal with parent/child zones needing to be
resigned.   He solicited comments on the list on this draft, which also
deals with zones that split, or recombine.

It was asked whether in some world where .com is shared among various
administrators with different keys, might this get complex.  The
answer was yes.  It was also asked whether the request for a key to be
signed be manual?   The answer was no, that is the point of this
proposal.  Does this cause a problem with zones where the key is not to
be kept on line? There is no comment on how quickly things happen, just
that they do.  If latency might be days, servers might not want to
retain state of the requests that had been made.    Donald briefly
described the method, but suggested that discussion of the issue be
continued on the mailing list.

Edward Lewis spoke on draft-ietf-dnsind-sec-rr-00.txt.  This and
draft-ietf-dnsind-keyreferral-00.txt are related drafts.   Keyreferral
came first, sec-rr is an addition to the earlier draft.  The issues
were that it could be difficult for a parent if it had to retain keys
for all of its children, and that there was also some desire to progress
away from NXT records.   However, Ed is now convinced that the parent
doesn't need to hold keys for all children.  Don Eastlake remarked that
only keys for insecure children that cannot be updated are needed.
Also, there have been comments that the current specifications should
not be delayed more, before some implementation experience has been
gained.   For example, on NXT records, they have not yet been
implemented for anyone to really be able to say that they are
unworkable.   For now these drafts will be considered dormant.  If, at
some later stage, there appears to be a need for them, they can be
revived.

Donald Eastlake spoke on draft-ietf-dnsind-kitchen-sink-00.txt.  This
is a new proposed resource record (actually not all that new, drafts
proposing it have even around for a while, and it has a type code
assigned) to provide a mechanism for those who want to define new RR
types to hold the known universe, but who don't, or can't obtain a
specific RR type code, and otherwise tend to attempt to interpret the
contents of TXT records.   One problem with the Kitchen Sink RR (and
TXT records) is that an application seeking to use it will get all the
records returned, and then have to dig through those to find the
relevant ones.   It was asked why individual RR type codes couldn't
simply be used.   Rob Austein replied from the audience that this is
for those who won't, or can't, do that.  For example, the IANA is
unlikely to register an RR code for an RR type whose contents cannot be
divulged.   If a proposed RR is worthy of standardising, it should get
its own RR type code.  This RR is for all of the other junk.    A new
draft is to be expected within about a month of the meeting, after
which it should be pushed forward as an experimental RFC.

Peter Koch spoke on draft-ietf-dnsind-apl-rr-02.txt.   This new draft
resolves the issues that had been raised since the last meeting.  No
new issues have been raised.   Peter believes the draft is ready for a
working group last call prior to requesting the draft be advanced as a
proposed standard.

Edward Lewis again acted as a proxy for Brian Wellington, and spoke on
the draft-ietf-dnsind-dddd-01.txt draft.   Ed went through the changes
in the new version of the draft.   It seems that there is a demand for
a mechanism that can be used to (in particular) make old DCHP installed
records go away after they are no longer relevant.   However there was
little support for this particular mechanism, it is too complex.
Michael Patton proposed a method long ago, the reaction then was that
the work required wasn't justified by the benefits.   There is really
little harm in leaving the obsolete records in the DNS.  A simple way
to arrange for records to be deleted is a desirable goal, but so far,
no-one has been able to find a suitable method.   Rob Austein pointed
out that most of the mechanism proposed is for handling all of the
possible failure cases, which are unlikely to occur, and in any case,
do little harm.    It was suggested that this draft be dropped.

Robert Elz spoke very briefly on Mark Andrews' draft
draft-ietf-dnsind-verify-00.txt, and explained its purpose.  Peter Koch
spoke on draft-ietf-dnsind-local-compression-05.txt which is,
essentially, an alternative - both provide a mechanism to allow name
compression in DNS packets for future RR types which contain domain
names in their data.

The new draft of local-compression avoids an ambiguity that was in the
previous draft - it now makes compression mandatory, so every RR will
have a canonical form for the compressed RR.   Local compression should
simply work if deployed at client & server for a new RR.  On the other
hand verify requires all the DNS servers on the net to be upgraded
before it can safely be used.

It was asked which, local-compression or verify, would work better for
a new RR type that is to be deployed for only a short period.  No-one
was really in favour of proceeding with verify.

Randy Bush asked whether anyone has any pressing need for any kind of
compression inside the RR data fields of anything but the NS records of
the root zone?  No-one had any demand.  Peter Koch suggested that there
might be new RRs coming where compression might be useful.  Matt
Crawford suggested A6 records might, but probably no type of
compression will really help.

Donald Eastlake spoke on draft-ietf-dnsind-local-names-07.txt.  This
draft has been updated, but more updates are still needed.  The draft
deals with two issues, and perhaps should be split into two.  The more
controversial second part needs the TLD "local" added to the root zone
files to work.   It was asked what is the demand for this mechanism.
Don couldn't really say, but did indicate that there do seem to be some
people using it.

As a suggestion for naming local resources, it seems OK.   The local
top level domain part is more controversial.   The draft is to be
revised one more time and then group will decide what we will do with
it.

Under any other business, Donald Eastlake suggested that an IANA
considerations draft, for the DNS, was needed.   Bill Manning indicated
that he already had a task to create such a document.  Don and Bill
will work together to produce a draft of this.

The group was asked whether any had examined the new proposal for
another resource record giving location information.   The group did
not express what could be considered support for the proposal.

Robert Elz suggested that for the Washington IETF, as a trial, dnsind
(or whatever the group has turned into) drafts will be required to be
submitted to the secretariat at least two weeks prior to the
secretariat's cut off date.   That is, dnsind has an earlier
deadline.   Drafts that do not make that earlier deadline will be
considered at the meeting only if time permits (they will definitely be
at the end of the agenda, and no attempt will be made to squeeze the
agenda to make them fit).   No dissent was expressed to this.