.gov DNSSEC operational message
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A KSK roll for the .gov zone will occur at the end of January, 2011. This key change is necessitated by a registry operator transition: VeriSign has been selected by the U.S. General Services Administration (GSA) to operate the domain name registry for .gov. It is important that you prepare for this key change NOW. DO NOT WAIT until late January, 2011, to take action: the changes described below should be made as soon as possible. Because .gov was signed prior to the signing of the root zone, it is reasonable to believe that many DNSSEC validators (usually part of recursive name servers) have the .gov zone's KSK statically configured as a trust anchor. Further, because automated trust anchor rollover software implementing the protocol described in RFC 5011 has not been widely available until recently, it is reasonable to believe that few validators with a statically configured .gov trust anchor would be able to understand a KSK roll using RFC 5011 semantics and update their trust anchor store automatically. VeriSign is sending this message to announce the impending .gov KSK roll so that the DNSSEC operational community will be informed of the change and has the opportunity to take the necessary steps to prepare for it. The .gov KSK roll will occur between 27 January 2011 and 31 January 2011. The rollover will not use RFC 5011 semantics because of issues surrounding the registry operator transition. The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone. Because the root zone has had DS records corresponding to the current .gov KSK since 27 October 2010, static configuration of a trust anchor for .gov is currently no longer strictly necessary. Because there will be no non-DNS-based mechanism to authenticate subsequent .gov KSKs, configuration of the .gov KSK as a trust anchor is NOT RECOMMENDED. Take these steps NOW to prepare for the .gov KSK roll in late January 2011: 1. If your DNSSEC validators DO NOT HAVE a trust anchor for the root zone configured, CONFIGURE the root zone's KSK as a trust anchor. An authenticated version of the root zone's KSK is available at http://data.iana.org/root-anchors/. 2. If your DNSSEC validators have a trust anchor for the .gov zone configured, REMOVE the .gov zone's KSK as a trust anchor from your validator's configuration. If you follow both steps above, your DNSSEC validators should continue to validate names in .gov, but the .gov KSK will be authenticated via the signed root's KSK rather than a locally configured trust anchor. DO NOT WAIT until late January, 2011, to take these actions: the trust anchor changes described above should be made as soon as possible. If you have any questions or comments, please send email to registrar@dotgov.gov or reply to this message. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEVAwUBTRJqVNdGiUJktOYBAQJaHQf+OKcKsnUySDLzwdMUdjDpFhvm53iJF4RN /fWMK+5ahTqWpWgDnMi0NZij6OKCu+jUtH75Q9z4iXglyQzl5rweL4N01jV7GquV tYO18ys2lQ7w07XFP2Y8568ckYeWkDgYGwHJ4GKRMW4/cyl6YlE3Z+sxMbn/O3/G CcaTgmVtVHkVvLJfPMotaE9M4ldAlM3yMAHQspadVPrBNtzmYUBjJhjvwe1XxAok UBJLwqubSnY2qoAsXrwcHov4Z1izxMiuLIthyjoc79r11J0CYzwDNpDd2QyPD/3y 7nFHlxCIYDm9r2lnv8sbc/p+/PuM7rpzpkCUvpWY9FArZWt7h7gSfA== =+pAa -----END PGP SIGNATURE-----
----- Original Message -----
From: "Matt Larson" <mlarson@verisign.com>
The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone.
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell. Why was that decision taken, Matt? Cheers, -- jra
On Thu, 23 Dec 2010, Jay Ashworth wrote:
From: "Matt Larson" <mlarson@verisign.com>
The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone.
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell.
Why was that decision taken, Matt?
Having a zone's KSK statically configured on validators as a trust anchor can lead to a world of hurt: when rolling the KSK, the zone owner has to get everyone to update their trust anchor configuration. In theory, the protocol described in RFC 5011 allows an operator to signal a roll and validators will do the right thing. In practice, in these early days, you can't count on much 5011 deployment because implementations haven't been available for that long. This situation puts the operator of a popular signed zone, such as a TLD, in a difficult position and makes KSK rolls difficult--but only if the KSK is statically configured. Meanwhile, we now have a perfectly good signed root zone that can vouch for any TLD's KSK. As a result, as the impending registry operator for .gov, VeriSign doesn't want to encourage static configuration of the .gov KSK as a trust anchor. Such static configuration would be made easier and implicitly condoned if the .gov KSK were published and authenticatable outside of DNS. Note that the situation is the same today with the signed .net zone (and will be the same for the .com zone when it is signed in Q1 of 2011): the .net KSK is intentionally not published outside DNS. The path to trusting that key is via the signed DS record corresponding to it in the root zone. Matt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/26/2010 09:07, Matt Larson wrote: | On Thu, 23 Dec 2010, Jay Ashworth wrote: |>> From: "Matt Larson"<mlarson@verisign.com> |> |>> The new KSK will not be published in an authenticated manner outside |>> DNS (e.g., on an SSL-protected web page). Rather, the intended |>> mechanism for trusting the new KSK is via the signed root zone: DS |>> records corresponding to the new KSK are already present in the root |>> zone. |> |> That sounds like a policy decision... and I'm not sure I think it sounds |> like a *good* policy decision, but since no reasons were provided, it's |> difficult to tell. Actually I thought Matt went to great lengths in his original post to explain both the current landscape and the reasons why you'd want to make a change. |> Why was that decision taken, Matt? | | Having a zone's KSK statically configured on validators as a trust | anchor can lead to a world of hurt: when rolling the KSK, the zone | owner has to get everyone to update their trust anchor configuration. | In theory, the protocol described in RFC 5011 allows an operator to | signal a roll and validators will do the right thing. In practice, in | these early days, you can't count on much 5011 deployment because | implementations haven't been available for that long. | | This situation puts the operator of a popular signed zone, such as a | TLD, in a difficult position and makes KSK rolls difficult--but only | if the KSK is statically configured. Meanwhile, we now have a | perfectly good signed root zone that can vouch for any TLD's KSK. As | a result, as the impending registry operator for .gov, VeriSign | doesn't want to encourage static configuration of the .gov KSK as a | trust anchor. Such static configuration would be made easier and | implicitly condoned if the .gov KSK were published and authenticatable | outside of DNS. To the extent my opinion counts for anything, this all sounds perfectly reasonable to me. Now OTOH if someone wants to demonstrate the value in having a publication channel for TLD DNSKEYs outside of the root zone, I'm certainly willing to listen. Just be forewarned that you will have an uphill battle in trying to prove your case. :) Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJNGj1eAAoJEFzGhvEaGryE6BAH/3rIXuCIxl3YDvw5NysbbO+S mbrYHl5ISaYxMBemXtZcqkN+MU2V62mFx1Oj7f0W0t59QZxn6l9/yUrGvvpZszr/ AIaoiYJ+gMx/OO6l8UZ1nfX7lb2UEAoLEL3kxkr4f0hpengT9H+7j/Uj7w0kQGD0 rJ98LnDFdQzegFAISKb9kHgDdUtLI7/hYFCquvZFWVzobkzh4/TdDYIyE2nidASc 5FgDf3wuEpJHWFkTvG/W34UTQA6o4D+3ffrOSERxFugWddsBiMvfk+JfTek962wM fLN0IKl3xVkwL/fLX7g1aLf2FBb+SH+FWXXAPx7eXcr3NYKug5OryqE6ORiorUE= =nMlB -----END PGP SIGNATURE-----
On Tue, Dec 28, 2010 at 11:41:18AM -0800, Doug Barton wrote:
Now OTOH if someone wants to demonstrate the value in having a publication channel for TLD DNSKEYs outside of the root zone, I'm certainly willing to listen. Just be forewarned that you will have an uphill battle in trying to prove your case. :)
Doug
well, not to pick on you, or the choices made by VSGN, but I -will- point out that there are many good reasons to support an out of band method for moving critical data. (lots of refs on the tradeoffs btwn OOB and IB channels are to be found by your fav search engine). the Internet of last century relied in most cases on in-band communications. and what we have seen is the creation of overlays or outright independent "control plane" or C&C networks to manage data flow with independent prioritization over other traffic as the Internet has evolved. In this case i think this DNSiSEC model is about 15 years behind the curve. IMHO, key management should be able to use an OOB channel when the in-band is corrupted or overlaoded. Reliance on strictly the IB channel presumes there will be no problems with that channel. EVER. For me, I don't want to take that risk. YMMV of course. I can't presume that you (or anyone else) share my values regarding system resilience. For me, the choice made by VSGN in regards to this zone presuposes bullet-proof and DDOS proof communications between servers. No packet overloads, no out of memory conditions, no link saturation, etc. I appreciate that some might think they live in such a world. I hope that you and VSGN are lucky. As for myself, I'm making plans to have more control over my DNS verification destiny. If this "proves" my case to you, wonderful! If not, no sweat, we'll agree to disagree. --bill
On 12/28/2010 14:46, bmanning@vacation.karoshi.com wrote:
On Tue, Dec 28, 2010 at 11:41:18AM -0800, Doug Barton wrote:
Now OTOH if someone wants to demonstrate the value in having a publication channel for TLD DNSKEYs outside of the root zone, I'm certainly willing to listen. Just be forewarned that you will have an uphill battle in trying to prove your case. :)
Doug
well, not to pick on you, or the choices made by VSGN, but I -will- point out that there are many good reasons to support an out of band method for moving critical data. (lots of refs on the tradeoffs btwn OOB and IB channels are to be found by your fav search engine).
... and while as a general principle I tend to agree with you, I was pretty specific in what I asked for.
the Internet of last century relied in most cases on in-band communications.
Actually I think I can make a pretty convincing argument that the Internet of last century relied almost entirely on certain individuals meeting face to face at IETF, RIR, and other meetings. But with respect to the season I will attempt to be charitable.
and what we have seen is the creation of overlays or outright independent "control plane" or C&C networks to manage data flow with independent prioritization over other traffic as the Internet has evolved. In this case i think this DNSiSEC model is about 15 years behind the curve.
IMHO, key management should be able to use an OOB channel when the in-band is corrupted or overlaoded. Reliance on strictly the IB channel presumes there will be no problems with that channel. EVER. For me, I don't want to take that risk. YMMV of course.
I'm not sure I agree that an OOB channel would be useful here, even given your premise. Yes, to some extent DNS is distributed, but I think the degree of fate-sharing that is inherent in the system makes the OOB validation scheme _for TLD DNSKEYs_ (which, again, is what I asked about) at best useless, and at worst a giant waste of everyone's time to try and do well.
I can't presume that you (or anyone else) share my values
You could have just stopped here. :)
regarding system resilience. For me, the choice made by VSGN in regards to this zone presuposes bullet-proof and DDOS proof communications between servers. No packet overloads, no out of memory conditions, no link saturation, etc. I appreciate that some might think they live in such a world. I hope that you and VSGN are lucky. As for myself, I'm making plans to have more control over my DNS verification destiny.
If this "proves" my case to you, wonderful! If not, no sweat, we'll agree to disagree.
Good plan. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On 28 Dec 2010, at 22:46, bmanning@vacation.karoshi.com wrote:
IMHO, key management should be able to use an OOB channel when the in-band is corrupted or overlaoded. Reliance on strictly the IB channel presumes there will be no problems with that channel. EVER. For me, I don't want to take that risk. YMMV of course.
If normal DNS resolution fails to work then there's no point in getting the keys from another source since there's no data for them to validate. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
On Wed, Dec 29, 2010 at 02:56:35PM +0000, Tony Finch wrote:
On 28 Dec 2010, at 22:46, bmanning@vacation.karoshi.com wrote:
IMHO, key management should be able to use an OOB channel when the in-band is corrupted or overlaoded. Reliance on strictly the IB channel presumes there will be no problems with that channel. EVER. For me, I don't want to take that risk. YMMV of course.
If normal DNS resolution fails to work then there's no point in getting the keys from another source since there's no data for them to validate.
oh resoultion works a treat. its the validation that gets hosed. :) --bill
----- Original Message -----
From: "Doug Barton" <dougb@dougbarton.us>
Now OTOH if someone wants to demonstrate the value in having a publication channel for TLD DNSKEYs outside of the root zone, I'm certainly willing to listen. Just be forewarned that you will have an uphill battle in trying to prove your case. :)
If you do not, then your clients have little hope of spotting insider malfeasance changes, no? Or aren't such changes practical for other reasons which I don't understand, not being a DNSSEC maven? Cheers, -- jra
Jay Ashworth <jra@baylink.com> writes:
----- Original Message -----
From: "Doug Barton" <dougb@dougbarton.us>
Now OTOH if someone wants to demonstrate the value in having a publication channel for TLD DNSKEYs outside of the root zone, I'm certainly willing to listen. Just be forewarned that you will have an uphill battle in trying to prove your case. :)
If you do not, then your clients have little hope of spotting insider malfeasance changes, no?
Or aren't such changes practical for other reasons which I don't understand, not being a DNSSEC maven?
Can you provide us a scenario? -r
On 29 Dec 2010, at 03:27, Jay Ashworth <jra@baylink.com> wrote:
If you do not, then your clients have little hope of spotting insider malfeasance changes, no?
No cryptography can expose the difference between data that is correctly signed by the proper procedures and data that is correctly signed by a corrupt procedure. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
On Wed, 29 Dec 2010 15:01:41 GMT, Tony Finch said:
No cryptography can expose the difference between data that is correctly signed by the proper procedures and data that is correctly signed by a corrupt procedure.
Amen... Well, it *would* help detect an intruder that's smart enough to subvert the signing of the zones on the DNS server, but unable to also subvert the copy stored on some FTP site. Rather esoteric threat model, fast approaching the "Did you remember to take your meds?" level. Plus, if you're worried about foobar.com's zone being maliciously signed, do you *really* want to follow a pointer to www.foobar.com to fetch another copy? :)
On Wed, Dec 29, 2010 at 11:15:02AM -0500, Valdis.Kletnieks@vt.edu wrote:
On Wed, 29 Dec 2010 15:01:41 GMT, Tony Finch said:
No cryptography can expose the difference between data that is correctly signed by the proper procedures and data that is correctly signed by a corrupt procedure.
Amen...
Well, it *would* help detect an intruder that's smart enough to subvert the signing of the zones on the DNS server, but unable to also subvert the copy stored on some FTP site. Rather esoteric threat model, fast approaching the "Did you remember to take your meds?" level.
presuposes the attack was server directed. the DNS-sniper will take out your locally configured root KSK &/or replace it w/ their own. no need to "carpet-bomb" all users of the vt.edu caches - right?
Plus, if you're worried about foobar.com's zone being maliciously signed, do you *really* want to follow a pointer to www.foobar.com to fetch another copy? :)
who intimated that the OOB channel would be http? since that is based on the DNS, i'd like to think it was suspect as well. :) --bill
On 29 Dec 2010, at 16:56, bmanning@vacation.karoshi.com wrote:
presuposes the attack was server directed. the DNS-sniper will take out your locally configured root KSK &/or replace it w/ their own.
If they can do that then you have MUCH bigger problems than authenticity of DNS replies. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
----- Original Message -----
From: "Matt Larson" <mlarson@verisign.com>
On Thu, 23 Dec 2010, Jay Ashworth wrote:
From: "Matt Larson" <mlarson@verisign.com>
The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone.
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell.
Why was that decision taken, Matt?
Having a zone's KSK statically configured on validators as a trust anchor can lead to a world of hurt: when rolling the KSK, the zone owner has to get everyone to update their trust anchor configuration. In theory, the protocol described in RFC 5011 allows an operator to signal a roll and validators will do the right thing. In practice, in these early days, you can't count on much 5011 deployment because implementations haven't been available for that long.
Yes, I'd gathered that.
This situation puts the operator of a popular signed zone, such as a TLD, in a difficult position and makes KSK rolls difficult--but only if the KSK is statically configured. Meanwhile, we now have a perfectly good signed root zone that can vouch for any TLD's KSK. As a result, as the impending registry operator for .gov, VeriSign doesn't want to encourage static configuration of the .gov KSK as a trust anchor. Such static configuration would be made easier and implicitly condoned if the .gov KSK were published and authenticatable outside of DNS.
Ok, having re-read this a third time, now on a full sized screen, I guess I see what you're driving at: you don't *want* an out-of-band auth channel, *because people will use it*.
Note that the situation is the same today with the signed .net zone (and will be the same for the .com zone when it is signed in Q1 of 2011): the .net KSK is intentionally not published outside DNS. The path to trusting that key is via the signed DS record corresponding to it in the root zone.
Just remember what Lazarus Long said: "put all your eggs in one basket, certainly. But make sure it's a *very good* basket." Cheers, -- jr 'where am I going? And why am I in this handbasket?' a
* Jay Ashworth:
----- Original Message -----
From: "Matt Larson" <mlarson@verisign.com>
The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone.
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell.
I don't know if it influenced the policy decision, but as it is currently specified, the protocol ensures that configuring an additional trust anchor never decreases availability when you've also got the root trust anchor configured, it can only increase it. This means that there is little reason to configure such a trust anchor, especially in the present scenario.
Clearly this will require 3 years of subcommittee conferences in order to prove. .j On Sun, Dec 26, 2010 at 11:23, Florian Weimer <fw@deneb.enyo.de> wrote:
* Jay Ashworth:
----- Original Message -----
From: "Matt Larson" <mlarson@verisign.com>
The new KSK will not be published in an authenticated manner outside DNS (e.g., on an SSL-protected web page). Rather, the intended mechanism for trusting the new KSK is via the signed root zone: DS records corresponding to the new KSK are already present in the root zone.
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell.
I don't know if it influenced the policy decision, but as it is currently specified, the protocol ensures that configuring an additional trust anchor never decreases availability when you've also got the root trust anchor configured, it can only increase it. This means that there is little reason to configure such a trust anchor, especially in the present scenario.
----- Original Message -----
From: "Florian Weimer" <fw@deneb.enyo.de>
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell.
I don't know if it influenced the policy decision, but as it is currently specified, the protocol ensures that configuring an additional trust anchor never decreases availability when you've also got the root trust anchor configured, it can only increase it. This means that there is little reason to configure such a trust anchor, especially in the present scenario.
Not being a DNSSEC maven, the idea that there was no out-of-band way to confirm what the in-band method was telling you seemed bad to me; Matt's explanation, OTOH, seems sensible. Cheers, -- jra
Date: Tue, 28 Dec 2010 21:17:57 -0500 (EST) From: Jay Ashworth <jra@baylink.com>
----- Original Message -----
From: "Florian Weimer" <fw@deneb.enyo.de>
That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell.
I don't know if it influenced the policy decision, but as it is currently specified, the protocol ensures that configuring an additional trust anchor never decreases availability when you've also got the root trust anchor configured, it can only increase it. This means that there is little reason to configure such a trust anchor, especially in the present scenario.
Not being a DNSSEC maven, the idea that there was no out-of-band way to confirm what the in-band method was telling you seemed bad to me; Matt's explanation, OTOH, seems sensible.
There is no reason that you could not do OOB transfers of keys, but it would be so cumbersome with the need to maintain keys for every TLD (and, for that matter, every zone under them) and deal with key rolls at random intervals and confirm that the new keys you were getting were, in fact legitimate would be more than overwhelming. It just does not scale. DNSSEC(bis) was designed to deal with this by being able to cryptographically confirm that all data is valid and all keys are legitimate as long as you have the root key. I am not about to go into how all of this is accomplished, but it does. Some parts of it are still a bit fragile, but the basic DNSSEC spec is now very solid and the implementations of it are getting to pretty good. (Can hardly wait for BIND 10!) I think the DNSSEC spec is a very good basket and I hope that the current implementations are, as well. At least I am very confident that they will fail-safe. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
---- Original Message -----
From: "Kevin Oberman" <oberman@es.net>
There is no reason that you could not do OOB transfers of keys, but it would be so cumbersome with the need to maintain keys for every TLD (and, for that matter, every zone under them) and deal with key rolls at random intervals and confirm that the new keys you were getting were, in fact legitimate would be more than overwhelming. It just does not scale.
I apologize; I was not clear. I was not suggesting OOB *production transfer of keying information*. I was rather suggesting that an additional publication of the keys, in an authenticatable manner, which could be used by anyone who believed that Something Hincky might be going on to confirm or deny, might be useful. Cheers, -- jra
Date: Tue, 28 Dec 2010 22:34:20 -0500 (EST) From: Jay Ashworth <jra@baylink.com>
---- Original Message -----
From: "Kevin Oberman" <oberman@es.net>
There is no reason that you could not do OOB transfers of keys, but it would be so cumbersome with the need to maintain keys for every TLD (and, for that matter, every zone under them) and deal with key rolls at random intervals and confirm that the new keys you were getting were, in fact legitimate would be more than overwhelming. It just does not scale.
I apologize; I was not clear.
I was not suggesting OOB *production transfer of keying information*.
I was rather suggesting that an additional publication of the keys, in an authenticatable manner, which could be used by anyone who believed that Something Hincky might be going on to confirm or deny, might be useful.
Ahh. I did miss your point and I suspect others (other than Bill) might have, as well. Yes, having a verifiable source of keys OOB might have a small bit of value, but, assuming we get general adoption of RFC 5011, I think it's pretty limited value. Of course, this begs the question, how do we do a better job of verifying the keys received out of band than the root zone does of verifying the keys? Sort of a chicken and egg problem. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Tue, Dec 28, 2010 at 08:07:22PM -0800, Kevin Oberman wrote:
Yes, having a verifiable source of keys OOB might have a small bit of value, but, assuming we get general adoption of RFC 5011, I think it's pretty limited value. Of course, this begs the question, how do we do a better job of verifying the keys received out of band than the root zone does of verifying the keys? Sort of a chicken and egg problem. -- R. Kevin Oberman, Network Engineer
presumes RFC 5011 is viable. fall outside the 30day window and your screwed. :) that said, what folks came up w/ for the root key roll might be a useful template, e.g. the use of TCR's and use an M/N assurance check - in those rare cases where your just foobarr'ed and you can't take your servers into the SCIF to rekey. and/or an alternative to the strict timing constraints in RFC 5011 with a protocol that gives more leyway for a node being offline over a keyroll interval. There -should- be a functional equivalent of OTAR for DNSSEC keys that is not constrained to a tight window... IMHO of course. --bill
participants (10)
-
bmanning＠vacation.karoshi.com -
Doug Barton -
Florian Weimer -
jamie rishaw -
Jay Ashworth -
Kevin Oberman -
Matt Larson -
Robert E. Seastrom -
Tony Finch -
Valdis.Kletnieks＠vt.edu