[IETF51] dnssec

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

	just a memorandum i took during the meeting.

	sorry i could not catch most of your name, it is difficult for me
	(as non-western language speaker) catch/spell western names.
	also, i have trouble catching up with content too...  anyway, better
	than nothing.

itojun


purpose: what's going on
address what you are trying to accomplish

russ, NAI labs:
couple of DNSsec related projects
- get .mil signed.  SAIC.  working towards it 1.5 years
- own network, own network system, cross-signed with cairn
	biggest challenge  parent-child relationship
	due to the network organization we could workaround it to be
	easier than others
- result: cumbersome, but can make it work.
do you publish public key somewhere? - it should be.  keys.cairn.net

??, mcic:
doing .mil too
using BIND9 early beta
we are about say "it's requirement to do DNSSEC" - have fun vendors.


jacob, sweden (.se):
doing the right thing:-)


scott rose, nist:
looking at protocol impacts of dnssec, administration
(sorry did not catch the content)


mark ?, research team, verisign:
how to deploy dnssec?
come up with method for incrementally coming up with dnssec
"opt-in" draft
using own codebase (genetically very distinct from bind9).
resolver - nominum
draft and test code - they are different.  demonstration purposes.
www.research.srl.com sp??
gtld.dnssec.comnet.no sp??


eastlake:


bmanning, jeff baker, ISI:
look at impact of dnssec stuff to whole toolkit, dns apex/root
key management, generation, creation, chain chasing to admin tree...
couple of tree, various places, running signed root/infrastructure zones, on top of ipv6.


?:
experiment, mirror domain name system under special zone (xyzzy.net sp??)


dan, ISI:
proj with NAI 
make dns interoperate among zone, cairn.net is a testbed
if you want to register zone under cairn.net, we can do that


olafur:
chair of dnsext.
Q: is dnssec deployable/worth deploying?  need modification?
we need an answer.


itojun, kame:
getrrsetbyname on openbsd libc
why KEY for SSH keys?
why KEY for IPsec auth?


jinmei, kame:
small signed zone, sec.kame.net
m root server operation.  planning to do stats, implication/whatever of EDNS0/performance.


williams, newstar:


cathy:
maintain in-addr.arpa zone.


sekiya:
m root server, ipv6 experimental name server.  interested in global testbed of dnssec


NAI guy:
experimenting with dnssec, focus: large TLDs.  looking at resolver issues
ans to olafur's question: topic is changing? "securing dns" to "worldwide pki using DNS"


what "securing DNS" really means.  clearifing goal is important.


writing BCP for sign-zone.


ripe guy:
would like to propagate methods to make internet more secure.  dnssec is one of them.


wesley:
modifying ssh to use dnssec keys.


92 release date - end of aug, or early sep
openssl?  use 096b.  works for multiple platforms.


need things to play with :-)


experimental operation - is it worth trying to coordinate, to make a real root structure?
partly missing is real server-server interaction tests.
good.
need to agree on which version of BIND we will be using and such?
	dnssec spec has been mostly stable.  but 913 has difficulty with 92.
	9x do not interop with 8x, and such.  need to agree on releases level.
test on v6 - safer place, but v6 net stability issue?
attempt to do both, from-root and within-some-subzone.


verisign implementation, will it be released/free? - not decided.

not everyone will be using dnssec (hard to learn).

dnssec protects who?  isp?  end user?  need a perfect protection or what?

bind9 needs to be optimized for performance.  if you run dnssec, you are hosed.
signature verification can kill a box easily.

use the word "data integrity".  don't use "secure" nor "reliable".

need to document threat model and what's good about dnssec.

in 9 months, we need to make dnssec docs forward to the next level of standard.  are we okay?
parent-child relationship is hard...
need to sit down and answer serious questions.  what is dnssec giving us?  is it worth the cost?  how many tweaks do we need?  is it really operationally possible? (if not operationally possible, it won't work).  may need to simplify.  there are tradeoffs.
there will be a presentation in dnsext.

dnssec - pki difference: consistent policy, recovery from failures (verification of revocation lists).

key management is painful (independent from DNS)
automate!

deploy TSIG, if SIG/KEY is too hard.  better than nothing.

is root using TSIG? - no, experimental root does.
how frequently do you change TSIG keys? - no answer.

minimum policy?

cache poisoning is the problem.  dnssec should be the solution for it.
modern servers do lots of sanity checks, only onlink case.
MS nameserver blindly accepts whatever on additional section. - which ver?
it is not too much problem than 5 years ago, but still a problem.