draft minutes

[Randy Bush <[e-mail]>]

[ these minutes from Jun-ichiro itojun Hagino <[e-mail]> are the
  only ones i have received.  will submit tomorrow if i get no others.
  please send corrections now -- randy ]

multicast dns - is this the right solution?
?: is it the same protocol, or new protocol?
reuse of the port number, reuse of the packet format

?: when we started, "behavior just like DNS"
operational problem, conceptual problem

alain: icmp6 name lookup - one solution looked at (but was not provided for ipv4)

aboba: no set of goals stated, document is ready for ietf last call
something gone very wrong.

is this solving the right problem?
is there a better solution?

mohta: zeroconf is not a good thing to pursue.  if we don't want client configuration, dns servers having wellknown anycast addresses work fine

?: would like to do "infrared" thing that palm does, or appletalk.  need some mechanism for resolving name.

rob: there are people with different goals.

?: it is a good way to reuse DNS.  we won't be able to solve the problem even if we start fresh

aboba: if zeroconf requirement is broken?

olafur: zeroconf is a part of requirement.


---
dns threat model (rob)

examine why dnssec was started
dnssec ensures data item is the same when they are put in, and when they are pulled out

lack of threat model?

dnssec has dependency on time sync.


---
delegation signer (olafur)

motivation
key record repeats the mistake of ns record in delegations, same record in two zones
key at child is clumbersome
parent advertises strong identifier of key used
resolver
	verifies DS record from parent
	only verifies key if sig matches verified DS

DS advantages
information flow in key handshake is now identical to NS
minimizes communication
	only when hcild changes KEY set signing key
less data in parent
	DS much small than key
	DS only at secdure delegation
child in full control of security status
no conflicting key sets

disadvantages: more work for resolvers.

3 implementations

what change from the last IETF
NODS in NXT bitmap at unsecured delegations
DS can only pont at DS zone keys that can sign zone
key size field dropped
server returning...

DS complicates life for resolvers

chop off 2535, or DS, or opt-in

next steps
DS seem to work
DS makes DNSSEC much/some easier for operations
DS increments complexity in resolvers
advance or discard?

?: is it really advantageous to have less data in parent?
less state - similar to opt-in
minimizes communication

deployability difference for big zones
how much better

should combine discussion for opt-in

it is advantageous that downstream reload does not happen when upstream key changes

balance: decoupling child signing and parent signing - weakening security

outband or inband?

key rollover for .com - 6month, 2 key alive at one time

(comments continue after opt-in talk)

---
opt-in

dnssec painful for large zones
huge upfront cost
	null KEYS, nxt RR and signatures for child zones that are not secure
	little initial deployment
high generation cost
	ordering
	re-signing
	distributing

changes since 00
total rewrite
goal is the same, different methods
NXT indicates opt-in instead of KEY
opt-in uses noSig techniques
basically, finer granurality, opt-in 2535 choice can be made on per-record (instead of per-zone)

2535 NXT - authenticated denial of existence of names
does not allow unsigned names
opt-in NXT - authenticated denial of existence of SIGNED names
does allow unsigned names

2535 - positive answer = this delegation is not signed
the unsigned name exist (crypto verifiable)
opt-in - negative answer = there exist no signed delgation between two signed names
the unsigned name exist (not crypto verifiable)

pros and cons
every advantage has disadvantages
positive: opt-in reduces the amount of crypto in a zone
negative: opt-in gives up authenticated denial of existence for unsecured delegations (give up security for unsecured data item)
don't "like" opt-in? sign it with 2535
	opt-in does not obsolete 2535

positive side-effect
traversing a zone through NXT recodrs gives only signed names and signed delegations
a chain of secure delegations is possible without the requirement to sign the whole zone

2535 is not "better " ot "worse" than opt-in
2535 has advantages for the average zone
opt-in has advantages for the delegation-only zone (large zone)

randy: change in security model.  attacking the problem of size by a protocol change, and security model change.  assumption - the little part of zone gets signed.

?: it is already hard to keep up hardware with .com size.

vixie: losing ability to cryptographically prove non-existence of names, or nonexistence of child signature, is it true? - not exactly.

?: it is up to zone owner.

?: we can mix 2535 and opt-in in a single zone.


---
key

desire to have algorithms separately documented.
minimize dependency to 2535
key format draft documents standard moduli?


---
AD bit outstanding issue

ad draft status
document passed working group last call, not sent out

when can AD bit be set?
AD = authenticated data
AD draft says authoritative server can set the AD bit if local security policy allows
comments on the mailing list afer last call disagree

argument for text
the issue only affects resolvers that trust server
doing signature validation on all data loaded is expensive
	either slows loading or answers
integrity of whole zones on servers can be protected by other means
	signed zone files, signed zone transfer

against
AD MUST only be set if signatures have been verified
	setting the AD bit under other conditions is wrong
AA bit implies that the data is authentic

suggestion
authors must add text that clarify states that AD bit is not be set by default and MUST only be set if there are some other validity checks in place
document must also document what [stub] resolvers are affected

?: 2535 says about AD bit - data satisfies the security policy of the server

?: what is "policy"?  can you tell what kind of policy the server is implementing?

?: the situation happens only when you talk to authoritative zone.  it should be your own domain, so you know the policy?

?: why you can't use AA bit for that?

authors will update the draft.


do we need DS? do we need opt-in?

vixie: from test results, it seems (something like) DS is needed for key rollover
opt-in is just a hack for one zone (.com)
anyway we need to get this DONE.

?: opt-in is needed, to sign .com.  can't deploy .com with 2535.

?: cost vs usefulness.  cost is significant for large zones.

?: does opt-in break security of zones (= signed chain)?

bill: interoperability between 2535 and DS? - yes, DS-capable resolvers can (but there is a flag day).

olafur: we are doing this too long.  for DS and opt-in, need go or nogo.

?: there are people who are trying to deploy 2535.  too long wait.

randy: agree with vixie.

?: not deployable as it is today.

vixie: need to separate between deployability due to size, and other issues.
does it matter if we sign .com today, or 2004?

this needs to come to conclusion.  during this week people will talk and try to come to conclusion, and then to the list.

vixie: the reason why root is not signed is that dnssec is still seems to be in flux


---
tkey securet key renewal mode

necessary to refresh shared keys for tsig
new mode for update procedure and mechanism in tkey
	renewal mode defined

key has lifetime.  during renewal, key lifetime overwraps

tsig-signed query from client
expiration time check
server urges clients to send tkey renewal requests

tkey secret key renewal request from client
	DH public key
	old key's name and algorithm
answer from server
	establish new secret by DH

TSIG-signed query with the new key from client
server adopts the new key

feature
systematic control by server
"renewal", not add/delete
limit number of shared keys

think about network errors.

feel no need for this.  server can delete the key when it expires.

tkey is just for temporary measure.  it is direciton we shouldn't go.


---
dns mib

proposed replacement for 1611
not ready for prime time yet.  please read, test it and comment.

need requirement document to start with.


---
ngtrans dns op req

problem: IPv4-only and IPv6-only nodes coexist, how to resolve?
long term problem

consequences - this working group has to do something.

requirement
single root requirement, applies for IPv4 and IPv6
dns is IP version independent application.  need to be able to get the same data independent from data.
we can change v6 things, we cannot change v4 things

need some kind of bridging system, so that v6 only resolver can get data from v4 only server, or other ways
need symmetry in bridging system?  no.

v4 resolver - no good way.  zone needs to be served by dualstack node.
v6 resolver - relaying system?

leakage of information
serve zones on dualstack node, period.


---
dynamic update

we assume that updated records gets eventually removed explicitly
state an expiration time

repeat of past effort.

if we are going to repeat this one, requirement document is needed.

we can't assume wall clock (powered off).

there seem to be some need.


---
application keys - limiting the scope of the key resource record

simple idea - restrict KEY to dnssec.

dnssec key vs application keys - looks like a different beast.  reolver behavior is very different.


separate rtype, SRV, KEY, ...
protocol specific flag?  attribute?  should we separate pubkey and cert?
we need a requirement document.


(battery is out)

to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.