[ALAC] KSK Rollover on today's ALAC Agenda

Thu Mar 29 20:27:52 UTC 2018

Thx Andrei

Javier Rúa-Jovet

+1-787-396-6511
twitter: @javrua
skype: javier.rua1
https://www.linkedin.com/in/javrua 


> On Mar 29, 2018, at 2:18 PM, Andrei Kolesnikov <andrei at rol.ru> wrote:
> 
> 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 8.8.8.8, 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 interpretation.
> 
> 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.
> 
> 
> 
> Joe
> 
>> 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-roll-postponed-17oct17-en.pdf
>> December update: https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project
>> go for continuing roll February: https://www.icann.org/news/blog/announcing-draft-plan-for-continuing-with-the-ksk-roll
>> 
>> --andrei
> 
> 
> 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
> RIPN.NET
> 
> _______________________________________________
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180329/9f58a479/attachment.html>