DNSEXT66 minutes

[Ólafur Guðmundsson /DNSEXT co-chair <[e-mail]>]

Minutes of DNSEXT working group, IETF 66
July 10th 2006, Afternoon Session I
Note takers: Marcos Sanz and Robert Martin-Legene

Agenda and presentations available at
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66

Administrivia: Previous minutes are approved. Draft agenda is approved.

PRESENTATION 1
- "Document status" by O. Gudmundsson
New RFCs since last meeting are 4389, 4470 and 4509. A review of the
status of current I-Ds follows:
  draft-ietf-dnsext-dns-name-p-s-02 is in AUTH48 state.
  draft-ietf-dnsext-wcard-clarify-11 and 
draft-ietf-dnsext-dhcid-rr-13 are in the RFC-Editor queue.
  draft-ietf-dnsext-nsid-02 is in wg LC.
  draft-ietf-dnsext-mdns-45 is in publication requested as informational.
  draft-ietf-dnsext-dnssec-experiments-03 is in publication requested 
as experimental.
  draft-ietf-dnsext-opt-in-09 is in publication requested as experimental.
  draft-ietf-rfc2536bis-dsa-06 needs more reviewers. LC is completed 
and is waiting for chair decision.
  draft-ietf-rfc2539bis-dhk-06 needs more reviewers, too.
  draft-ietf-dnsext-dnssec-trans-04 has entered LC.

There is ongoing work with the following drafts:
-	Draft-ietf-dnsext-dnssec-bis-updates-03
-	Draft-ietf-dnsext-2929bis-03, hopefully going soon to wg LC
-	Draft-ietf-dnsext-signed-nonexistence-requirements-03,
		hopefully going soon to wg LC
-	Draft-ietf-dnsext-nsec3-06, aiming at having it completed this year.
And the following drafts are in holding state:
  - Draft-ietf-dnsext-rsasha256-00
  - Draft-ietf-dnsext-ecc-key-09, needing simplifications because of
				  interoperabilty issues.

DISCUSSION 1
No discussion

PRESENTATION 2
- "NSEC3 status and issues" by D. Blacka
http://www.nsec3.org contains an issue tracker about NSEC3 (with
history and rationale) and other useful information. NSEC3 is an NSEC
RR alternative that prevents zone enumeration by hashing domain names
and at the same time is an optional optimization for
delegation-centric zones called opt-out. Current version of the draft
is Draft-ietf-dnsext-nsec3-06.

There was a side meeting yesterday and there is a proposed NSEC3
workshop (tentative date is September). Purpose of the last Frankfurt
workshop (8th-10th May) was interoperabilty testing of signing,
serving and validation, and no major issues found. A semi-permanent
test environment was set up. Notes from the workshop are in the NSEC3
website, and provided valuable input for the version -06 of the
draft. Some tests that still need to be done are: NSEC to NSEC3
rollover and vice versa, signalling mechanisms, traversing down
various combinations of NSEC and NSEC3 with and without opt-out and
spoofing tests with wildcards and opt-out.

Changes from the -05 to -06 draft version are: a hash length field was
added to RDATA, a new section on signalling and a new section on
dynamic update were added to the document, and some text on the
handling of unknown NSEC3 hash algorithms was added, too. The examples
were updated and completed. In the new version of the draft responses
are now required to use NSEC3 with all the same parameters, because
otherwise it becomes too cumbersome for implementations.

Things still known to be missing in the draft are text on
transitioning and on the following open issues, which didn't make
it to -06 mainly because of time constraints.

Open issues are (numbering according to the issue tracker in the NSEC3
website):
#8 "signalling": about interoperabilty with 4035-based
resolvers. NSEC3-signed zones should be treated by them as insecure
and, in order to achieve this, the new draft describes the use of
unknown signing algorithms. There was an alternative solution and this
one is not set in stone, but this is what has been implemented.

#9 "iterations upper bound": the current document sets an upper
bound based on RSA signing times. Resolvers may treat NSEC3 RRs with
too many iterations as bogus. Open questions are: Should be based on
verification times instead? Resolvers should treat as insecure
instead? How does the upper bound change over time?

#11 "queries for NSEC3 owner names" (aka the "paradox problem"): Three
different approaches exist that have been described in past versions
of the draft. Should these queries work? Some people don't feel it to
be very important, but the correct behavior must be defined.

#18 "Signalling complete NSEC3 chains": So that authoritative servers
  (primary and secondary) can determine the NSEC3 parameters. The
  current document requires finding the NSEC3 for the zone apex, but
  there are three other proposals: a) to introduce a new zone apex RR
  (e.g. NSEC3-PARAM), b) to reuse NSEC3 at zone apex, and c) a special
  case the zone apex NSEC3. Preferred solution at the moment is
  introducing a new zone apex RR.

#22 "Separating NSEC3 from DS algorithms": NSEC3 currently reuses the
  DS hash algorithm registry, but the desired NSEC3 hash properties
  might not be exactly the same as for DS, so maybe a new registry
  could be needed.

DISCUSSION 2
No discussion

PRESENTATION 3
- "Automated DNSSEC trust anchor management" by O. Kolkman
The trust anchor update requirements in DNSSEC are documented in
dnsext-rollover-requirements-02.
The initial set of proposals includes:
draft-ietf-dnsext-trustupdate-threshold,
draft-ietf-dnsext-trustupdate-timers,
draft-laurie-dnssec-key-distribution, draft-moreau-dnsext-takrem-dns,
draft-weiler-dnssec-dlv and P. Vixie's "old-signs-new", which is not a
I-D (yet).

The key-rollover scope would be replacing trust anchors, based on
existing scope, and would not include using a multitude of islands of
trust.
Reviewers of these documents seem to converge to thresholds and timers
solutions, or sometimes threshold with modifications (that is, mainly
the wg documents). timers have properties that are not available in
threshold and reviewers seem to like some of these in threshold,
too. Others prefer the extreme of threshold with minimal
parameters. Question to the floor: Timers seems to be a complete
document, what is the benefit of further refining threshold?

DISCUSSION 3
J. Ihren asks what the IPR status on threshold and timers is. The
decision about IPR is, however, felt to be out of scope for this
wg. The personal interpretation of the chairs is that no actual IPR
exists (only a claim about SSL), but implementors should take
decisions regarding IPR by themselves.

B. Manning explains that the patent on threshold and timers is valid
only in Israel (tentatively extended to Canada and Europe, but it was
withdrawn). For him, timers-document is ready and sufficient, but
operational considerations he sees in there should be widely
reviewed.

There is consensus in the room to not consider the DLV solution in
this concrete discussion.

R. Austein admits that DLV is only a consolidation of trust anchors,
not a rollover solution.
The feeling in the room about accepting B. Laurie's document to be a
wg item is not conclusive.

M. St. Johns states that some text on trust anchor deletion must be
included in the timers document, thus it's not complete yet. He feels
that timers are weird, but the necessary result of retrofitting an
active protocol into a passive protocol. An alternative solution could
be to do the rollover off-band with another protocol, but then issues
could arise with firewalls (e.g. one protocol doesn't get blocked, but
the other one does).

B. Manning points out that, both with timers and thresholds, if you
are offline long enough, you might lose the ability to synchronize.

R. Austein expresses his preference for the timers solution.

W. Hardaker states that timers are architecturally sounder and a
self-contained solution. The revoke bit is good in his opinion.

M. Larson states that he's fine with both solutions, however
expresses concerns because the wire protocol has to change the revoke
bit for timers.

A. Sullivan states that the threshold is easier to grasp for the
people than timers.

S. Weiler expresses his preference for threshold.

Consensus of the room is to go forward concentrating in timers. When
the document is updated by the editor (by the end of the week), it
will go for LC.

PRESENTATION 4
- "RFC 2627bis, DNAME rewrite for clarity" by M. Larson and W. Wijngaards
DNAME has been in the charter of the wg since 2002. RFC 2672 has
shortcomings, omissions and could be clearer. Protocol will not be
changed in this rewrite, which is not intended to create a DNAME2. The
process will be to first create an ID listing issues with 2672, then
gather WG feedback to create solutions, and later create 2627bis.

First cut of issues is (more input wished):
* 2672 defers signalling. Non-EDNS and EDNS0 are presumed to be
non-DNAME-capable, which is actually not the case. With a signalling
mechanism, the response to DNAME-capable client could omit CNAME
synthesis and compress DNAME data.

* 2672 prohibits compression in DNAME RDATA pending signalling, but
* this could be done if the client were DNAME-capable.

* 2672 always sends DNAME. Is this making like difficult to older
   resolvers? Would it break things with wider deployment. Signalling
   would help to deal with this.

* 2672 requires synthesized CNAME to have zero TTL. Could it be
* possible to use DNAME-TTL for synthesized CNAMES so as to allow
* caching?

* 2672 is not clear about wildcard DNAME. 2672 is clear that wildcard
   synthesis doesn't apply to DNAME, because DNAME substitution occurs
   before wildcard expansion, but draft-ietf-dnsext-wcard-clarify
   disagrees, so this issue should be expanded and clarified.

* 2672 is silent on whether recursive nameservers can synthesize
   CNAMEs from cached DNAMEs for non-DNAME-capable stub resolvers. This
   must be clarified.

DISCUSSION 4
R. Austein corrects the last issue by stating that it is actually
worse: the draft doesn't talk about recursive nameservers, but
about "servers" in general. Then he suggests to consider DNSSEC
when updating the document

PRESENTATION 5
- "2929bis" by D. Eastlake 3rd
At the Dallas meeting there were requests for more explicit and
details guidance, so these have been added in section 3.1.3 of version
-03. Suggestion to go to LC with -03, considering pending comments by P. Koch.

DISCUSSION 5
R. Austein questions the necessity of this doc the chairs restate its
necessity.
Thomas Narten pleads for the necessity of an RFC, a draft is not enough.

PRESENTATION 6
- "DNS cookies" by D. Eastlake 3rd (Draft-eastlake-dnsext-cookies-00)
This DNS cookies provide weak authentication of queries and responses
and can be viewed as a weak version of TSIG, but with the benefit that
they require no setup or configuration. They are intended to reduce
forged source IP address in traffic amplification DOS attacks and
recursive server workload DOS attacks, together with cache poisoning.

To sum it up, the cookie RR is a meta-RR in the additional information
section including a resolver cookie and a server cookie in the
RDATA. The details of the functioning are described in the draft.

The complexities of this solution have to do with bad guy resolver
behind a NAT (who can get server cookie and attack other resolvers
behind the NAT) and with anycast servers (who would need to use the
same server secret or assure that queries from the same resolver go to
the same server).

DISCUSSION 6
R. Martin-Legene expresses sympathy for the idea, but points out that
    the solution would be to fix UDP.
P. Koch  points out that spoofing must be stopped somewhere else
   (cf. BCP38) and states that DNSSEC fixes cache-poisoning.
M. Andrews predicts that this will increase resolution times, so it
   should be done an EDNS option, if at all.

The chairs conclude that this is not a topic of the wg at this point,
and will wait to hear feedback from the operational community, because
it addresses an operational problem.

PRESENTATION 7
- draft-koch-unsolicited-queries-00 by P. Koch
P. Koch reminds that the DNSOPS wg is currently dealing with the
amplification attack and that there is an ID about it:
     draft-ietf-dnsop-reflectors-are-evil-01.
Then announces that there is an I-D about identifying and responding
to unsolicited queries and asks for review of it:
   draft-koch-dns-unsolicited-queries-00.

DISCUSSION 7
No discussion

PRESENTATION 8
- "andrews-dnsext-soa-discovery-01" by M. Andrews
This draft is about discovering zone cuts without causing negative
entries to be recorded in caches. The author asks about going LC with
the document.

DISCUSSION 8
Apparently, few people have read it. Chairs will ask people in the
mailing list to read it and depending on feedback, it will be
adopted.
P. Koch states that the document seems useful, but at the same time
    potentially dangerous because of playing games with the namespace.
R. Austein points out that those mechanisms of discovery could be
    useful for dynamic updates.

PRESENTATION 9
- "Update on wg milestones" by O. Kolkman
The proposal for the update of the wg milestones has been posted to
the mailing list. Please read and comment.

Adjourn.


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