From cet1 at cam.ac.uk  Tue Feb 12 16:52:33 2019
From: cet1 at cam.ac.uk (Chris Thompson)
Date: 12 Feb 2019 16:52:33 +0000
Subject: [ksk-rollover] Increased DNSKEY queries to the root servers
 since the KSK-2010 revocation
In-Reply-To: <7441567E-1C75-4DFA-8278-4B54186AB5E2@icann.org>
References: <7441567E-1C75-4DFA-8278-4B54186AB5E2@icann.org>
Message-ID: <Prayer.1.3.5.1902121652330.15074@hermes-2.csi.cam.ac.uk>

On Jan 15 2019, Paul Hoffman wrote:

>Greetings again. Soon after the new DNSKEY RRset was published at 1400 UTC
>on 11 January 2019 with KSK-2010 revoked, there was a noticeable increase
>in ./IN/DNSKEY queries sent to root servers.

[much detail omitted here]

>The ICANN organization is evaluating the traffic at the L-root to try to
>characterize the resolvers that are rapidly asking for the root's DNSKEY
>RRset. From this, we can determine if we are able to help the operators
>of those resolvers to remediate this anomalous behavior. We will also
>share data with other root server operators who are conducting similar
>investigations. The results will be reported when our analysis is complete.

A month on, is there anything more known about this? In particular, for
how long did the increased DNSKEY query rate continue?

-- 
Chris Thompson
Email: cet1 at cam.ac.uk

From roy at dnss.ec  Tue Feb 12 17:12:35 2019
From: roy at dnss.ec (Roy Arends)
Date: Tue, 12 Feb 2019 17:12:35 +0000
Subject: [ksk-rollover] Increased DNSKEY queries to the root servers
 since the KSK-2010 revocation
In-Reply-To: <Prayer.1.3.5.1902121652330.15074@hermes-2.csi.cam.ac.uk>
References: <7441567E-1C75-4DFA-8278-4B54186AB5E2@icann.org>
 <Prayer.1.3.5.1902121652330.15074@hermes-2.csi.cam.ac.uk>
Message-ID: <44EDF9CD-211D-460B-AAA8-A356BE710EDC@dnss.ec>

I gave a presentation on this at FOSDEM.

https://fosdem.org/2019/schedule/event/dns_ksk_2010_revoke_monitoring/

There is still no decline. There is a slight increase since the revoke.

Roy



> On 12 Feb 2019, at 16:52, Chris Thompson <cet1 at cam.ac.uk> wrote:
> 
> On Jan 15 2019, Paul Hoffman wrote:
> 
>> Greetings again. Soon after the new DNSKEY RRset was published at 1400 UTC
>> on 11 January 2019 with KSK-2010 revoked, there was a noticeable increase
>> in ./IN/DNSKEY queries sent to root servers.
> 
> [much detail omitted here]
> 
>> The ICANN organization is evaluating the traffic at the L-root to try to
>> characterize the resolvers that are rapidly asking for the root's DNSKEY
>> RRset. From this, we can determine if we are able to help the operators
>> of those resolvers to remediate this anomalous behavior. We will also
>> share data with other root server operators who are conducting similar
>> investigations. The results will be reported when our analysis is complete.
> 
> A month on, is there anything more known about this? In particular, for
> how long did the increased DNSKEY query rate continue?
> 
> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover


From session-request at ietf.org  Tue Feb 19 18:54:13 2019
From: session-request at ietf.org (IETF Meeting Session Request Tool)
Date: Tue, 19 Feb 2019 10:54:13 -0800
Subject: [ksk-rollover] ksk - New Meeting Session Request for IETF 104
Message-ID: <155060245330.20759.17576804032858743783.idtracker@ietfa.amsl.com>



A new meeting session request has just been submitted by Liz Flynn, on behalf of the ksk working group.


---------------------------------------------------------
Working Group Name: KSK Futures
Area Name: Operations and Management Area
Session Requester: Liz Flynn

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: dnsop dprive lamps saag git




People who must be present:
  Paul E. Hoffman
  Warren &quot;Ace&quot; Kumari

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From kim.davies at iana.org  Tue Feb 19 23:22:49 2019
From: kim.davies at iana.org (Kim Davies)
Date: Tue, 19 Feb 2019 23:22:49 +0000
Subject: [ksk-rollover] Future rollover planning opportunities
Message-ID: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>

Colleagues,

We are continuing to implement the final phases of the KSK-2017 rollover for the DNS Root Zone.

While there are no plans to immediately schedule any subsequent planned rollover, we recognize this is a good opportunity to gather feedback while everyone?s experience with this rollover is still fresh in mind. Feedback from the community will inform our future strategy.

We welcome feedback, particularly to this list, on what should be considered in designing the process for performing future rollovers. We are also planning to hold a number of outreach efforts in the coming months to capture further input. These sessions are being led by the ICANN?s Office of the Chief Technology Officer (OCTO) in coordination with IANA staff. These sessions will be at:


  *   ICANN 64 in Kobe, as part of the DNSSEC workshop;
  *   IETF 104 in Prague, as a proposed BOF; and
  *   The 3rd ICANN DNS Symposium in Bangkok

The feedback we receive will be used by the IANA team to develop a draft plan later in the year that we intend to share for public review.

Thanks in advance.

kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190219/e62dc963/attachment.html>

From fred at isc.org  Wed Feb 20 00:42:02 2019
From: fred at isc.org (Fred Baker)
Date: Tue, 19 Feb 2019 16:42:02 -0800
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
Message-ID: <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>

ISC put about ten hours into the recent rollover - validating and testing, etc. To our way to thinking, the roll-over was far more of an event for the resolvers than it was for us. That probably says something about the frequency of roll-over events - if they were happening daily or weekly and we were putting ten hours into each event, we would begin to be concerned, but if they happened quarterly or annually we don't think we would be bothered - and might even think it was a good idea.

The key consideration is that key rollovers are a "usual" event, and as such the key(s) should be something learned from the root and the root servers, not something configured or compiled into the resolver software.

> On Feb 19, 2019, at 3:22 PM, Kim Davies <kim.davies at iana.org> wrote:
> 
> Colleagues,
>  
> We are continuing to implement the final phases of the KSK-2017 rollover for the DNS Root Zone.
>  
> While there are no plans to immediately schedule any subsequent planned rollover, we recognize this is a good opportunity to gather feedback while everyone?s experience with this rollover is still fresh in mind. Feedback from the community will inform our future strategy.
>  
> We welcome feedback, particularly to this list, on what should be considered in designing the process for performing future rollovers. We are also planning to hold a number of outreach efforts in the coming months to capture further input. These sessions are being led by the ICANN?s Office of the Chief Technology Officer (OCTO) in coordination with IANA staff. These sessions will be at:
>  
> 	? ICANN 64 in Kobe, as part of the DNSSEC workshop;
> 	? IETF 104 in Prague, as a proposed BOF; and
> 	? The 3rd ICANN DNS Symposium in Bangkok
>  
> The feedback we receive will be used by the IANA team to develop a draft plan later in the year that we intend to share for public review.
>  
> Thanks in advance.
>  
> kim
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover


From dot at dotat.at  Wed Feb 20 12:29:59 2019
From: dot at dotat.at (Tony Finch)
Date: Wed, 20 Feb 2019 12:29:59 +0000
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
Message-ID: <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>

Fred Baker <fred at isc.org> wrote:
>
> The key consideration is that key rollovers are a "usual" event, and as
> such the key(s) should be something learned from the root and the root
> servers, not something configured or compiled into the resolver
> software.

However there has to be a bootstrap mechanism, and the only one available
is for the validator vendor to provide an initial key set.

I agree that rollovers need to be routine (I think annual makes sense) but
they have to be planned with software releases in mind. This might require
keys to be generated and promulgated out of band a long time before they
are published in the zone or used for signing. Then a vendor package can
include root keys covering the next couple of years, say.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
promote human rights and open government

From gih at apnic.net  Wed Feb 20 17:58:29 2019
From: gih at apnic.net (Geoff Huston)
Date: Wed, 20 Feb 2019 17:58:29 +0000
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
Message-ID: <3363FF72-6066-416D-B158-0059736DE2F0@apnic.net>



> On 20 Feb 2019, at 4:29 am, Tony Finch <dot at dotat.at> wrote:
> 
> Fred Baker <fred at isc.org> wrote:
>> 
>> The key consideration is that key rollovers are a "usual" event, and as
>> such the key(s) should be something learned from the root and the root
>> servers, not something configured or compiled into the resolver
>> software.
> 
> However there has to be a bootstrap mechanism, and the only one available
> is for the validator vendor to provide an initial key set.
> 
> I agree that rollovers need to be routine (I think annual makes sense) but
> they have to be planned with software releases in mind. This might require
> keys to be generated and promulgated out of band a long time before they
> are published in the zone or used for signing. Then a vendor package can
> include root keys covering the next couple of years, say.
> 

There is something in your note Tony that I feel I should comment on. It gets 
to the heart of why the key gets rolled at all, in my view.

I could offer the view that there is a prevalent feeling (perhaps irrationally 
- who knows) that a very long-held key will get compromised at some time. Either
the tools to break the key will improve, or access to the key will no longer
work, or some other mishap. It seems foolhardy not to have some exercised
plan to roll the key to respond to such potential eventualities when or if the
unplanned disaster happens and we need to roll the key.

But then we enter into the next phase of the thinking - if we plan to roll the key
at some time in response to some operational incident then we probably
need to rehearse this plan.

And so we have this extended exercise of using RFC5011 to transition the key.
The plan has two parts - an extended ?introduction? of the new key and a
key switch. The procedure we use at present is a planned introduction and a planned
switch. 

If I were to guess at the thinking here, the plan is to allow us to decouple
this slightly - i.e. to introduce a backup key in a planned fashion and
to be able to switch keys either as planned process or in response to some
situation that compromises the current working key in some manner.

Your note seems to head down the path of planned switches, whereas I would offer
the view that the overall object here is to carefully rehearse the introduction
of backup keys, with the aim to be able to perform a key switch to a live backup 
with less notice than years or even months, if the need arises. While planning
key switches well in advance sounds like a decent approach, we should not fall
into the trap of thinking that the only way to perform a switch to a live backup 
is with such advance notice every time. 

my 2c anyway

 Geoff



From sm+icann at elandsys.com  Wed Feb 20 18:35:43 2019
From: sm+icann at elandsys.com (S Moonesamy)
Date: Wed, 20 Feb 2019 10:35:43 -0800
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <3363FF72-6066-416D-B158-0059736DE2F0@apnic.net>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <3363FF72-6066-416D-B158-0059736DE2F0@apnic.net>
Message-ID: <6.2.5.6.2.20190220102258.0b920b88@elandnews.com>

Hi Geoff, Tony,
At 09:58 AM 20-02-2019, Geoff Huston wrote:
>There is something in your note Tony that I feel I should comment on. It gets
>to the heart of why the key gets rolled at all, in my view.
>
>I could offer the view that there is a prevalent feeling (perhaps 
>irrationally
>- who knows) that a very long-held key will get compromised at some 
>time. Either
>the tools to break the key will improve, or access to the key will no longer
>work, or some other mishap. It seems foolhardy not to have some exercised
>plan to roll the key to respond to such potential eventualities when or if the
>unplanned disaster happens and we need to roll the key.

Please see Section 4.5 of the DPS.  A "roll-over often" approach may 
have to take that into consideration.

Regards,
S. Moonesamy 


From mcr+ietf at sandelman.ca  Wed Feb 20 18:39:41 2019
From: mcr+ietf at sandelman.ca (Michael Richardson)
Date: Wed, 20 Feb 2019 13:39:41 -0500
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
Message-ID: <5330.1550687981@localhost>


Tony Finch <dot at dotat.at> wrote:
    > Fred Baker <fred at isc.org> wrote:
    >>
    >> The key consideration is that key rollovers are a "usual" event, and as
    >> such the key(s) should be something learned from the root and the root
    >> servers, not something configured or compiled into the resolver
    >> software.

+1

    > I agree that rollovers need to be routine (I think annual makes sense) but
    > they have to be planned with software releases in mind. This might require
    > keys to be generated and promulgated out of band a long time before they
    > are published in the zone or used for signing. Then a vendor package can
    > include root keys covering the next couple of years, say.

I think that there is very little incremental cost to including a multitude
of keys in a software release.  i.e. rather than 1 or 3 for the next 3-4
years,  I'd like to around a dozen.  With a variety of algorithms, keysizes,
and with the private keys escrowed in a variety of ways.  Some will be
expired without ever been used... they are just in case, or in support of
as-yet-unknown contingencies.   (including fire-drills for such switches)
I'd like for this to include a hash-based signature system, but I'm not sure
we have the standards specifications for this nailed down sufficiently.

Yes, there is some non-trivial cost for the root-zone key holder to keep more
private keys safe.  It is my understanding that the ICANN software for this
is being revised to be significantly more flexible, and so I also see this as
a way to make sure it all really works.

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190220/27d146b2/signature.asc>

From housley at vigilsec.com  Wed Feb 20 18:53:00 2019
From: housley at vigilsec.com (Russ Housley)
Date: Wed, 20 Feb 2019 13:53:00 -0500
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <5330.1550687981@localhost>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5330.1550687981@localhost>
Message-ID: <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>



> On Feb 20, 2019, at 1:39 PM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:
> 
> Tony Finch <dot at dotat.at> wrote:
>> Fred Baker <fred at isc.org> wrote:
>>> 
>>> The key consideration is that key rollovers are a "usual" event, and as
>>> such the key(s) should be something learned from the root and the root
>>> servers, not something configured or compiled into the resolver
>>> software.
> 
> +1
> 
>> I agree that rollovers need to be routine (I think annual makes sense) but
>> they have to be planned with software releases in mind. This might require
>> keys to be generated and promulgated out of band a long time before they
>> are published in the zone or used for signing. Then a vendor package can
>> include root keys covering the next couple of years, say.
> 
> I think that there is very little incremental cost to including a multitude
> of keys in a software release.  i.e. rather than 1 or 3 for the next 3-4
> years,  I'd like to around a dozen.  With a variety of algorithms, keysizes,
> and with the private keys escrowed in a variety of ways.  Some will be
> expired without ever been used... they are just in case, or in support of
> as-yet-unknown contingencies.   (including fire-drills for such switches)
> I'd like for this to include a hash-based signature system, but I'm not sure
> we have the standards specifications for this nailed down sufficiently.

There are two hash-based signature schemes that have been reviewed by the IRTF CFRG, one is already and RFC and the other is in the RFC Editor queue.  Both of them have huge signature values, which would be an interesting challenge in the DNSSEC environment.

I think we should be using hash-based signatures to sign software and firmware.  They will give us authentication and integrity protection even if a large-scale quantum computer gets invented soon.  That will allow us to deploy the next generation when we know what that looks like (see https://csrc.nist.gov/projects/post-quantum- <https://csrc.nist.gov/projects/post-quantum-cryptography>cryptography <https://csrc.nist.gov/projects/post-quantum-cryptography>).
Russ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190220/ba16a536/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190220/ba16a536/signature-0001.asc>

From paul at nohats.ca  Wed Feb 20 19:09:48 2019
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 20 Feb 2019 14:09:48 -0500 (EST)
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5330.1550687981@localhost>
 <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>
Message-ID: <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>

On Wed, 20 Feb 2019, Russ Housley wrote:

> I think that there is very little incremental cost to including a multitude
> of keys in a software release. ?i.e. rather than 1 or 3 for the next 3-4
> years, ?I'd like to around a dozen. ?With a variety of algorithms, keysizes,
> and with the private keys escrowed in a variety of ways.

That makes monitoring and transparency recoding of private key usage
much harder.  It also raises the possibly abuse of any DNSSEC key to the
weakest key escrow method, and will surely raise lots of red flags with
people who already don't trust this system.

One of our arguments now is that if Verisign or ICANN abuses its key
holding power, they will go down (commercially or non-commercially) and
so they have a strong incentive not to blindly accept NSLs. When we have
multiple escrow parties, its easy to sacrifice one. So this is
detrimental to the security of the system as a whole.

> I'd like for this to include a hash-based signature system, but I'm not sure
> we have the standards specifications for this nailed down sufficiently.

Please experiment locally, not globally. Kthanks :)

Paul

From matt.larson at icann.org  Wed Feb 20 19:31:49 2019
From: matt.larson at icann.org (Matt Larson)
Date: Wed, 20 Feb 2019 19:31:49 +0000
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5330.1550687981@localhost>
 <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>
 <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>
Message-ID: <0FD35453-ECA5-45E0-AD3A-DF0205335437@icann.org>

Please note that the text Paul quotes is from Michael Richardson, not Russ Housley.

> On Feb 20, 2019, at 2:09 PM, Paul Wouters <paul at nohats.ca> wrote:
> 
> On Wed, 20 Feb 2019, Russ Housley wrote:
> 
>> I think that there is very little incremental cost to including a multitude
>> of keys in a software release.  i.e. rather than 1 or 3 for the next 3-4
>> years,  I'd like to around a dozen.  With a variety of algorithms, keysizes,
>> and with the private keys escrowed in a variety of ways.
> 
> That makes monitoring and transparency recoding of private key usage
> much harder.  It also raises the possibly abuse of any DNSSEC key to the
> weakest key escrow method, and will surely raise lots of red flags with
> people who already don't trust this system.
> 
> One of our arguments now is that if Verisign or ICANN abuses its key
> holding power, they will go down (commercially or non-commercially) and
> so they have a strong incentive not to blindly accept NSLs. When we have
> multiple escrow parties, its easy to sacrifice one. So this is
> detrimental to the security of the system as a whole.
> 
>> I'd like for this to include a hash-based signature system, but I'm not sure
>> we have the standards specifications for this nailed down sufficiently.
> 
> Please experiment locally, not globally. Kthanks :)
> 
> Paul
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover


From paul at nohats.ca  Wed Feb 20 20:04:22 2019
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 20 Feb 2019 15:04:22 -0500 (EST)
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <0FD35453-ECA5-45E0-AD3A-DF0205335437@icann.org>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5330.1550687981@localhost>
 <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>
 <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>
 <0FD35453-ECA5-45E0-AD3A-DF0205335437@icann.org>
Message-ID: <alpine.LRH.2.21.1902201500190.12605@bofh.nohats.ca>

On Wed, 20 Feb 2019, Matt Larson wrote:

> Subject: Re: [ksk-rollover] Future rollover planning opportunities
> 
> Please note that the text Paul quotes is from Michael Richardson, not Russ Housley.

Indeed. It seems Russ's client quoting was incompatible with my client's
ability to detect it was quoted, and it all appeared as written by him. A
source check reveals Russ only included an HTML copy and not a ascii/text
version in his reply. When I open the HTML manually, the quoting looks
okay.

Oh standards, they work so well :)

Paul

From peter.van.dijk at powerdns.com  Wed Feb 20 20:06:06 2019
From: peter.van.dijk at powerdns.com (Peter van Dijk)
Date: Wed, 20 Feb 2019 21:06:06 +0100
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
Message-ID: <5A3DDE75-8DD6-4F36-8F31-D8E1DF328F46@powerdns.com>

On 20 Feb 2019, at 13:29, Tony Finch wrote:

> However there has to be a bootstrap mechanism, and the only one 
> available
> is for the validator vendor to provide an initial key set.

If it can provide an initial key set, it can also provide a current key 
set. See below :)

> I agree that rollovers need to be routine (I think annual makes sense) 
> but
> they have to be planned with software releases in mind.

I strongly disagree. Users have a trust relationship that everything is 
built on already - that with their software vendors. For most people, 
that is ?Debian? or ?CentOS? or perhaps ?Microsoft?. Debian 
already ships a dns-root-data package that contains the current root 
trust anchors.  This package is updated outside of any release schedules 
imposed by ISC, PowerDNS, NLnetlabs, etc.

I understand that the RedHat/CentOS/Fedora side of things also has plans 
for this, or maybe has done this meanwhile.

Please build on that relationship. It?s all we need.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

From paul at nohats.ca  Wed Feb 20 20:43:11 2019
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 20 Feb 2019 15:43:11 -0500 (EST)
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <5A3DDE75-8DD6-4F36-8F31-D8E1DF328F46@powerdns.com>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5A3DDE75-8DD6-4F36-8F31-D8E1DF328F46@powerdns.com>
Message-ID: <alpine.LRH.2.21.1902201541200.12605@bofh.nohats.ca>

On Wed, 20 Feb 2019, Peter van Dijk wrote:

> I understand that the RedHat/CentOS/Fedora side of things also has plans for 
> this, or maybe has done this meanwhile.

Currently done on a per-package basis still :(

Paul

From mcr+ietf at sandelman.ca  Wed Feb 20 21:08:06 2019
From: mcr+ietf at sandelman.ca (Michael Richardson)
Date: Wed, 20 Feb 2019 16:08:06 -0500
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5330.1550687981@localhost>
 <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>
 <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>
Message-ID: <14365.1550696886@localhost>


    mcr> I think that there is very little incremental cost to including a
    mcr> multitude of keys in a software release. ?i.e. rather than 1 or 3
    mcr> for the next 3-4 years, ?I'd like to around a dozen. ?With a variety
    mcr> of algorithms, keysizes, and with the private keys escrowed in a
    mcr> variety of ways.

Paul Wouters <paul at nohats.ca> wrote:
    > That makes monitoring and transparency recoding of private key usage
    > much harder.  It also raises the possibly abuse of any DNSSEC key to the
    > weakest key escrow method, and will surely raise lots of red flags with
    > people who already don't trust this system.

yeah, so the idea is not that it be a free-for-all, but that we might have
many more keys maintained by perhaps just one additional entity.

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190220/300fe684/signature.asc>

From paul at nohats.ca  Thu Feb 21 03:52:54 2019
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 20 Feb 2019 22:52:54 -0500 (EST)
Subject: [ksk-rollover] Future rollover planning opportunities
In-Reply-To: <14365.1550696886@localhost>
References: <7A862315-098A-4CFE-B774-0DE9B221A219@iana.org>
 <B548E007-6C42-47EB-8BE8-10C0F9233F6A@isc.org>
 <alpine.DEB.2.20.1902201223250.19193@grey.csi.cam.ac.uk>
 <5330.1550687981@localhost>
 <CD392771-26B6-4859-8420-B0D16661602F@vigilsec.com>
 <alpine.LRH.2.21.1902201405260.29336@bofh.nohats.ca>
 <14365.1550696886@localhost>
Message-ID: <alpine.LRH.2.21.1902202250580.1229@bofh.nohats.ca>

On Wed, 20 Feb 2019, Michael Richardson wrote:

> Paul Wouters <paul at nohats.ca> wrote:
>    > That makes monitoring and transparency recoding of private key usage
>    > much harder.  It also raises the possibly abuse of any DNSSEC key to the
>    > weakest key escrow method, and will surely raise lots of red flags with
>    > people who already don't trust this system.
>
> yeah, so the idea is not that it be a free-for-all, but that we might have
> many more keys maintained by perhaps just one additional entity.

That was discussed in the past too, eg by the Root Key rollover design
team. The issue with that is that it most likely means that if one key
cannot be used anymore for reason X, most likely the whole set cannot
be used anymore for the same reason. Eg if there is an issue with a RNG,
or with the HSM security, etc.

Paul