- ksk-rollover - lists.icann.org

Any potential correlation between the roll over and the recent notice by the US Department of Homeland Security on DNS Cyber Attacks?
by Lee Neubecker Jan. 25, 2019

Jan. 25, 2019

I wanted to make sure you were all aware of several notices issued which came just before and after the root key change over for DNS. Bad actors with access to the older private key root (if compromised) may have been motivated to strike before the key change over. https://www.cyberscoop.com/dhs-dns-directive-government-shutdown/ This alert went out the day before change over on January 10th, 2019. https://www.us-cert.gov/ncas/current-activity/2019/01/10/DNS-Infrastructure… This alert on January 22nd, 2019 https://cyber.dhs.gov/ed/19-01/ This alert was issued yesterday https://www.us-cert.gov/ncas/alerts/AA19-024A The timing of this change over taking place roughly 2+ weeks after the U.S. Government Shutdown is a little unfortunate, since the switch over date may have encouraged attacks before the old key was revoked. I do think the re-key is a good idea, and agree with Tony Finch on the concept of "[I favour annual rollovers, with keys generated and promulgated out of band a few years in advance, and at most two KSKs in the root zone at any time.]" I welcome any comments. Lee Neubecker, CISSP President & CEO GreatLakesForensics.com 65 W. Jackson Blvd., Suite 101 Chicago, IL 60604 Toll Free/Fax: 888-503-0665 https://greatlakesforensics.com Computer Forensics · Cyber Security Readiness & Response · Online Identity Investigations Check out my security blog at https://leeneubecker.com

2 1

Re: [ksk-rollover] Increased DNSKEY queries to the root servers since the KSK-2010 revocation
by Wessels, Duane Jan. 16, 2019

Jan. 16, 2019

On 1/15/19, 3:53 PM, "Geoff Huston" <gih(a)apnic.net> wrote: Does this have anything to do with the observation that A and J truncate large IPv6 UDP responses No, I don't think so. In the data that I've look at so far, it's been IPv4 sources exhibiting this rollover-and-die[1] behavior. We do observe an increase in truncation during ZSK rollovers. But at revocation, the overall truncation rate dropped a little, almost certainly due to the increase in volume from misbehaving sources. Admittedly that could be masking truncation from other sources so I'll take a closer look. DW [1] I wish they would.

1 0

RFC 5011 will not be implemented in Dnsmasq
by Rene 'Renne' Bartsch, B.Sc. Informatics Jan. 14, 2019

Jan. 14, 2019

Hi, according to Simon Kelly RFC 5011 is not sufficient for automatic DNSSEC key updates and will not be implemented in Dnsmasq (https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg124…) As the majority of SoHo routers uses Dnsmasq as DNS resolver I suggest to address this problem by discussing a suitable solution with Simon Kelly and the IETF workgroups. Regards, Renne

6 9

Root zone KSK-2010 is now revoked
by Matt Larson Jan. 11, 2019

Jan. 11, 2019

Dear colleagues, A few moments ago, at 1400 UTC today, 11 January 2019, ICANN's root zone management partner, Verisign, published root zone serial number 2019011100 with the RFC 5011 REVOKE bit set. As a result, KSK-2010's key tag has changed from 19036 to 19164. In addition, the root DNSKEY RRset is now signed with two KSKs: the current KSK (KSK-2017) as well as the former KSK (KSK-2010). The second signature is required by RFC 5011 to prove possession of KSK-2010's private key to assert the revocation. This second signature makes the response to a query for the root zone's DNSKEY RRset increase in size from 1414 bytes to 1425 bytes. We don't expect any operational issues from this change. The DNSKEY RRset size increase is small, and other zones currently publish considerably larger apex DNSKEY RRsets without apparent issue. In addition, because KSK-2010 has not been used for signing since the root KSK rollover to KSK-2017 on 11 October 2018, no DNSSEC validators that are currently validating correctly can be depending on it. Nevertheless, please let us know if you suspect any issues or have any questions. For the root zone management partners, Matt -- Matt Larson, VP of Research ICANN Office of the CTO matt.larson(a)icann.org

1 0

Revoking KSK-2010 imminent
by Chris Thompson Jan. 7, 2019

Jan. 7, 2019

With the revoking of KSK-2010 in the root DNSKEY RRset due in 5 days time, is no one at all nervous about possible consequences? A couple of more specific question: 1. This has been asked before, but is anyone analysing the RFC 8145 data to see how many servers are reporting that they only trust KSK-2017, and are they in a position to track how this changes during the revoking process? The graphs at http://root-trust-anchor-reports.research.icann.org/ are described in terms of servers trusting only KSK-2010 vs. all others. 2. In the unlikely event that publishing a revoked KSK-2010 causes significant problems (e.g. the new high water mark for the size of a signed DNSKEY response has been mentioned), do ICANN have a back-off strategy (e.g. to delay the revoking)? -- Chris Thompson Email: cet1(a)cam.ac.uk

7 10

New trust anchor files published
by Paul Hoffman Dec. 20, 2018

Dec. 20, 2018

Greetings again. IANA has updated the DNS root trust anchor file at: https://data.iana.org/root-anchors/root-anchors.xml This now includes a "validUntil" attribute on the KeyDigest element for KSK-2010. If you are a software developer who has code that reads the trust anchor XML, it would be great to hear whether this works as expected for you. --Paul Hoffman

1 0

Post IETF - determining 5011 support - part 1
by Michael StJohns Nov. 13, 2018

Nov. 13, 2018

Paul asked me to drop a note to the list describing a few techniques that I think might be used to determine whether a querying entity supports 5011. This email describes detection through the use of the REVOKE bit. (Note that I haven't tested any of these - but they should work 1) Assume that non-5011 entities silently ignore the revoke bit 2) Per 5011, the revoke bit applies to ALL DNSKEY records, not just the root KSKs and you're not allowed to trace a chain of trust through a revoked key. 3) In a non-root zone, set up a delegations to two zones - "valid" and "invalid". 4) Set the valid zone up with the normal KSK/ZSK pair in the DNSKEY RRSet. Set the invalid zone up but with the ZSK having the revoke bit set. Create the RRSigs as appropriate and remember to have the ZSK in the invalid zone also sign the DNSKey RRSet (to cause the key to be revoked). 5) Seed both zones with various A/AAAA and CNAME records. 6) Place web servers at the location pointed to by each of the A/AAAA RRSets and at a place pointed to by the CNAME record. 7) Seed a popular web page (get Google or some other high traffic name to help) with URLs that point to items (say a JPG) served by each of the web servers - avoid having anything else at those servers but these items. 8) Collect logs on the DNS server and on the web servers over a period of a month or so. 9) Do the analysis. Items retrieved from the server pointed to by the A/AAAA RRSet signed by the revoked ZSK are probably being pulled by clients served by resolvers that don't do 5011. Correlate the times of DNS query with times of web queries - you'll mostly pull up the first query from a given resolver before it caches the answer. Pairing an invalid URL (in the sense that DNSSEC should prevent its retrieval) with a valid URL allows for a check against false negatives. If the correlation by log analysis doesn't work - have the dns server return dynamic addresses for the web server that encode the resolver's identity in some manner. (For example, by twiddling the CNAME so that a browser generates an SNI with the resolver identity encoded for a TLS connection). So: Client that sees web pages pointed to by both valid and invalid zones is probably being served by a non-5011 resolver. Client that sees only web pages pointed to by the valid zone is probably being served by a 5011 resolver. Client that sees either neither of the web pages or only the invalid web page is probably being served by a broken resolver. Mike

4 3

Post IETF - Determining 5011 Support Part 2
by Michael StJohns Nov. 12, 2018

Nov. 12, 2018

5011 defines a very specific timing domain for (see section 2.3 of RFC5011) doing refresh of the trust point key RRSET and that active refresh is both mandatory and easily distinguished from normal dns cache timeout/requery intervals. One possible way of identifying 5011 resolvers would be to do timing analysis on the root server logs. Specifically: 0) Time sync all of the roots. 1) Aggregate all the logs from all root servers for a 30 day period. 2) Sort by resolver IP and timestamp. group by resolver IP. 3) For each resolver, calculate the inter-arrival interval times between queries and compare that to the predicted/configured 5011 values. A 5011 compliant resolver that's also caching should be querying the root about 1/2 the TTL of the dnskey RRSet. Again, haven't tested this and implementers may have taken liberty with the refresh protocol, but its a place to start. And yes, I know this is a massive data set to wander through.... Mike

1 0

Informal meeting at IETF 103
by Paul Hoffman Nov. 11, 2018

Nov. 11, 2018

There will be an informal discussion of DNS root KSK futures at IETF 103 on Friday, November 9, at 0900 local (Bangkok) time in room Chitlada 3. The purpose is to allow IETF participants to ask questions and propose ideas for how the DNS root KSK should be maintained in the future. Suggestions from the mic lines at recent meeting include suggestions for fixed rollover schedules, suggestions for data collection before the next rollover, standby KSKs and how they would affect the rollover schedule, and how resolver software vendors' actions can be taken into account. The discussion is expected to last for one hour or less. Unfortunately, there is no remote participation for the Friday sessions, so the meeting will be limited to those in the room. However, I will make a recording to create notes on what is said. --Paul Hoffman

11 21

KSK Roll outreach to enterprise DNS operators
by Kal Feher Nov. 9, 2018

Nov. 9, 2018

I raised this topic at the IETF103 ksk roll meeting (Wednesday edition). I was asked to submit this to the list so here it is. I'd spoken to a lot of non-ISP DNS operators prior to the 2017 roll date and again prior to the actual 2018 roll. These resolver operators would fall into two categories: * Government agencies * Enterprise IT While some had heard of DNSSEC, most were unaware of the key roll (true for 2017 and 2018). There were several cases where the operator was validating but was entirely unaware of that fact. They'd deployed DNS software somewhat recently and accepted the defaults. I'm taking into consideration Geoff's point that it might take 3 or more roll over attempts to achieve truly smooth roll overs. So if we agree that at least the next two rolls (plus or including algo roll) require operator awareness, I have two points related to the lack of awareness amongst this specific kind of non DNS expert operators: 1. I think ICANN's outreach needs to include focus on channels consumed by enterprise IT operators. More mainstream media should be involved. This might cost money if it requires paid for articles. Many enterprise technology companies disseminate updates and industry trend information via their certification and software subscription membership channels. Ideally the next key roll could feature prominently in those materials. 2. A regular key roll schedule might help ease the communication burden for any one key roll. In some ways it will allow us to benefit from previous outreach efforts, if those efforts draw people's attention to a calendar of key rolls. Even a rough calendar would help. Ideally it has a permanent web location. I'm aware that there are challenges faced with getting ICANN's board to commit to a roll over well before the date, much less a rough schedule. However I think most outreach efforts will be more effective if conducted after the board has approved a roll. Of course, the true goal should be for no one to need to know that a roll over will occur. -- Kal Feher Melbourne, Australia

1 0