Subject: DNSEXT IETF-57 WG minutes (draft)

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 13 Aug 2003 17:45:04 -0400

Send in comments before I submit these:
X-UIDL: 2P?"!&B~!!R&-!!4)I"!

IETF 57 - Vienna, Austria
DNSEXT Minutes

Olafur thanked Randy Bush for his long service as WG chair and welcomed
Olaf  Kolkman as the new co-chair.

Charter
   Text on list
   Focus on DNSSEC docs and its dependencies
     Process in the coming 2-3 months
   Important to have the core documents reviewed by more people
   Once DNSSEC done, advance docs that are in PS status to DS
     List put out of docs and will be used to build milestones

Update from AD
   OPT-IN to Informational RFC, instead of Experimental
   Question on why INFO vs. EXP, answer was WG didn't accept, but there
   is need to document this for history.
   Since code exists and its sort-of half-baked, and people may want to
   "play" with it, it should be EXP.
   INFO: here's the endpoint, we're not putting on ST, EXP: go play with
   this and come back
   More words needed as to why decision was made, chairs to draft
   boilerplate text for document.

IPSECKEY
   WG defining RR to store IPSEC Keys for Opportunistic Encryption,
   Will be most likely defining new IANA registry to key types for IPSECKEY
   if you think that's not a good idea, speak up on IPSECKEY WG list

LLMNR
   18 Issues raised and 17 resolved
   WG Last Call asked for in email

DNSSEC Editors Report
   Want more input on the drafts from the list
   4 drafts, 1 is threats, other 3 are BIS core drafts
   Open Issues
     Unresolved questions posted to list with some still unresolved
     Type code rollover
       draft may be revised to create new registry for new types
       not sure if that's necessary
       motivation came from wanting to keep KEY/SIG for SIG(0) uses
       new registry will allow DNSKEY/RRSIG to drop cruft from current
       registry
       are there any issues with having all of these new registries?
         IANA might be concerned about it due to the number of registries
     DS and Wildcard draft
       DS is in IESG last call
       Waiting on wildcard clarify

DNSSEC-editors Question 6: should caches retain failed
     verifications (rephrase: how to interpret CD bit)
   Should caches try to reduce the number of identical queries going out
   by caching failed verification responses?
   CD bit just an optimization (a way to tell recursive nameserver you
   don't have to check SIGs if you don't want to)
   should CD be: I'm going to check SIGs, stay out of my way.
   one interpretation of RFC2535 is to say if verification fails, the
   recursive nameserver must drop the data
   SERVFAIL is not a good response when DNSSEC fails, need way to tell
   application what failed, why, where to go
   threat: if recursive nameserver's clock is wrong, but application host's
     clock is right, indirect DOS, which is unacceptable
   any other thoughts on CD bit, discuss on list

Wildcard Clarification
   draft-ietf-dnsext-wcard-clarify-00.txt
   Since March
     Proof to formalize the notion/definition of closest encloser
   Proposals:
     Split document into 2 pieces
       Pre-DNSSEC and DNSSEC parts
       document contains 1034 updates and DNSSEC updates
       chapters 1-5, and appendix Appendix A update 1034
       chapters 6,7 update/clarify DNSSEC

   Clarifying 1034 (Pre-DNSSEC)
     Existence statement
     Impact of Wild Card domain name owning particular RRs (CNAME, NS,
     DNAME, SOA)
     Related to CNAME-change to 4.3.2-3.c

   DNSSEC Part
     Rules for NXT's as part of authenticated denial as it relates to
     wild cards
     Fix up the proof, Bob would like someone with more formal math
     knowledge to check over proof
     Add "recipe" resulting from proof for implementor
     Where does this "part" go?

   Existence
     1034 words too vague

   CNAMEs
     what happens to CNAMES owned by wild card names?
     according to 4.3.2 its okay

   NSs
     MAY? SHOULD? MUST? reject zone on load?
       no - don't say anything on wild cards owning NSs
   DNAMEs
     DNAME has problems, not specifically related to wild cards
   SOAs
     doesn't need discussion...

   Q: for these things that are deemed non-scenical, are implementor
   going to be directed to give horrible errors?
   it might not make sense to bar these at this time

   CNAME: not sure there's no problem
   text in 1034 is advisory, not a step-by-step procedure, different
   implementor might do steps in different order, it might be good to
   write the steps into a protocol document

   Q: is this necessary for the Pre-DNSSEC stuff? DNSSEC stuff is
   necessary
   Yes, the issue is 2 different servers doing it differently (a master
   and a slave)

   Change to 4.3.2-3.c
     add explicit text for CNAME chasing

   Actions
     Split
     Existence
     Add text to clarify "* NS"
     Modify step 3.c of 4.3.2 in 1034
     Move DNSSEC text to own document
     Add "recipe" resulting from proof, edit proof

   Q: should these DNSSEC bits be put into a separate doc and progressed
   and then added to BIS documents by editors
   Not sure, depends on what the change is

   Comment: If we're going to mess with 4.3.2-3.c, then let's go ahead
   and make  all the necessary changes to the algorithm change it from
   advisory  to a nailed-down set of steps

   Chair: move DNSSEC parts to dnssec-BIS documents, only update 1034
   in your document.

TSIG Interoperabilty Testing Results
   Goal to move RFC2845 from PS to DS
   Must do interop tests with at least 2 independent implementations
   Categories:
     Client-Server (C-S)
     Slave-Master (S-M)
     Client-Forwarder-Server (C-F-S)
   Preliminary report at
     http://w6.nic.fr/RFC2845/
     Full or partial interoperabilty found depending on category of
     tests (C-S, S-M, C-F-S)

   Q: were "other" clients (dhcpd doing TSIG dynups) tested?
   no

   Q: was any feedback given back to implementor on error messages due
   to error conditions?
   don't think so

Secure Notify
   (diagrams showing zone relationships and steps in SEP key
   rollover)

   Goals
     automate parent-child interactions
     derived trust from established trust anchor (e.g. parent DS record)
     change parent-child interactions from OPS issue to Protocol issue
     Remove human from loop for routine actions
   Approach
     use NOTIFY from child to signal changes in
       Apex SEP KEY RRs
       NS records
       Glue? (maybe, maybe not)
     Secure NOTIFY by
       SIG(0) from SEP KEY
       chains to parent's DS
   Issues
     Type code change removes SIG(0) for SEP KEY (SEP DNSKEY)
       Will be resolved by TSIG(0) document (proposed)

   Q: Does this require that the SEP bit be set?
   yes
   that doc said that that bit would be info only, not used for protocol
   then why put it in the protocol? it should be used
   really applies to verification protocol - shouldn't be used there, but
   uses like this are okay

   Q: Use a key that belongs to the child to talk to the registry?
   no, not the registry, but to the master
   this changes the way registries interact with masters
   don't think so, parent may choose to not accept this packet, doesn't
   affect how registries talk to masters

   Chair: should separate DS bits from NS bits, parent zone has no way to
   check whether child zone is properly configured, updating NS could be
   harmful isn't it local policy to do that?
   lots of checks must be done to protect DNS from bad operators

   Comment: worried about adding new features to NOTIFY, designed along
   SNMP-TRAP theory: hint that now would be a good time to pull
   NOTIFY is pre-DNSSEC, since NOTIFY can be signed, data can be included
   preference to use UPDATE rather than NOTIFY
   UPDATE semantics don't cleanly fit this model

   Comment: could be really, really useful in the reverse tree
   universities have delegated entire /24s to departments who run their
   own nameservers policy would fit well automatic tunnel brokers using
   reverse map are also a good fit

   Q: what can i do with this, that i can't do with dynamic update?
   DS doesn't belong to child, DS is just a hash of my key
   technically, content of DS belongs to child, but signature of DS
   belongs to parent

   Comment: another key change document that uses only 1 DS at a time

   Comment: no shortage of opcodes, let's define a new opcode for it
   don't want to write yet another draft

   Comment: using dynamic update does remove one timing dependency

   Mike: trust anchor sits in SEP key, could you expand on that in the doc

   Q: is work in this area important for this WG?

   Chair: this doc makes changes to the protocol, must be DNSEXT, but it
   makes assumptions based on ops possibility all of this work gets
   dumped into a completely new WG

   Q: this WG or another WG?
   DNSEXT can take this work on if it doesn't go anywhere else
   not a prereq for the base docs

   Comment: cautious about changing the protocol since other protocol changes
   are being made for the DNSSEC stuff not sure if it is a good general
   solution

   Chair: key management issues are a major deployability issue for DNSSEC
   this needs to be looked at really hard
   wants the key management "pieces" to work on their own

   Chair: even with this doc in DNSEXT and changing the protocol,
   addressing ops issues  maybe there are other solutions that address
   the same problem

   Chair: number of requirements assumptions that need to be fleshed out
   may be a couple of good, effective ways to solve it
   there are multiple requirements with multiple solutions

   Comment: come to DNSOP and discuss things there

Final Comment
There are now two tall Vikings running DNSEXT and if no one reads the
documents, we will be using our Viking knowledge 

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