Dear WG,
the meeting minutes for our session at the IETF74 in San Francisco have been
posted to <http://www.ietf.org/proceedings/09mar/minutes/dnsop.txt>.
A copy is also attached below. Thanks to John, Benno and Bruce for scribing.
All typos and delays are mine.
-Peter
-----------------------------------------------------------------------------
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 <[email protected]> <[email protected]>
Peter Koch <[email protected]> <[email protected]>
Minutes: John Schnizlein
Jabber: xmpp:[email protected]
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} ]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-0.pdf>
No new IETF attendees, about 5 new to DNSOP WG
- Note Well
- agenda : <http://www.ietf.org/proceedings/09mar/agenda/dnsop.txt>
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]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-1.pdf>
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]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-2.pdf>
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]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-3.pdf>
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]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-4.pdf>
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]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-5.pdf>
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]
<http://www.ietf.org/proceedings/09mar/slides/dnsop-6.pdf>
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} ]
-----------------------------------------------------------------------------
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
