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

From: "Loomis, Rip" <[email-masked]>
Date: Tue, 11 Apr 2006 11:41:43 -0400

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

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 11 Apr 2006 13:07:37 -0400

> TA" calculation--similar to how SOA values are used.

See e.g. draft-moreau-dnsext-sdda-rr-01.txt, Authentication 
Expiration/Inception Fields.

> practiced and DNS+DNSSEC+key management.

Then the zone manager re-issues the SDDA RR with more restrictive 
Authentication Expiration/Inception Fields.

> too often/not often enough to pull/push/verify status?  

A mere operational issue, once the SDDA Expiration/Inception protocol 
support is accepted:

A local policy for *paranoid* DNS resolvers is to query authoritative 
key management *often*. An ordinary DNS resolver implementation may have 
a manual command/button for "emergency trust anchor rollover queries" so 
that a publicised DNS root private key compromise has a cure, and 
otherwise do the queries according to the SDDA expiration time.

OK, these are solution space elements, just in reaction to your 
"additional thoughts".

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]