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 
withthis 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