[dns-operations] Why roll the KSK? (was Sad news today: systemd-resolved to be deployed in Ubuntu 16.10)

Shane Kerr shane at time-travellers.org
Mon Jun 6 10:35:22 UTC 2016


Ondřej,

I did not participate in the discussions, but IIRC the question long
ago when the root signing process was being developed was whether we
should roll:

1. only when needed (Florian's position),
2. frequently, or
3. every now and then (the current IANA KSK DPS)

The motivation behind #1 is why bother if things are working?

The motivation behind #2 is that if you don't make it part of practice,
then it won't work when you need to use it. The current concerns about
widespread DNSSEC breakage when the KSK rolls next year seem to
indicate that this is a valid concern. A model like Lets Encrypt, which
requires new certificates every 90 days, seems more and more like a
good idea in retrospect. So you wouldn't need RFC 5011, but you would
have to have *some* automated way to keep your DNS trust anchor up to
date.

The motivation behind #3 is... um. Well, I don't actually know. It
seems like the worst of all possible worlds. :-P

Cheers,

--
Shane

At 2016-06-06 12:02:25 +0200
Ondřej Surý <ondrej.sury at nic.cz> wrote:

> No matter what, the KSK is going to be rolled, so it's futile to resist at this moment.
> 
> For a background see:
> 
> 1. https://www.icann.org/resources/pages/ksk-rollover
> 2. https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf
> 
> This "The IANA Functions Contract requires ICANN to perform a Root Zone KSK rollover" mostly answers your question, but I agree it's good to practice a Root KSK rollover for operational purposes now and to change the algorithm in the future.
> 
> Cheers,
> Ondrej
> 
> --
>  Ondřej Surý -- Technical Fellow
>  --------------------------------------------
>  CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
>  Milesovska 5, 130 00 Praha 3, Czech Republic
>  mailto:ondrej.sury at nic.cz    https://nic.cz/
>  --------------------------------------------
> 
> ----- Original Message -----
> > From: "Florian Weimer" <fweimer at redhat.com>
> > To: "Paul Wouters" <paul at nohats.ca>, "Jan Včelák" <jan.vcelak at nic.cz>
> > Cc: dns-operations at dns-oarc.net
> > Sent: Monday, June 6, 2016 11:20:49 AM
> > Subject: Re: [dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10  
> 
> > On 06/05/2016 08:31 PM, Paul Wouters wrote:  
> >> On Fri, 3 Jun 2016, Jan Včelak wrote:
> >>  
> >>> I don't think this is necessarily a negative score point for systemd.
> >>>
> >>> I already trust my Linux distribution in what they are shipping. I don't
> >>> mind whether it is a list of certification authorities or trust anchor
> >>> for DNSSEC. For me, the trust point is the distribution signing key. And
> >>> the package I can audit. I don't really fancy some software pulling in
> >>> another trust anchor.  
> >>
> >> If your machine is offline for the months during with a KSK rollover
> >> happens, can you get online with enough DNS to update your OS to get
> >> an updated trust anchor?  
> > 
> > I still don't understand this.
> > 
> > Why would you do a KSK rollover if they key isn't compromised?  And if
> > the KSK *is* compromised, you don't want to perform an automated update.
> > 
> > Florian
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs  
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160606/3ae1400e/attachment.sig>


More information about the dns-operations mailing list