Subject: Issues with draft-ietf-dnsext-trustupdate-threshold-00.txt

From: Mike StJohns <[email-masked]>
Date: Sun, 14 Aug 2005 20:41:39 -0400

At the DNSEXT meeting we were asked to comment on the various trust update 
drafts...

DISCLAIMER:  I'm the author of the other trust anchor update draft.  That 
said, I believe the following to be a fairly objective description of 
problems with the named draft.  This draft (along with my own) is currently 
expired, but we've been asked to resubmit them - see 
http://tools.ietf.org/wg/dnsext/agenda?item=agenda63.txt for pointers to 
the expired drafts.

1) "Time is nature's way of making sure everything doesn't happen at the 
same time."  The timing model in the draft with respect to when anchors are 
valid is non-existent.  Basically, the draft is written from the point of 
view of the data provider (server) and not the resolver.  To understand why 
this is a problem, consider 1 trust point with N trust anchors and 1000 
resolvers that all begin with the same perception of trust anchors at the 
trust point.  Do any trust update action at the trust point, wait a random 
time and do another trust update action.  First question:  For any given 
resolver, what is the set of active (trusted) trust anchors for that trust 
point at any time T after the second update action.  Answer: Indeterminate 
because the state of the trust anchor AT THE RESOLVER depends on the 
resolver seeing all the trust update activity and it might not if the first 
query to the trust point occurs after the second update action.  Second 
question: What are the chances all 1000 will have the same state 
information at time T?  Answer: approaches zero.  There's an attempt to 
wave this off as not a problem (section 3.7) but any protocol description 
has to consider what actually reaches the resolver, and not just say to the 
operator "don't do that".  In other words, if the resolver doesn't see a 
change because another happens due to the operator going off and doing two 
changes in a row without sufficient delay between them, the resolver is 
going to get out of sync with the trust point. (And people being who they 
are, this will happen either on purpose or by mistake)

2) The draft uses the term "locally configured minimum" to describe the 
number of trust anchors needed at a trust point to validate trust 
updates.  This comes under the heading of a very bad idea.  To explain, 
take the same 1000 set of resolvers from paragraph 1.  Have 500 of them 
require 2 anchors and 500 require 3.  Have the trust point owner sometimes 
use two anchors and sometimes three.  Question:  What are the chances that 
all 1000 will be able to keep in sync?  Answer:  Zero.    The number of 
trust anchors needs to be a consistent number per trust point and ideally 
for the entire scheme (so you don't actually have to configure this at the 
resolver.)  Its possible what the author meant the trust point owner would 
make the selection, but that's almost as bad because that value (MofN for 
the trust point) isn't encoded in the DNS and would need to be manually 
configured by EACH resolver owner.

3) Due to the draft's described data model, each trust point DNSKEY RRSet 
would have to be signed by every SEP DNSKEY in the RRSet.  This tends to 
expand the RRSig RRSet substantially.

4) Unfortunately, since the RRSig RRSET isn't also signed, its possible to 
delete one or more of the RRSigs from an answer with some interesting and 
mostly undefined impacts on the resolver's view of the trust anchor 
set.  E.g. you can REALLY cause some interesting problems by letting some 
resolvers see all the RRSIGs and some see reduced sets.

5) It's unclear if this changes the trust model of DNSSEC by requiring an 
AND of keys at a trust point rather than an OR.  In other words before if 
you had at least one trust anchor that chained (via at least one key at 
each signature point) to the data, the data validated. If the draft 
requires multiple keys for trust update but single keys for trust chaining, 
there are some interesting interactions that may take place when you throw 
in multiple algorithms.

At the current state of the draft, I can't say if any or all of these are 
fatal, but there's a lot more work to do to nail down the protocol 
interactions.

Mike

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>