.gov DNSSEC operational message

Mailman List Mirror (Read Only)
1

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.

2

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

3

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

4

* Jay Ashworth:

5

Clearly this will require 3 years of subcommittee conferences in order to prove.

.j

6

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. :slight_smile:

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. :slight_smile: http://SupersetSolutions.com/

7

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

8

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. :slight_smile:

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. :slight_smile:

  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

9

From: "Matt Larson" <mlarson@verisign.com>

> > 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

10

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

11

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

12

Jay Ashworth <jra@baylink.com> writes:

13

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.

14

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.

15

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? :slight_smile:

16

oh resoultion works a treat. its the validation that gets hosed. :slight_smile:

--bill

17

> 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? :slight_smile:

  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. :slight_smile:

--bill

18

If they can do that then you have MUCH bigger problems than authenticity of DNS replies.

Tony.

19

Bill Manning saith:

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. :slight_smile:

No it's not, Bill, not *necessarily*; you know better than that. :slight_smile:

Cheers,
-- jra