<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">This is really helpful - thanks.<div><br></div><div>From what Joe is saying, there are good arguments to go ahead.  I am particularly heartened by Joe’s statement of ICANN’s outreach - both public and targeted. Am I reading this incorrectly<br><div><br></div><div>(Could we put this text on the wiki -so it is part of the conversation ALAC is having on the issue.)</div><div><br></div><div>Holly<br><div><div>On 30 Mar 2018, at 5:18 am, Andrei Kolesnikov <<a href="mailto:andrei@rol.ru">andrei@rol.ru</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div>Dear colleagues,<br></div>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.<br></div>Yours, --andrei<br>--<br><div><br><div>Hi all,</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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 8.8.8.8, in my experience). I would imagine any such impact would be 
short-lived for both reasons.</div><div><br></div><div>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.</div><div><br></div><div>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 
interpretation.</div><div><br></div><div>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%.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div class="gmail-yj6qo gmail-ajU"><div id="gmail-:g0g" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><span class="gmail-HOEnZb gmail-adL"><font color="#888888"><div><br></div><div><br></div><div>Joe</div></font></span><div class="gmail-adL"><div class="gmail-adm"></div><div class="gmail-im"><div><br>On Mar 22, 2018, at 20:00, Andrei Kolesnikov <<a href="mailto:andrei@rol.ru" target="_blank">andrei@rol.ru</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div>John, the input data is pretty simple with unknown impact...<br></div>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. <br><br></div>Questions ALAC may have:<br></div>- building risk assumptions, very generic: does it really off users from the internet? If so, to which degree? <br></div><div>- possible ICANN outreach campaign for ISP, telcos and hosting: is it in the scope of ALAC or out of scope?<br></div>- possible outreach campaign for end users: (Y2K model?)<br></div><div>-
 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?<br></div><div><br>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. <br><br></div><div>John, recent texts about the issue:<br></div>postponing paper: <a href="https://www.icann.org/en/system/files/files/root-ksk-roll-postponed-17oct17-en.pdf" target="_blank">https://www.icann.org/en/<wbr>system/files/files/root-ksk-<wbr>roll-postponed-17oct17-en.pdf</a><br></div>December update: <a href="https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project" target="_blank">https://www.icann.org/news/<wbr>blog/update-on-the-root-ksk-<wbr>rollover-project</a><br></div>go for continuing roll February: <a href="https://www.icann.org/news/blog/announcing-draft-plan-for-continuing-with-the-ksk-roll" target="_blank">https://www.icann.org/news/<wbr>blog/announcing-draft-plan-<wbr>for-continuing-with-the-ksk-<wbr>roll</a><br><br></div>--andrei</div></blockquote></div></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-27 22:16 GMT+03:00 Alan Greenberg <span dir="ltr"><<a href="mailto:alan.greenberg@mcgill.ca" target="_blank">alan.greenberg@mcgill.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
Here is my last try at summarizing things.<br><br>
What is wrong or missing?<br><br>
-----------------<br><br>
What I am hearing (extrapolated) is:
<ul>
<li>Our community understands the need to roll the KSK but is divided on
which path to follow at this point.
</li><li>We want an intense awareness campaign including targetting ISPs,
Telcos, Major industries. Use RIRs where they can identify potential DNS
providers.
</li><li>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.
</li><li>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.
</li><li>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.
</li></ul></div>

<br>______________________________<wbr>_________________<br>
ALAC mailing list<br>
<a href="mailto:ALAC@atlarge-lists.icann.org">ALAC@atlarge-lists.icann.org</a><br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/alac" rel="noreferrer" target="_blank">https://atlarge-lists.icann.<wbr>org/mailman/listinfo/alac</a><br>
<br>
At-Large Online: <a href="http://www.atlarge.icann.org/" rel="noreferrer" target="_blank">http://www.atlarge.icann.org</a><br>
ALAC Working Wiki: <a href="https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)" rel="noreferrer" target="_blank">https://community.icann.org/<wbr>display/atlarge/At-Large+<wbr>Advisory+Committee+(ALAC)</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Andrey Kolesnikov<br></div><div><a href="http://ripn.net/" target="_blank">RIPN.NET</a><br></div><div><br></div></div></div></div></div>
</div>
_______________________________________________<br>ALAC mailing list<br><a href="mailto:ALAC@atlarge-lists.icann.org">ALAC@atlarge-lists.icann.org</a><br>https://atlarge-lists.icann.org/mailman/listinfo/alac<br><br>At-Large Online: http://www.atlarge.icann.org<br>ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)</blockquote></div><br></div></div></body></html>