----------------------------------------------------------------------------- dnsop WG minutes for IETF 74, San Francisco, US ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 74, San Francisco Location: Hilton San Francisco, Continental 4 Date: Tuesday, 24 March 2009 Time: 15:20 - 17:00 (UTC-8) Chairs: Rob Austein Peter Koch Minutes: John Schnizlein Jabber: xmpp:dnsop@jabber.ietf.org J-Scribe: Bruce Campbell, Benno Overeinder J-Script: http://jabber.ietf.org/logs/dnsop/2009-03-24.txt http://jabber.ietf.org/logs/dnsop/2009-03-25.txt Audio: ftp://videolab.uoregon.edu/pub/videolab/media/ietf74/ietf74-continental_4-tues-pm.mp3 [~150MB] WG URL: http://tools.ietf.org/wg/dnsop/ Material: https://datatracker.ietf.org/meeting/74/materials.html Version: $Revision: 1.3 $ ----------------------------------------------------------------------------- 1) Administrivia [ 15:24 {audio 2:34:08} ] No new IETF attendees, about 5 new to DNSOP WG - Note Well - agenda : no changes ----------------------------------------------------------------------------- 2) Status Update [ 15:29 {audio 2:39:00} ] - RFCs published RFC 5358 "Preventing Use of Recursive Nameservers in Reflector Attacks" - Internet-Drafts in RFC Editor Queue - NONE - - I-Ds at the IESG - NONE - - I-Ds in or past WGLC - draft-ietf-dnsop-reverse-mapping-considerations-06.txt post WGLC, EXPIRED, minor edits needed, to be sent to IESG - draft-ietf-dnsop-respsize-11.txt EXPIRED - draft-ietf-dnsop-default-local-zones-08.txt write-up in progress - draft-ietf-dnsop-as112-under-attack-help-help-02.txt passed WG last call - minor edits needed write-up in progress - draft-ietf-dnsop-name-server-management-reqs-02.txt WGLC ends one week after IETF 5 reviewer threshold not met on list 6 people in the room other than design team members said they read and want it to proceed, chairs asked them to submit their position to the list. Wes: edits are minor at this point ----------------------------------------------------------------------------- 3) WG Charter [ 15:33 {audio 2:43:30} ] [chairs][ 0 min][15:30] - no news, skipped - ----------------------------------------------------------------------------- 4) Active Drafts [ 15:33 {audio 2:43:38} ] [chairs][25 min][15:30] 4.0) draft-ietf-dnsop-resolver-priming-01.txt EXPIRED, incorporation of feedback pending expect an update in May draft-ietf-dnsop-as112-ops-02.txt revived, awaiting WGLC 4.1) draft-ietf-dnsop-dnssec-trust-anchor-03.txt Awaiting WGLC Dmitry Burkov: required hash can limit the usefulness of this Olaf: clarification: the hash mentioned is for the DS RR, does not imply so for the signing algorithm; the draft should not require use of any particular algorithm and key - agree and don't think the text requires it. Dmitry Burkov: prefer that it deprecate SHA-1 but not specify a recommended algorithm 4.2) draft-ietf-dnsop-rfc4641bis-01.txt [ 15:41 {audio 2:51:05} ] [Olaf Kolkman] Version 00 just captures RFC and errata RFC4641 is informational because of lack of practice, should the -bis be a BCP or informational? removed table of key sizes and simplified the recommendation: use 1024 bits, 2048 if concerned about security Paul Hoffman: starting Jan 2011, NIST requires 2048 bits - will be presented in SAAG - also has to be SHA-2, US Govt will no longer be allowed to use RSA1024 or SHA-1 differentiation between KSK as a trust anchor (third party reliance) or just a DS pointed at it. key effectivity periods: KSK effectivity 2 decades or 12 months (to exercise) but possible stability risk. guidance needed added key algorithm rollover: essentially double signature rollover, with sigs for each key (non)cooperative registrars (zone maintainer) - picture looks dim in the case of long TTLs - looking for Antoin Verschuuren: only way to go: exchange private keys (will not happen), disagree that the problem is there without DNSSEC - long TTL in that case keeps old data in caches; may have to go through insecure Ed Lewis: last sentence on slide may be accurate because of serial number mismatch. Re: key lengths, recommend not saying "do this" but instead describe tradeoffs. Olaf: want crypto specialists to confirm that key lengths and effectivity periods are reasonable. Paul Hoffman: say how much longer the longer key takes to sign Mark Andrews: missing discussion on whether to use NSEC or NSEC3 Olaf: please send to the list with what recommendations should be. Olaf: there are other than these issues on the issue-tracker Ondrej Sury: want longer rollover times described also, want to wait until root is signed, so maybe longer than a year Jaap: plan in the European Commission to write a document like this, telling operators how to run DNSSEC Olaf: later presentation on timing, those drafts should cross reference each other; want to first address the open issues; please send text to the list ASAP ----------------------------------------------------------------------------- 5) Current & New Topics [ 16:02 {audio 3:12:36} ] 5.1) draft-morris-dnsop-dnssec-key-timing-00.txt [Johan Ihren] Olaf: How to deal with the 4641bis overlap? Johan: there is a need to coordinate these drafts Olaf: minimum values for the timings? Johan: it depends - you don't get a number; you get an equation. back to Johan's preso deal only with key timing - not including signing because already complicated enough signing side still to be worked out asking WG to take on as a WG item Wes Hardaker: applaud the work - suggest that you structure the document to suit the needs of people who are not very familiar with DNSSEC. Johan: we have haggled over this - not intended for DNSSEC zone operators, but for software implementers. Responding to confusion in terms of discussion. language barrier and confusion in terminology Wes: Missing 5011 considerations Johan: we deliberately only deal with state transitions and avoided dealing with distributing trust anchors. Antoin: helpful for making policy, concerned about relation to 4641bis Evan Hunt: suggest terminology coordination also with RFC 5011 Johan: the terminology is important, 5011 cannot change, but let's see how to improve Olaf: operational practices has the same issue. Chairs postpone decision for adoption due to overlap with 4641bis. WG is asked "Do we at least want to work on this?" Humm in favor of support, silence for opposition ACTION: Chairs to coordinate with editors of this and 4641bis to describe overlap and interaction and bring appropriate question to the WG 5.2) draft-liman-tld-names-00.txt [ 16:27 {audio 3:37:00} ] [Lars-Johan Liman] Draft was written on request from the DNS directorate Intent to make clear what octet values are allowed in the label closest to the DNS root. Perspective of the technical community. Does anyone disagree label length restriction apply to the root? [room was silent] Hostnames (RFC 952) specification does NOT apply to TLD labels as there is no address or MX RR for the TLD itself; anyone oppose? Ondrej Sury: 2.3.1 of RFC 1035 specifies the label spec Liman: it's a recommendation there, doesn't say "must" Mark Andrews: with TLDs you don't want anything wider than RFC952 Liman: want to ignore RFC952, have something else as a basis Mark: RFC952 is modified by RFC1123 Joe Abley: third bullet; absence of A/AAAA isn't enough for an indicator Ed Lewis: concerned to rule out "host" at the TLD label; should not do policy here Liman: inclined to follow Andrew Sullivan's recommendation from the mailing list: this is basically policy, but has been used as basis in other specs; thereby has become a technical specification over the years Francis Dupont: suggests to contact the author of RFC 1123 for clarification of the intentions of the wording Liman: proposed way forward: 1123 is intentional [projector died] open up as little as possible to accomodate IDN A-labels would like to remove chars from the current version to be RFC1123 plus what it needs for IDNs Mark Andrews: good way forward Andrew Sullivan: we can consult with original 1123 contributors, but different people have interpreted thios piece of text regardless of initial intentions; is it ambiguous and can we clarify? Ed Lewis: concerned about setting policy vs recording good choices "Is the purpose to specify what we think should be TLD names or are these safe for applications?" Liman: Aiming at technically safe names, no policy if possible Peter (chair): this was prompted because IDN TLDs' "xn--" is in obvious conflict with "will be alphabetic" The draft will continue as an individual submission until further notice. Discussion is encouraged to continue on the DNSOP WG mailing list. Chairs to coordinate with dnsext chairs. ----------------------------------------------------------------------------- 6) Other (non WG) Internet-Drafts [ 16:44 {audio 3:54:22} ] - NONE - ----------------------------------------------------------------------------- 7) I/O with other WGs [ 16:44 {audio 3:54:22} ] behave) draft-bagnulo-behave-dns64-02.txt [Andrew Sullivan] Comments still needed especially on the case where DO=1 and CD=0; What should a validating resolver do? Would setting the AD bit break anything? Confirming feedback: Is it OK to push translated A into the additional section instead of answer section just as a debugging hint? The draft is now a BEHAVE WG item - more "DNS eyes" would be good. hiprg) draft-ponomarev-hip-hit2ip-03.txt [ 16:47 {audio 3:57:00} ] [Oleg Ponomarev] Input from the HIP research group Olaf: why use the DNS for such a flat namespace? Could use any database mechanism and you don't exploit any DNS advantages. Oleg: Don't want to construct new protocol or deploy new servers. Peter Koch: given the state of our own reverse mapping draft, is there consensus in HIP that this is needed? Oleg: like to have it for access control lists and logfiles Peter: access control sets off alarm bells. Makes more sense with HIP than with IP addresses? Oleg: yes, it's secure in a way Bruce Campbell: do you intend this as a per entity basis or global? Oleg: possibly global Olaf: Have you given consideration to the registry business going to scale for this? Oleg: self generated, host is able to prove its identity, so registration is easy Chairs point to the "Multiple Interfaces" (mif) BOF to meet Thursday, 1510 - 1610 and the 6man WG, Tuesday, 1710-1810, which has RFC 3484bis, draft-chown-addr-select-considerations-02.txt on its agenda. Early DNS review is encouraged. ----------------------------------------------------------------------------- 8) A.O.B. [ 16:58 {audio 4:08:14} ] 8.0) DNSSEC, IXFR and redundant signers [Joe Gersch] How to delete (slightly different) RRSIGs when backup signer kicks in? Extend protocol to allow update to check for other fields while deleting RRSIG? Any support for this IXFR extension? Rob: need to take this to the list, proposed protocol change suggests this is for "namedroppers" (DNSEXT) 8.1) DNS Reverse for IPv6 [Alain Durand] v6 operators looking into reverse DNS, especially for address space given to home users, need feedback Alain is collecting feedback in his personal mailbox but will send a reminder to teh DNSOP list 8.2) Trust Anchor Repository Bar BOF [Russ Mundy] Announcement: Bar BoF tomorrow evening about TARs ----------------------------------------------------------------------------- Z) Meeting closed [ 17:05 {audio 4:15:26} ] -----------------------------------------------------------------------------