Re: is this "normal" if not what to do about it?

On 1/26/2015 11:50 PM, Viktor Dukhovni wrote:

On Mon, Jan 26, 2015 at 11:25:58PM -0500, John wrote:

...

Thanks for the reassurance. I was not sure whether there was a problem or not. Every test I ran indicated that there was no problem, but being new and nervous I thought I should ask.

My only comment on your settings:

 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45762
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 ;klam.ca.               IN SOA
 klam.ca.                SOA     ns0.klam.ca. admin.klam.ca. 2015012610 14400 3600 1209600 3600
 klam.ca.                RRSIG   SOA 8 2 3600 20150226005819 20150126235819 849 klam.ca. <signature>

is that a 30 day signature is at the high end of the sensible range.

However, this is often reasonable for domains that don't have much of value to protect. For a domain with more at stake, and a operations staff that ensures that all secondary servers are always reasonably current, and signature updates always timely, one might consider ~7-day signatures rather than 31-day signatures.

Bottom-line, you're fine, you even have working TLSA records:

 klam.ca. IN MX 10 smtp.klam.ca.
 _25._tcp.smtp.klam.ca. IN TLSA 3 0 1 5bf12300255d1475ae43677b7062ab8964ca097ee6096cd005115b8c974e83ab

that match your SMTP server's certificate. Just don't forget to add a TLSA record that matches your next certificate a few TTLs *before* you deploy it.

 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

After the new cert chain live, you can drop the original TLSA RR, leaving only the new one in place.

Just to make sure that I understand what you are saying here.

Are you recommending rolling the ZSKs every 7 days, or are you talking about something else? Furthermore, if that is what you are saying, what is your recommendation for KSKs? Plus, what are your recommendations for the prepublish interval and the retirement interval?

I would agree with you that some of the recommendations for the key life are not very sensible. I would have thought that a 2048 bit key was good for around 30+ days and that KSKs should be 4096 bit.

I have been semi-retired for several years, but when public key crypto (RSA) first showed up on my horizon, (11980s) the estimated time to break was (IIRC) 7.8 billion years. Something like five years later a 631 bit primes were being factored in something like a month. I suppose somebody with a large botnet (SETI style) can probably cut that time significantly. What effect do the new algorithms have on time to break? I assume that they are still based upon trapdoor functions?

Take care. Regards