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

[John Allen]

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
-- 
John Allen
KLaM
------------------------------------------
How do you tell when you're out of invisible ink?