On Wed, Jan 07, 2015 at 01:47:06PM -0500, John wrote:
> >I am not sure I understand this. Why are you linking the two?
> >I am not linking anything.
>
> I am not sure what TLSA updates has to do with key rotation, other than they
> might be a good idea to do them at the same time. May be its my odd ball way
> of reading it.
I am talking about SMTP server TLS key/cert rotation, not DNSSEC
key rotation.
And not at the same time, the TLSA RRs for new certs/keys need to
be published before the keys are deployed concurrently with the
live keys. Let the combination age a few TTLs, then deploy the
new keys.
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4
With DNSSEC it is the other way around. Publish old and new DNSKEY
records first, let that bake in for a few TTLs, then publish new
DS RRs. When removing keys, drop corresponding DS RR first, let
than RRset age a bit, then remove the keys.
Invariants:
DNSSEC: For each not yet expired (TTL) DS RRset there is
always a corresponding DNSKEY published at the zone apex.
DANE: At all times the server's live certificate chain
matches at least one TLSA record in every not yet expired
(TTL) TLSA RRset.
Key rotation must maintain these invariants.
No extant DS RRsets that contain records with no matching DNSKEY.
No TLS certificate chains that fail to match some record in
every extant TLSA RRset.
--
Viktor.
