[ALAC] KSK Rollover on today's ALAC Agenda

Andrei Kolesnikov andrei at rol.ru
Thu Mar 29 18:18:47 UTC 2018

Dear colleagues,
Below is an exchange of email with Joe Abley and John re: KSK rollout. This
message is personal view and carry no SSAC position. I think Joe did a very
good job explaining the situation is very simple form.
Yours, --andrei

Hi all,

Many apologies for missing this e-mail earlier, and thanks Andrei for
passing on those details. I can add some more detailed technical colour,
for what that's worth.

To answer the questions, there is no such web page that I am aware. ICANN
continues to solicit help from the technical community to analyse the data,
but it is very noisy and difficult to interpret. I suspect there will never
be a clear conclusion from the data with respect to end-user impact (in
fact, it's not obvious that any useful conclusion is possible).

The risk of not rolling is related to the risk of a key compromise (e.g. a
facility failure, a cryptanalysis breakthrough, a failure of process, etc).
We have to assume the risks of such a compromise are very low, given
ICANN's demontrated ability to pass audits and protect their crypto assets,
although the impact might well be high in the event that something
happened. My view is that the delay in rolling the KSK has a run-on impact
on ICANN's ability to make progress with plans for both scheduled and
emergency key rollovers in the future, however, and I think that any
further such delay really needs to be well justified.

The degree of the impact on the small population of end-users who rely upon
a validator that is not ready for the KSK roll is that there will be a
failure to validate until the problem is fixed (i.e. DNS lookups will fail,
web sites won't load, e-mail won't arrive or be sent, etc). System
administrators are well versed in the operation of twitchy infrastructure
that has a direct impact on support costs, and some validator problems will
be fixed quickly. End-users (especially those who at some time have relied
upon resolvers of variable quality) have also been observed to switch
resolvers when failures happen (most often to, in my experience). I
would imagine any such impact would be short-lived for both reasons.

I think it's important to recognise that there has been no convincing
correlation demonstrated between the RFC8145 data that ICANN have been
presenting in many venues and impact on end-users. ICANN continue to
solicit help from researchers in the community (me included) and there is
plenty of communication between us, but no real insight.

For example, the graphs presented by ICANN that have recently caused
concern in some circles document linear increases in *addresses* associated
with received queries. There has been no attempt to identify the
relationship between those numbers and the number of resolvers (e.g.
accounting for DNS forwarders, carrier-grade NAT and other effects), and
even less between the number of resolvers and the number of affected
end-users. Numbers like "20%" that appeared in some graphs produced by
ICANN unfortunately are being shared widely without any real attempt at

What we know is that ICANN have been engaged in a great deal of outreach,
both public and individually targeted towards organisations that are
thought to have large numbers of dependant end-users. The top dozen
resolver operators are responsible for over 90% of the traffic observed at
ORG, and all of those organisations are known to be aware and ready for the
KSK rollover. This is a crude measurement, but it plausibly suggests an
upper bound for the end-user population represented by the 8145 data;
whatever that data indicates, it's a small fraction of the remaining 10%.

It is far easier to point at the significant resolver operators that we
know about, and plausible estimates of the end-users that are not expected
to see any disruption from the key roll than it is to draw conclusions from
the RFC8145 data. Of course, we continue to try.

Note that this commentary is all my own; SSAC has not yet had a chance to
form a consensus view on the situation, although we expect that to happen
soon in anticipation of a question from the board.


On Mar 22, 2018, at 20:00, Andrei Kolesnikov <andrei at rol.ru> wrote:

John, the input data is pretty simple with unknown impact...
About 4-5-6% (number must be changing over time) of recursive resolvers
with enabled trust anchor still running KSK 2010 without being updated to
KSK 2017 capable to handle a new key.

Questions ALAC may have:
- building risk assumptions, very generic: does it really off users from
the internet? If so, to which degree?
- possible ICANN outreach campaign for ISP, telcos and hosting: is it in
the scope of ALAC or out of scope?
- possible outreach campaign for end users: (Y2K model?)
- ALAC may say "don't do it and postpone further until we know more?" or we
all in agreement about October 2018? Should this question be asked?

Joe, is there a site with newer data or resource which shows the dynamics
of change of unpatched resolvers live or batched mode? Such as from
Verisign, ISC, NLnet lab? Can you navigate us to recent publications with
risk "not rolling" if any? Another plea to you is about practical scenario
of the doomsday: new key rolled, unpatched recursive resolver is not
accepting a new key and what? User sends DNS query to the resolver and what
happens? It is not responding or fails back to non DNSSEC mode or just
bricks? This one is very important to ALAC and Atlarge in general. Most
people don't understand it.

John, recent texts about the issue:
postponing paper: https://www.icann.org/en/system/files/files/root-ksk-
December update: https://www.icann.org/news/blog/update-on-the-root-ksk-
go for continuing roll February: https://www.icann.org/news/


2018-03-27 22:16 GMT+03:00 Alan Greenberg <alan.greenberg at mcgill.ca>:

> Here is my last try at summarizing things.
> What is wrong or missing?
> -----------------
> What I am hearing (extrapolated) is:
>    - Our community understands the need to roll the KSK but is divided on
>    which path to follow at this point.
>    - We want an intense awareness campaign including targetting ISPs,
>    Telcos, Major industries. Use RIRs where they can identify potential DNS
>    providers.
>    - Information packet we can send to our community (ALSes, Individual
>    Members) to get them to prompt their local ISPs or others and which can be
>    similarly used by other constituencies within ICANN.
>    - A holistic review of the situation (including a risk assessment of
>    alternatives) in time for further discussion at ICANN62, including the then
>    current state of whatever data is available and forecast of Sentinal
>    availability.
>    - We would like to better understand under what conditions a rollover
>    date change is possible to avoid doing it at the end of a week.
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+
> Advisory+Committee+(ALAC)

Andrey Kolesnikov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180329/935cc5a7/attachment.html>

More information about the ALAC mailing list