----------------------------------------------------------------------------- dnsop WG minutes for IETF 75, Stockholm, SE ----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 75, Stockholm Location: Stockholm City Conference Centre, "Small Stage" Date: Monday, 27 July 2009 Time: 09:00 - 11:30 (UTC+2) Chairs: Rob Austein [Peter Koch ] Jaap Akkerhuis Minutes: Jim Galvin Jabber: xmpp:dnsop@jabber.ietf.org J-Scribe: Andrew Sullivan J-Script: http://jabber.ietf.org/logs/dnsop/2009-07-27.txt Audio: ftp://videolab.uoregon.edu/pub/videolab/video/ietf75/ietf75-mon-smallstage-am.mp3 [~20 MB] WG URL: http://tools.ietf.org/wg/dnsop/ Material: https://datatracker.ietf.org/meeting/75/materials.html ----------------------------------------------------------------------------- Agenda: 1) Administrivia [chairs][ 5 min][09:00] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min][09:05] 3) Active Drafts [chairs][ 5 min][09:10] 3.1) draft-morris-dnsop-dnssec-key-timing-00.txt [Johan Ihren][ 5 min][09:10] 4) Current & New Topics [chairs][ 5 min][09:15] 4.1) draft-wijngaards-dnsop-trust-history-00.txt [Wouter Wijngaards][15 min][09:15] 4.2) draft-livingood-dns-redirect-00.txt [Jason Livingood][40 min][09:30] 4.3) draft-ljunggren-dps-framework-00.txt [Anne-Marie Eklund-Lowinder]][20 min][10:10] 4.4) draft-howard-isp-ip6rdns-00.txt [Alain Durand][15 min][10:30] 5) Other (non WG) Internet-Drafts [10:45] 6) I/O with other WGs 7) A.O.B. [N.N.][10 min][11:20] {please identify issues in advance} ----------------------------------------------------------------------------- 1) Administrivia Rob apologizes for being disorganized but we are not taking any prisoners. 2) Status Update 3) Active Drafts [chairs][ 5 min][09:10] 3.1) draft-morris-dnsop-dnssec-key-timing-00.txt [Johan Ihren][ 5 min][09:10] Johan Ihren draft-morris-dnsop-dnssec-key-timing-00 - management and handling of 5011 revoke status to be included - still working on making the document more readable - still need to work on interactions with 4641bis but expect resolution soon - will have new draft for Hiroshima and we can move forward from there 4) Current & New Topics [chairs][ 5 min][09:15] 4.1) draft-wijngaards-dnsop-trust-history-00.txt [Wouter Wijngaards][15 min][09:15] Wouter Wijngaards - asking for adoption of his draft - plan is to support end-users with local validators Steve Crocker - how do developers test whether this works? Wouter - Configure with backdated test chains. Steve continues by raising scaling issues of coming online and testing that everything works. Part of the issue is that these algorithms are used infrequently and the system needs to allow configurations that permit testing in a reasonable time frame, e.g., consider being able to roll keys every second. Johan Ihren - what is the relationship to 5011? Wouter - Could be complementary or a replacement. This issue is mentioned in the document Bill Manning - Supportive of the draft because it is a more general purpose mechanism for how to re-sync UNKNOWN - what if you lose your key and have no starting point? Wouter - as with 5011 you can not continue chain of trust. Olaf Kolkman - some have suggested that trust anchors should be maintained by the OS, so why do this? Wouter - That is fine. this is certainly not the only way to do it, just an alternative. Roy Arends - A few years ago I replaced by 512 bit key (from 10 years ago) with a 1024 bit key. The 512 bit key has been broken. Can you please explain more about your leap of faith argument? Wouter - A "leap of faith" is just one of your strategies but we will try to say more. Rob Austein - Why do you see this as a DNSOP document versus a DNSEXT document? Wouter - It is about maintaining a configuration. Rob - The chairs will huddle and decide where to put it. Rob does the usual query for working group support and finds 8-10 hands of people willing to review the document. Given the support we skip taking names and agree the document will be a working group document, either here or in DNSEXT as determined by the Chairs later. 4.2) draft-livingood-dns-redirect-00.txt [Jason Livingood][40 min][09:30] Jason Livingood - please keep an open mind; believe in transparency of what operators do - very interested in feedback regardless of your point of view Several comments and reminders that "the web is not the Internet" and that this is completely incompatible with DNSSEC. All of this is consistent with what has been discussed on the mailing list. More information can be found in the Jabber log. Rob Austein (hatless) - Could you please more about the motivation for why this should be done. Chris Morrow - Objects to codifying this insofar as it is not in the best interests of the network. Rob Austein - There are commonly two directions for documents like this. One is "if you are going to do this here is how." Two, "here is a technical description of what people are doing and here are the tradeoffs." Olaf Kolkman - FYI, there is a framework for this in an IAB draft. Antoin Verschuren - If this is just for redirecting web "things" then this draft does not belong in DNSOP. Jason - We will say more about the various ways in which this can be done to make this clear. Wes Hardaker - I would like to see more description of the reasons why this should not be done. Mike Graff - My concern is that there is nothing in the draft about what happens if you are not a web browser. Vijay Gill - Concerned about stamp of approval by IETF. Rob Austein - We could write a document that concludes this is bad but I do believe we need to get cost issues included for that to be sensible. Web proxies are one potential solution but they are costly to run. Mandated redirects are partly about reducing help desk calls but these more analysis. Jason - Web proxies have both scalability and privacy issues, e.g., law enforcement would be interested in log files as soon they figure out that information is available. Mark Andrews - Big concern about NXDOMAIN redirect, Internet is not just Web. Doug Otis - We had a project a couple years that explored using this to identify traffic that suggested a web site had been compromised. We were able to watch and see attacks occurring. However we had to abandon the project because we realized we just could not support it. Also the browser is where the vulnerability exists and this does not address that "real" problem. Glenn Kowak - Just out of curiosity, is there any ISP that has a contract that puts "no redirect" in contracts? UNKNOWN - there are ISPs that have something similar in their contracts, e.g., if you get a static IP address then you are often eligible for additional constraints or requirements. Bill Manning - what you do in the privacy of your own AS is your own business, but once what you do affects me, and I'm not one of your customers, I do not understand Chris Morrow - if you are inside an ISP you can not be fully informed. Perhaps this will work in some environments, e.g., an enterprise, but this can not be made to work in general. There are just too many applications and we do not about all the interactions. Rob Austein - Rather than ask if this should be a working group draft, let me ask if anyone objects to Jason continuing to work on the draft and bringing it to this group? Group consensus to continue. 4.3) draft-ljunggren-dps-framework-00.txt [Anne-Marie Eklund-Lowinder]][20 min][10:10] Anne-Marie Eklund-Lowinder Fredrik Ljunggren Roy Arends - Very supportive of the work. It would be good for the working group to accept this document. Ondrey - Agree this would be a good document for the working group to accept. Mark Andrews - Agree it would be good for end-users to have a standardized way to establish trust. Rob Austein - Asking the usual question regarding interest, there is consensus we have it. We will wait for the next time to consider adopting this as a working group draft. Anne-Marie - We expect to have the next version of the draft by the end of September. 4.4) draft-howard-isp-ip6rdns-00.txt [Alain Durand][15 min][10:30] Alain, - asking if this document can be adoped by the working group Several comments and suggestions that agree that providing reverse lookups is still generally good but perhaps we should consider relaxing that a bit and documenting when it is okay not to provide reverse information. Andrew Sullivan reminds us there was a document in our past that discussed this issue but it died in process. We never could come to agreement. Rob Austein - original proposal is that it is not the ISPs problem if the application screws up. What I sense is that the objections to this document are all coming at this from a different position. Rob - asking the group if there is anyone that believes an ISP should be required to respond to all queries about an address that is in use? No one in the room agreed. Rob - asking if the group agrees this should be a work item (as opposed to a working group document)? There were 5 hands. -----------------------------------------------------------------------------