Subject: Re: 3 comments on timers-03

From: Mike StJohns <[email-masked]>
Date: Wed, 26 Jul 2006 14:22:25 -0400

At 01:46 PM 7/26/2006, Scott Rose wrote:
>I have been reading the draft-timers-03, and I know there are other
>comments, but I think these are unrelated.  2 are minor, one is a response
>to a discussion point in the draft.
>
>First the minor ones
>1.  "resolver" is used several times when the actual component performing
>the action would be the validator.

The resolver conceptually includes the resolution part, the validator 
part and the trust anchor database part.  The management of the 
database is actually either part of the resolver, or an external 
application rather than part of the validator.  I did a quick scan 
and I think my language is mostly consistent with that.  I'll do a 
bit deeper review on the next pass, but it would help if you'd point 
to the specific instances - thanks!

>2.  Section 5.1 - the 5th step is "wait a while".  This step seems
>unnecessary.  Or, if a time limit is really needed before any other
>operation, the time could be the TTL of the DNSKEY RRset or the min TTL of
>the SOA RR.  But I think it's unnecessary.

That was meant to refer to the hold down time for the add anchor 
operation.    Basically, once you've posted the data (as the data 
originator), the trust anchor doesn't become valid - at each resolver 
- until some period of time has expired and certain actions are taken 
by the resolvers.  That's described in the resolver state table as 
the AddPend stage.  Section 5 is meant to describe what things look 
like from the data originators point of view - some resolvers are 
going to get the new trust anchor fairly quickly, others might have 
just missed their last timed update and may take a while to get the 
new anchor, so "Wait a while" seemed to be sufficient.

Next rev I'll add "... - the new trust anchor will be populated at 
the resolvers on the schedule described by the state table and update 
algorithm - see section 2.3 above"

>For the discussion point in section 4.2 (states).  In the "missing" state,
>if a DNSKEY is removed from a RRset, it should be dropped as a trust anchor.
>I don't know if there should be a wait of the "hold down" time or not.  If
>the RRset validates and there is a trust anchor, then it is a mistake in the
>rollover process and the missing trust anchor could be dropped.

You definitely don't want to delete a trust anchor from a set just 
because it's missing once.  The example for why that would be a *bad 
thing* is an operator publishing a trust point DNSKEY RRSet sans that 
trust anchor by mistake, and then realizing the mistake after a few 
hours.  Any resolver that retrieved that RRSet would delete the trust 
anchor and when the problem was fixed in a few hours, would be out of 
step with what the rest of the resolvers thought were the trust 
anchors for that trust point.  OTOH, eventually that accidentally 
deleted key would rejoin the set of trust anchors after the add hold 
down period.

>If there is no trust anchor anymore (i.e. the only trust anchor is now
>missing) - then there needs to be a timeout before dropping, just in case of
>a man-in-the-middle dropping the DNSKEY RRset from messages.

If I were going to drop this, I'd probably set a hold down time for 
dropping it to be something like twice the hold down time for adding 
it.  I'd probably also refuse to drop it unless I got a validated 
RRSet from the trust point which didn't include the trust anchor - 
and without a second trust anchor, that would be impossible so I'd 
never drop a single trust anchor.

Hmm...

It makes the state table more complex, but it's do-able.

So the trade offs are a more complex state table vs just hanging on 
to a non-revoked but missing trust anchor.

Comments?

>Scott
>
>
>
>--
>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/>

--
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/>

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 26 Jul 2006 14:42:10 -0400

<no-hat-just-regular-wg-member>

>the action would be the validator.

Actually I think we need a new term in this discussion,
in my mind the old terms perform
         resolver = DNS entity that performs lookup
         validator = entity that validates DNS responses

the new term describes the new function caused by key management:
         TA-maintainer = entity that keeps track of current TA's for the
                    all the trust anchor points it is configured with.

         Olafur

---

From: Mike StJohns <[email-masked]>
Date: Wed, 26 Jul 2006 14:50:41 -0400

Please no...  part of the reason I didn't do that 
is because it isn't necessarily a separate 
application, codebase or whatever. I'd *really* 
prefer not to add this because I think it will 
actually cause more confusion, not less.

Mike

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 26 Jul 2006 15:08:18 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mike StJohns

> to the specific instances - thanks!

I'll go through again and maybe spot some specific cases.  As with the other
thread, I agree that adding more terminology might make things more
confusing.

> algorithm - see section 2.3 above"

I think that's fine.

> to a non-revoked but missing trust anchor.

I agree with the second part - dropping only when I have a valid secondary
trust anchor.  But if the cost is a more complex state table, and the only
benefit is missing (and possiblty revoked, or not) keys are no longer
cluttering up my validator, I don't know if the trade-off is worth it, but
then I haven't tried to implement this yet.

---

From: Robert Story <[email-masked]>
Date: Wed, 26 Jul 2006 19:11:01 -0400

On Wed, 26 Jul 2006 14:22:25 -0400 Mike wrote:
MS> >For the discussion point in section 4.2 (states).  In the "missing" state,
MS> >if a DNSKEY is removed from a RRset, it should be dropped as a trust anchor.
MS> >I don't know if there should be a wait of the "hold down" time or not.  If
MS> >the RRset validates and there is a trust anchor, then it is a mistake in the
MS> >rollover process and the missing trust anchor could be dropped.
MS> 
MS> You definitely don't want to delete a trust anchor from a set just 
MS> because it's missing once.

Isn't this exactly the attack vector described in the first
paragraph of section 2.1?

The corner case that bugs me with the timers draft is if an
attacker manages to get a new key into a published DNSKEY RRSet and it
goes unnoticed for the add hold-down period. Resolvers will consider it
a valid trust anchor. When the operator notices this and re-publishes,
they can omit the bad key, but not revoke it. Resolvers that have
the bad key will continue to trust it until the remove hold-down timer
expires.

-- 
Robert Story
SPARTA