is this "normal" if not what to do about it?
my experimental zone (the family site) klam.ca has a KSK and a ZSK. There appear to be time differences between the records reported by DIG and the source records on file. In the case of the ZSK the inactive date-time is a few hours different, but in the ZSKs case it is 3 months.
Is this a problem, and if so what do I do about it.
The following dates were found in the source record and the output from dig.
source record dig KSK -A 20150126163534 20150117012252 KSK -I 20150225173534 20150225144654
ZSK -A 20150126163534 20150126173534 ZSK -I 20150527015028 20150225173534
oops!! I swapped the ZSK and KSK in the table.
On January 26, 2015 9:09:40 PM John john@klam.ca wrote:
my experimental zone (the family site) klam.ca has a KSK and a ZSK. There appear to be time differences between the records reported by DIG and the source records on file. In the case of the ZSK the inactive date-time is a few hours different, but in the ZSKs case it is 3 months.
Is this a problem, and if so what do I do about it.
The following dates were found in the source record and the output from dig.
source record dig KSK -A 20150126163534 20150117012252 KSK -I 20150225173534 20150225144654
ZSK -A 20150126163534 20150126173534 ZSK -I 20150527015028 20150225173534
-- John Allen KLaM
If you are out to describe the truth, leave elegance to the tailor.
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Activation/inactivation is when named starts/stops signing with the key. Inception/expiratioin is the time perion for which the signature is valid.
These are different time periods and are basically unrelated.
The inception will be < inactivation. The expiratin will be > activation.
After a key is activated it will be used to sign records that change. The sig-validity-interval (less a small random factor) is used to determine for how long a signature is valid for.
Mark
In message 14b292cc598.2743.14d9188d684ea7b6d1324cf92af46b48@klam.ca, John writes:
oops!! I swapped the ZSK and KSK in the table.
On January 26, 2015 9:09:40 PM John john@klam.ca wrote:
my experimental zone (the family site) klam.ca has a KSK and a ZSK. There appear to be time differences between the records reported by DIG and the source records on file. In the case of the ZSK the inactive date-time is a few hours different, but in the ZSKs case it is 3 months.
Is this a problem, and if so what do I do about it.
The following dates were found in the source record and the output from dig.
source record dig KSK -A 20150126163534 20150117012252 KSK -I 20150225173534 20150225144654
ZSK -A 20150126163534 20150126173534 ZSK -I 20150527015028 20150225173534
-- John Allen KLaM
If you are out to describe the truth, leave elegance to the tailor.
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
------------14b292ccdd3902274342ea2c58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
<html> <head>
</head> <body> <div style="color: black;"> <div style="color: black;"> <p style="margin: 0 0 1em 0; color: black;">oops!! I swapped the ZSK and KSK in the table.</p> </div> <div style="color: black;"> <p style="color: black; font-size: 10pt; font-family: Arial, sans-serif; margin: 10pt 0;">On January 26, 2015 9:09:40 PM John <john@klam.ca> wrote:</p> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div class="moz-signature">my experimental zone (the family site) klam.ca has a KSK and a ZSK. <br> There appear to be time differences between the records reported by DIG and the source records on file. <br> In the case of the ZSK the inactive date-time is a few hours different, but in the ZSKs case it is 3 months.<br> <br> Is this a problem, and if so what do I do about it.<br> <br> The following dates were found in the source record and the output from dig.<br> <table border="1" cellpadding="2" cellspacing="2" width="100%"> <tbody> <tr> <td valign="top"><br> </td> <td align="center" valign="top">source record </td> <td align="center" valign="top">dig<br> </td> </tr> <tr> <td valign="top">KSK -A <br> </td> <td align="center" valign="top">20150126163534 </td> <td align="center" valign="top">20150117012252<br> </td> </tr> <tr> <td valign="top">KSK -I<br> </td> <td align="center" valign="top">20150225173534<br> </td> <td align="center" valign="top">20150225144654<br> </td> </tr> <tr> <td valign="top"><br> </td> <td valign="top"><br> </td> <td valign="top"><br> </td> </tr> <tr> <td valign="top">ZSK -A<br> </td> <td align="center" valign="top">20150126163534<br> </td> <td align="center" valign="top">20150126173534</td> </tr> <tr> <td valign="top">ZSK -I<br> </td> <td align="center" valign="top">20150527015028<br> </td> <td align="center" valign="top">20150225173534<br> </td> </tr> </tbody> </table> <br> <br> -- <br> John Allen<br> KLaM<br> ------------------------------------------<br> If you are out to describe the truth, leave elegance to the tailor. </div>
_______________________________________________<br> Please visit <a class="aqm-autolink aqm-autowrap" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br> bind-users mailing list<br> bind-users@lists.isc.org<br> <a class="aqm-autolink aqm-autowrap" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote> </div> </div> </body> </html>
------------14b292ccdd3902274342ea2c58--
--===============0592810492330139115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===============0592810492330139115==--
On Mon, Jan 26, 2015 at 09:08:36PM -0500, John wrote:
There appear to be time differences between the records reported by DIG and the source records on file.
Dig does not and cannot report the activation and inactivation time, so it is hard to see how one might expect anything in dig output to agree with either time.
RRsigs report the signature validity interval which should start some time after activation, and though generally will end before inactivation, may even end after inactivation, if the key inactivation time was set (as in Carsten's notes) sufficiently close to that date, that existing RRsigs may already be in place that outlive the key inactivation.
The initial time of an RRsig will never be outside (activation, inactivation) interval, but the final time may lie just beyond.
On 1/26/2015 10:48 PM, Viktor Dukhovni wrote:
On Mon, Jan 26, 2015 at 09:08:36PM -0500, John wrote:
There appear to be time differences between the records reported by DIG and the source records on file.
Dig does not and cannot report the activation and inactivation time, so it is hard to see how one might expect anything in dig output to agree with either time.
RRsigs report the signature validity interval which should start some time after activation, and though generally will end before inactivation, may even end after inactivation, if the key inactivation time was set (as in Carsten's notes) sufficiently close to that date, that existing RRsigs may already be in place that outlive the key inactivation.
The initial time of an RRsig will never be outside (activation, inactivation) interval, but the final time may lie just beyond.
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.
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.
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 5bf12300255d1475ae43677b7062ab8964ca097ee6096cd005115b8c974e83abthat 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.4After 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
On Tue, Jan 27, 2015 at 01:51:32PM -0500, John Allen wrote:
Are you recommending rolling the ZSKs every 7 days, or are you talking about something else?
NO. I'm recommeding signature lifetimes of ~7 days for sites with the operational capacity to keep everything current on a tight schedule. This way, signatures of stale records expire quickly.
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.
Overkill IMHO. Since the root zone signature is 2048 bits, anything stronger is just a waste of bandwidth and risks interoperability problems. I a decade from now, perhaps we'll have interoperable options based on soon to be defined best-practice ECC curves,
For now RSA-2048 is about as strong as you can reasonably get, and likely strong enough.
What effect do the new algorithms have on time to break? I assume that they are still based upon trapdoor functions?
There is AFAIK no public evidence of practical key recovery attacks on RSA-1024, when properly seeded. Practical attacks on 2048-bit RSA seem rather unlikely at present.
On 1/27/2015 2:00 PM, Viktor Dukhovni wrote:
Are you recommending rolling the ZSKs every 7 days, or are you talking about something else?
NO. I'm recommeding signature lifetimes of ~7 days for sites with the operational capacity to keep everything current on a tight schedule. This way, signatures of stale records expire quickly.
I am still not quite sure what you mean. I have a sneaky feeling that we are talking about two different things. My DNSKEYs have a life of about 60 days. which is what I thought you were taking about.
However, if I look a little closer I see that my RRSIG has a life of about 30 days. I don't remember specifying any times when I signed my zones, plus I am now using inline signing. think I had better find out how to specify these values for inline.
Overkill IMHO. Since the root zone signature is 2048 bits, anything stronger is just a waste of bandwidth and risks interoperability problems. I a decade from now, perhaps we'll have interoperable options based on soon to be defined best-practice ECC curves,
For now RSA-2048 is about as strong as you can reasonably get, and likely strong enough.
Given the length of root signatures, I have to agree that 2048 is it.
There is AFAIK no public evidence of practical key recovery attacks on RSA-1024, when properly seeded. Practical attacks on 2048-bit RSA seem rather unlikely at present.
That's the problem with cryptography. Nobody is going to tell you that they have broken you codes, you only find out when something unexpected or unpleasant happens.
Take care.
On Tue, Jan 27, 2015 at 05:30:26PM -0500, John wrote:
NO. I'm recommeding signature lifetimes of ~7 days for sites with the operational capacity to keep everything current on a tight schedule. This way, signatures of stale records expire quickly.
I am still not quite sure what you mean. I have a sneaky feeling that we are talking about two different things. My DNSKEYs have a life of about 60 days. which is what I thought you were taking about.
I am NOT talking about key lifetimes. I am talking about signature lifetimes.
However, if I look a little closer I see that my RRSIG has a life of about 30 days. I don't remember specifying any times when I signed my zones, plus I am now using inline signing.
That's what I'm talking about. The 30 day lifetime is likely a default if you don't override it. It is likely best to leave it that way, unless you have stricter security requirements and the operational capability to work within a more narrow expiration window.
Likewise, keep the crypto settings mainstream. Having keys "more secure" than the root and/or your parent domain's makes no sense.
There are no security proofs for fundamental crypto primitives other than the ever impractical one-time pad. Everything else is at best a reasonable trade-off. At this point in time RSA 2048 is a reasonable trade-off. Stronger RSA keys for DNSSEC are not reasonable, and ECC is for now not sufficiently interoperable and the best curve choices are about to change.
So I think it is fair to say that at present best practice is to use a 2048-bit algorithm 8 KSK, and either a 2048-bit or even a 1024-bit (rotated periodically to suit your taste) algoritm 8 ZSK.
Anything more exotic is likely counter-productive.
On 1/27/2015 5:42 PM, Viktor Dukhovni wrote:
On Tue, Jan 27, 2015 at 05:30:26PM -0500, John wrote:
However, if I look a little closer I see that my RRSIG has a life of about 30 days. I don't remember specifying any times when I signed my zones, plus I am now using inline signing. That's what I'm talking about. The 30 day lifetime is likely a default if you don't override it. It is likely best to leave it that way, unless you have stricter security requirements and the operational capability to work within a more narrow expiration window.
Darn you Mr Dukhovni, there I was drifting along in blissful ignorance, now you have made think ;) Now I have to investigate sig-validity-interval, ha well.
With inline signing, how much extra work do you think will/would be involved.
On Tue, Jan 27, 2015 at 08:12:40PM -0500, John wrote:
Darn you Mr Dukhovni, there I was drifting along in blissful ignorance, now you have made think ;) Now I have to investigate sig-validity-interval, ha well.
No, you really DON'T! That comment was for anyone on this list with a 24-by-7 operations team, and DANE records that protect something of value, where reasonably timely "revocation" is wanted.
With inline signing, how much extra work do you think will/would be involved.
These aren't the droids you're looking for.
On 1/27/2015 8:55 PM, Viktor Dukhovni wrote:
On Tue, Jan 27, 2015 at 08:12:40PM -0500, John wrote:
Darn you Mr Dukhovni, there I was drifting along in blissful ignorance, now you have made think ;) Now I have to investigate sig-validity-interval, ha well.
No, you really DON'T! That comment was for anyone on this list with a 24-by-7 operations team, and DANE records that protect something of value, where reasonably timely "revocation" is wanted.
With inline signing, how much extra work do you think will/would be involved.
These aren't the droids you're looking for.
Of course Obi Wan
participants (4)
-
John -
John Allen
-
Mark Andrews -
Viktor Dukhovni