RE: ISSUE 4: Key "lifetimes", was Re: Pending issues for draft-i etf-dnsext-rollover-requirements-00

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

> > >ISSUE 4: Requirements draft does not explicitly mention advertising
> > >key "lifetimes"

Correct, and that lack of mention is also correct.  (More comments
below, plus comments inline on what Mike St. Johns and Scott Rose
previously said on this.)
 
> > Keys don't have lifetimes, signatures do.
Respectfully, I disagree slightly on terminology.  Keys do have
"lifetimes", and so do signatures.

Key "lifetime" is the key effectivity period, which is initially
defined by the operator, is generally not known to the end user or
security aware resolver, and can be changed at any time.  Scott
referred to this below as a "key operational period"--it's something
of which only the DNS zone administrator should be aware, in the
same way that the master/slave status of an authoritative server
should not be apparent to an end user.

Signature "lifetime" is the signature validity period, which
is defined initially by the operator but (for a given signature)
then cannot be changed and can be objectively verified by the
end user/security aware resolver.

> > Any given key in the DNS
> > should last until its superceded or revoked.   Anything 
> > else would be a base change to the protocol (and orthogonal to
> > the concept of key rollover).

Agree with this part.

> I agree with Mike.  Key operational periods are more policy 
> issues, not protocol issues.  There would be no way of expressing
> this lifetime in the DNSKEY record.
> 
> I don't support this requirement.

Some additional thoughts:

It Might Seem Nice If the key effectivity period for a Trust
Anchor (TA) was known to the security-aware resolvers and
could be figured into the "how often do I check for a new
TA" calculation--similar to how SOA values are used.

However, if there is a key compromise that results in an
emergency key supersession (emergency rollover), though,
then by definition the key effectivity period will be
changed--and to me this fact (and the related requirement
for timeliness in section 5.8 of the -00 draft) is an
essential difference between conventional DNS as currently
practiced and DNS+DNSSEC+key management.

There's no place in the DNSKEY record for effectivity
period, nor does there need to be, nor is it something
that (IMHO) should be communicated to security-aware
resolvers as part of establishing/changing a TA.  (What
MSJ and Scott said).

It does still seem to me that there's going to be an
issue, because of this essential difference, in how the
requirements draft (and the automated rollover draft(s))
flesh out the "timeliness" requirement.  How often is
too often/not often enough to pull/push/verify status?  

  --Rip

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