Subject: [DNSOP] Proposed changes to RFC 4641: rollovers

From: Paul Hoffman <[email-masked]>
Date: Sun, 28 Sep 2008 21:14:34 -0700

In the last paragraph of 3.1.1, remove the last sentence ("Although,
given a long enough key..."). Replace it with the following
paragraphs:
    There are two schools of thought on rolling a KSK that is not a
    trust anchor:
      - It should be done regularly (possibly every few months) so that
        a key rollover remains an operational routine.
      - It should only be done when it is known or strongly suspected
        that the key has been compromised in order to reduce the
        stability issues on systems where the rollover does not happen
        cleanly.
    There is no widespread agreement on which of these two schools of
    thought is better for different deployments of DNSSEC.  There is a
    stability cost every time a non-anchor KSK is rolled over, but it
    is possibly low if the communication between the child and the
    parent is good.  On the other hand, the only completely effective
    way to tell if the communication is good is to test it
    periodically.  Thus, rolling a KSK with a parent is only done for
    two reasons: to test and verify the rolling system to prepare for
    an emergency, and in the case of an actual emergency.

    Because of the difficulty of getting all users of a trust anchor to
    replace an old trust anchor with a new one, a KSK that is a trust
    anchor should never be rolled unless it is known or strongly
    suspected that the key has been compromised.

Remove the first paragraph of 3.3; it is now covered in 3.1.1 (and it
was wrong about the cryptography).

Change the second paragraph of 3.3 to:
    From a purely operational perspective, a reasonable key effectivity
    period for KSKs that have a parent zone is 13 months, with the
    intent to replace them after 12 months.  An intended key
    effectivity period of a month is reasonable for Zone Signing Keys.
    This annual rollover gives operational practice to rollovers.

    Ignoring the operational perspective, a reasonable effectivity
    period for KSKs that have a parent zone is 25 years or longer.
    That is, if one does not plan to test the rollover procedure, the
    key should be effective essentially forever, and then only rolled
    over in case of emergency.

In the first paragraph of 4.2, replace the first two sentences with:
    Regardless of whether a zone uses periodic key rollovers in order
    to practice for emergencies, or only rolls over keys in an
    emergency, key rollovers are a fact of life when using DNSSEC.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 29 Sep 2008 12:08:50 +0200

Hi Paul,

I encourage making the 4641 document more up to date and adding better
definitions. However, one issue draw my attention: I am not sure if
doing key rollover in emergencies only is good practice, for a couple of
reasons:

* All keys have an expected lifetime. After the lifetime, you may expect
a key to be compromised. Because you cannot easily suspect this until
harm is being done, I say its better to prevent than to fix. So do key
rollover only when the keys lifetime is running out, (inclusive) or it
is suspected that the key has been compromised.

* If keys that act as trust anchors have a long lifetime (effective
period), key rollover is hardly operated. Doing key rollover
periodically, not only for KSKs that do not act as trust anchors, gives
us more operational practice.

* Besides, you cannot know if a resolver will pick up your KSK as a
trust anchor, so you should consider that all your KSKs can be used a
trust anchor.

* Change of zonedata size or local policies might mean that a change in
KSK is made (longer key, different algorithm...)

Regards,

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 29 Sep 2008 12:08:50 +0200

Hi Paul,

Regards,

Matthijs

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 29 Sep 2008 06:23:59 -0700

>>>>> On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman <[email-masked]> said:

Overall I think the changes seem reasonable.  However, I don't think
everything is taken into account...  I understand the desire for
removing the specified timing associated with key-age based on modern
analysis.  But there are other reasons for needing to roll keys besides
just emergencies and emergency practice.  Specifically:

- algorithm changes (future algorithms may become more popular and
  supported by more tool sets than current ones)
- key length changes required due to advances in cryptographic attacks
- ownership changes (think of a zone name buy-out...  the new owner will
  certainly not want to use the same key since I doubt they'll trust the
  original owner much but they will want to use it long enough for a
  reasonable properly timed rollover to occur).
- parent relationship requirement changes (it's possible certain
  registrar's could enforce using a particular kind of key because
  that's how they're infrastructure is set up and if you change
  regiFrom [email-masked]  Mon Sep 29 06:23:46 2008
From: Wes Hardaker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Organization: Sparta
Date: Mon, 29 Sep 2008 06:23:59 -0700
Cc: [email-masked]
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers
Sender: [email-masked]

>>>>> On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman <[email-masked]> said:

Overall I think the changes seem reasonable.  However, I don't think
everything is taken into account...  I understand the desire for
removing the specified timing associated with key-age based on modern
analysis.  But there are other reasons for needing to roll keys besides
just emergencies and emergency practice.  Specifically:

- algorithm changes (future algorithms may become more popular and
  supported by more tool sets than current ones)
- key length changes required due to advances in cryptographic attacks
- ownership changes (think of a zone name buy-out...  the new owner will
  certainly not want to use the same key since I doubt they'll trust the
  original owner much but they will want to use it long enough for a
  reasonable properly timed rollover to occur).
- parent relationship requirement changes (it's possible certain
  registrar's could enforce using a particular kind of key because
  that's how they're infrastructure is set up and if you change
  restrar's you may have to change your keying attributes).

You make the assumption (in a few places) that you can control who uses
your key as a trust anchor here.  IE, if your parent is signed you
shouldn't need to worry about your key as a trust-anchor.  Although nice
in theory, it may not meet real-world operational practice.  In many
cases it is probably true that your key will not be used as a TA, in
other cases it's certainly false.

PH> Ignoring the operational perspective, a reasonable effectivity
PH> period for KSKs that have a parent zone is 25 years or longer.
                                               ^^^^^^^^
PH> That is, if one does not plan to test the rollover procedure, the
PH> key should be effective essentially forever, and then only rolled
                                        ^^^^^^^
PH> over in case of emergency.

I agree that 25 years is long.  I disagree, however, that it's safe to
round it up to forever (infinite).  Maybe wording along the lines of:
"...effective longer than most operational environments exist without
change" or something like that, which is really what you're trying to
imply by using 'forever'.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

gistrar's you may have to change your keying attributes).

You make the assumption (in a few places) that you can control who uses
your key as a trust anchor here.  IE, if your parent is signed you
shouldn't need to worry about your key as a trust-anchor.  Although nice
in theory, it may not meet real-world operational practice.  In many
cases it is probably true that your key will not be used as a TA, in
other cases it's certainly false.

PH> Ignoring the operational perspective, a reasonable effectivity
PH> period for KSKs that have a parent zone is 25 years or longer.
                                               ^^^^^^^^
PH> That is, if one does not plan to test the rollover procedure, the
PH> key should be effective essentially forever, and then only rolled
                                        ^^^^^^^
PH> over in case of emergency.

I agree that 25 years is long.  I disagree, however, that it's safe to
round it up to forever (infinite).  Maybe wording along the lines of:
"...effective longer than most operational environments exist without
change" or something like that, which is really what you're trying to
imply by using 'forever'.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 29 Sep 2008 07:43:02 -0700

----- Original Message ----- 
From: "Matthijs Mekking" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 29, 2008 3:08 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Paul,
>
> a key to be compromised.

No, it may have simply expired and so would no longer be 'in effect' but 
that doesnt mean that they 'will magically stop working' unless the code 
forces that and there is NO way to specify this without defining a 
compliance test suite that mandates this.

> Because you cannot easily suspect this until
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFI4KkyIXqNzxRs6egRAmRBAJ0ZcZGEqbSjTPb2O21IbetS24SyxwCZAcNi
> OwY52IY/ofrAzxcuAKOTP/s=
> =P3vk
> -----END PGP SIGNATURE-----

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.7.4/1695 - Release Date: 9/27/2008 
1:11 PM

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 29 Sep 2008 07:43:02 -0700

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 08:31:13 -0700

>is suspected that the key has been compromised.

I tried hard in my proposed new text to make it clear that the above 
reasoning is flawed. You cannot "expect a key to be compromised" at 
any particular time in the future. That's like predicting when 
someone will break into your house. If you have an idea about that, 
and you care what is in your house, you will add better protections.

This is not a new idea. Look at the expiration dates on the 
certificates in the trust anchor store in your browser. Many of them 
are at least twenty years from now. This is not a reflection that the 
CA thinks that their security is perfect for the next twenty years, 
then will become so bad that the secret key will be stolen.

>KSK is made (longer key, different algorithm...)

I thought I covered all of those in the proposed changes. If I 
didn't, it was a mistake. But they are just one school of thought. 
The "don't ever expire" school of thought, which is also widely held, 
is essentially the opposite.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 08:31:13 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 08:39:33 -0700

At 6:23 AM -0700 9/29/08, Wes Hardaker wrote:
>   registrar's you may have to change your keying attributes).

Good points. I would put the second and third of those into the 
"emergency" category, but not due to compromise. If people are liking 
the changes in general, adding the above would be good. It sounds 
like maybe there should be a separate sub-section on rollover theory 
instead of just two paragraphs.

>other cases it's certainly false.

This is a very good point, but I'm not sure how to deal with it in 
4641bis. If you as a key owner need to worry about this, you'll 
always have to do the harder work that trust anchors do. Maybe this 
can be mentioned a few places in the document but made part of the 
decision tree.

Now that you mention this, the opposite is also true today. TLDs who 
today need to be planning to be trust anchors due to the lack of a 
signed root also want to plan for the future when they have a parent. 
Worse, they get to deal with TARs, which are operationally halfway 
between a trust anchor and parent. This is well worth adding to 
4641bis as well.

>imply by using 'forever'.

Yes, that is a more accurate way to deal with "forever".

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Sep 2008 08:39:33 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Mon, 29 Sep 2008 11:46:12 +0000

any KSK can be used as a TA.  there is no way to know - unambigiously -
 that any given KSK is not being used as a TA in some validator.
 however, your assertion that at KSK should -never- be rolled unless
 compromise is known or strongly suspected is -BAD- from an operational 
 and liklely from a trust perspective.

 your selection of 12-13 months and 25 years are suspect. Can you provide
 the underlaying bias for these tiemframes?

--bill

---

From: [email-masked]
Date: Mon, 29 Sep 2008 11:46:12 +0000

--bill

---

From: Scott Rose <[email-masked]>
Date: Tue, 30 Sep 2008 07:07:16 -0400

> the underlaying bias for these tiemframes?

That is actually the NIST recommendations in SP 800-57 part 1  Public  
keys used for authentication should have a use lifetime of 1-2 years,  
but can be kept around a little longer to validate pre-existing  
signatures after that period.

Scott

>>     - It should only be From [email-masked]  Tue Sep 30 04:07:54 2008
From: Scott Rose <[email-masked]>
To: [email-masked]
Date: Tue, 30 Sep 2008 07:07:16 -0400
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers
Sender: [email-masked]

> the underlaying bias for these tiemframes?

That is actually the NIST recommendations in SP 800-57 part 1  Public  
keys used for authentication should have a use lifetime of 1-2 years,  
but can be kept around a little longer to validate pre-existing  
signatures after that period.

Scott

>>     - It should only be dodone when it is known or strongly suspected

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

ne when it is known or strongly suspected
>>   emergency, key rollovers are a fact of life when using DNSSEC.

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Sep 2008 07:59:29 -0700

>  the underlaying bias for these tiemframes?

The 12 month timeframe was adopted from the current 4641. I assume 
that this WG decided that, if you want to do rollovers to keep 
operational experience fresh in mind, that was the right period. 
Seems reasonable to me.

The 25 years is based on experience from the web CA field, where the 
trust anchors are likely to be protected with the same tools as those 
that 4641 suggests high-value trust anchors for DNSSEC. As Wes 
pointed out, I conflated "25 years" and "never", which was a mistake. 
I like his replacement of "...effective longer than most operational 
environments exist without change", and 25 years seems to be a 
reasonable guess at that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Sep 2008 07:59:29 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 30 Sep 2008 08:26:02 -0700

Scott
----- Original Message ----- 
From: "Scott Rose" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 30, 2008 4:07 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers

> signatures after that period.

What do you mean "Kept Around" - those keys need to be re-creatable through 
some Key Recovery Proces. especially since the master DNS Root is a direct 
piece of US Government Property until the NTIA MOU is codified in a formal 
conveyance of those Intellectual Properties. Yes I am talking about the MOU 
that NTIA wrote under Nancy Victory Esq's hand several years ago.

That said, since DNS Lookups and the records of them are key pieces of 
'evidence of activity' on the Internet or as a part of a larger private 
secure IP Network mand stem from a US Government owned DNS Root, the Root 
and its operations are constrained by FISCAM and the requiremensts of FISMA 
here...

So let me ask this, rather than ignoring the obvious why not look the use of 
DNS as a process to resolve an address and the handshaking processes in 
DNSSec provide the security model therein to meet the existing rules of 
evidence and step from there to the platform of needing to create culpable 
digital evidence that will meet the Presiding Court requirement's of any 
Nation willing to rely on this service???

This has ABSOLUTELY NOTHING to do with technology, it has to do with Social 
Process and that is the key win. We need logging of DNS Lookups that meets 
the reliable evidence requirement's put in place by the US Federal Rules of 
Civil Procedure.

Todd Glassey

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.5/1698 - Release Date: 9/29/2008 
7:25 PM

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 30 Sep 2008 08:26:02 -0700

Scott
----- Original Message ----- 
From: "Scott Rose" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 30, 2008 4:07 AM
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers

Todd Glassey

---

From: Scott Rose <[email-masked]>
Date: Tue, 30 Sep 2008 17:22:19 -0400

All of those issues relate to separate topics beyond the current scope  
of this effort.  I was only thinking of authentication for the  
protocol.  "Kept around" means there could be signatures out there  
still valid (sig validity period in the RRSIG) and in cache when the  
private portion is no longer used to generate RRSIGs.

Scott

On Sep 30, 2008, at 11:26 AM, TS Glassey wrote:

> What do you mean "Kept Around" - those keys need to be re-creatable  
> through some Key Recovery Proces. especially since the master DNS  
> Root is a direct piece of US Government Property until the NTIA MOU  
> is codified in a formal conveyance of those Intellectual Properties.  
> Yes I am talking about the MOU that NTIA wrote under Nancy Victory  
> Esq's hand several years ago.
>
> That said, since DNS Lookups and the records of them are key pieces  
> of 'evidence of activity' onFrom [email-masked]  Tue Sep 30 14:22:06 2008
From: Scott Rose <[email-masked]>
To: [email-masked]
Date: Tue, 30 Sep 2008 17:22:19 -0400
Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers
Sender: [email-masked]

All of those issues relate to separate topics beyond the current scope  
of this effort.  I was only thinking of authentication for the  
protocol.  "Kept around" means there could be signatures out there  
still valid (sig validity period in the RRSIG) and in cache when the  
private portion is no longer used to generate RRSIGs.

Scott

On Sep 30, 2008, at 11:26 AM, TS Glassey wrote:

> What do you mean "Kept Around" - those keys need to be re-creatable  
> through some Key Recovery Proces. especially since the master DNS  
> Root is a direct piece of US Government Property until the NTIA MOU  
> is codified in a formal conveyance of those Intellectual Properties.  
> Yes I am talking about the MOU that NTIA wrote under Nancy Victory  
> Esq's hand several years ago.
>
> That said, since DNS Lookups and the records of them are key pieces  
> of 'evidence of activity' on t the Internet or as a part of a larger  
> private secure IP Network mand stem from a US Government owned DNS  
> Root, the Root and its operations are constrained by FISCAM and the  
> requiremensts of FISMA here...
>
> So let me ask this, rather than ignoring the obvious why not look  
> the use of DNS as a process to resolve an address and the  
> handshaking processes in DNSSec provide the security model therein  
> to meet the existing rules of evidence and step from there to the  
> platform of needing to create culpable digital evidence that will  
> meet the Presiding Court requirement's of any Nation willing to rely  
> on this service???
>
> This has ABSOLUTELY NOTHING to do with technology, it has to do with  
> Social Process and that is the key win. We need logging of DNS  
> Lookups that meets the reliable evidence requirement's put in place  
> by the US Federal Rules of Civil Procedure.
>
> Todd Glassey
>
>>
>>
>>> --bill
>>>
>>>
>>>
> Version: 8.0.173 / Virus Database: 270.7.5/1698 - Release Date:  
> 9/29/2008 7:25 PM

he Internet or as a part of a larger  
> private secure IP Network mand stem from a US Government owned DNS  
> Root, the Root and its operations are constrained by FISCAM and the  
> requiremensts of FISMA here...
>
> So let me ask this, rather than ignoring the obvious why not look  
> the use of DNS as a process to resolve an address and the  
> handshaking processes in DNSSec provide the security model therein  
> to meet the existing rules of evidence and step from there to the  
> platform of needing to create culpable digital evidence that will  
> meet the Presiding Court requirement's of any Nation willing to rely  
> on this service???
>
> This has ABSOLUTELY NOTHING to do with technology, it has to do with  
> Social Process and that is the key win. We need logging of DNS  
> Lookups that meets the reliable evidence requirement's put in place  
> by the US Federal Rules of Civil Procedure.
>
> Todd Glassey
>
>>
>>
>>> --bill
>>>
>>>
>>>
> Version: 8.0.173 / Virus Database: 270.7.5/1698 - Release Date:  
> 9/29/2008 7:25 PM