IRTF Open Meeting @ IETF 105 ============================ Tuesday, 23 July 2019, at 15:20-16:50 Room: Place du Canada Chair: Colin Perkins Notes: Mat Ford # Introduction and Status Update -- Colin Perkins Slides: https://datatracker.ietf.org/meeting/105/materials/slides-105-irtfopen-agenda-01 # Update from ICNRG: CCNx RFCs -- Marc Mosko Slides: https://datatracker.ietf.org/meeting/105/materials/slides-105-irtfopen-content-centric-networking-ccnx-information-centric-networking-rg-icnrg-02 # Preventing (Network) Time Travel with Chronos -- Neta Rozen Schiff (NRS) ANRP Award Talk Slides: https://datatracker.ietf.org/meeting/105/materials/slides-105-irtfopen-preventing-network-time-travel-with-chronos-01 Video: https://www.youtube.com/watch?v=8v37fuWsGmY#t=14m10s Q&A: Stuart Cheshire - This is important work, thank you. You had a graph showing the probability improvements as the sample size improves - it had a staircase shape - what is the intuition for why it's not a monotonic increase? It seems like going from 14 to 18 it gets worse and then it improves at 20. NRS - This is a simulation effect. We use between 4 and 6 servers didn't really calculate. It's a straight line because we would like to remove B from each side. Stuart Cheshire - Is the conclusion that querying 8 servers gives you better results than querying 12? NRS - No - the lines are horizontal - it's a plateau. Even if we sample only 10 servers it still improves by up to 100. Wes Hardaker - This is good work, statistical analysis of security likelihood is nice to see. It looks like it's a feasible solution with one exception - you don't handle MITM attacks where the attacker is very close to you, right? NRS - That's right, if you control my gateway for example it's game over. Alexandre Ferrieux - It seems like your last validation step is to compare to current clock? If significant number of machines in a pool get huge drift they will all switch to panic mode as soon as they are switched back on, right? - imagine a bunch of machines that you remove from the network for sometime, clocks drift, then connect back to Internet - so they all go into panic mode NRS - Yes - in startup we use a panic model - we're working on it but maybe we don't have to query all servers but maybe a factor of 2 for example. this is exactly what we're working on. ? - Is there a general result here with regards to security and the digestion of untrusted sources that you're based on? NRS - The bottom line is that we can use clock sourcing in order to use Chronos as a watchdog to NTP and see if there is a huge shift and then move to a more secure mechanism. Colin: There is a working link to Neta's paper from the irtf.org website. Aanchal Malhotra - Did you do any analysis of whether using a fixed number of servers as opposed to selecting randomly from a large pool and using your modified algorithm provides similar security guarantees? NRS - The problem with using a fixed set is that once I have a malicious sample in my remaining set I will continue to ask the same server again and again. If the malicious server can do repeated time shift I have a problem. Repeated time shift is negligible in Chronos because I'm querying different servers. Colin Perkins - Did you talk to the NTP working group while you're here? NRS - yes, and the chair is here. we have presented a draft there and hope to have it adopted by the working group. No further questions. Applause for Neta. # Understanding the Role of Registrars in DNSSEC Deployment -- Taejoong Chung (TJ) ANRP Award Talk Slides: https://datatracker.ietf.org/meeting/105/materials/slides-105-irtfopen-understanding-the-role-of-registrars-in-dnssec-deployment-00 Video: https://www.youtube.com/watch?v=8v37fuWsGmY#t=39m45s Q&A: Wes Hardaker - Great talk - entertaining too! Are you continuing to do long running statistics gathering and are you publishing it live? If so i'd be interested to collaborate - I have a webpage http://stats.dnssec-tools.org where Viktor Dukhovni and I publish daily updated statistics of DNSSEC deployment and DANE deployment - it would be cool to merge our datasets. Are you running your analysis continually? TJ - Yes Pallavi Aras - Nice talk. When the client is big, e.g. domain name is used by a lot of clients, you try to make the domain name multi-vendor so you might have your zone hosted on Cloudflare and another provider. In this case activating DNSSEC is hard. You could also look at this aspect of the zones that you are scanning. We have a draft in DNSOP WG related to this. TJ - I'm not familiar with that area but happy to talk further. Paul Ebersman - On the 30% that don't have DS records - people commonly start playing with DNSSEC - and first thing they'll do when they aren't sure is yank DS records from parent - go undetermined rather than invalid - might want to resample on a recurring basis to see who has DS records appear and then disappear - this is also a vector for hijacking - first thing they do is remove ds records from the parent and start playing games Roland van Rijswijk - I'm a co-author of this paper - we looked at that - it's not people playing around with DNSSEC - it's people deploying a DS in one TLD, they sign their whole portfolio, but then only deploy DS in the TLDs that give them a financial incentive, such as .nl and .se. There are some positive side effects - there are people that sign everything because of the financial incentive but then also deploy the DS in every TLD, which is what people should have been doing. There are some positive side effects from other incentives that TLDs are now deploying for the deployment of DANE TLSA records where you see as a side effect an uptake of DNSSEC DANE in other TLDs than the one that deploy the incentives. I'd like to applaud Ulrich from .se for deploying that incentive as well. Ulrich Wisser - Thanks Roland. From Swedish Internet Foundation, we run .se. Very nice work - only criticism is that you didn't test our registrars. We would like to have this test on our registrars - we want to promote DNSSEC. Rick Wilhelm - On chart 24 - this is where the number 15/20 comes up - curious as to why the ones that support email upload aren't included in the count as supporting DNSSEC. TJ - They are included in the count - not all registrars are listed on the slide. Rick Wilhelm - In the .com registry there is a very large number of registrars participate with varying levels or participation for both allowing DNSSEC through their portal and also via other mechanisms. TJ - Yup Jody Kolker - Do you have any data on the top 100k Alexa websites that are using DNSSEC? TJ - Yes we do, but not in this paper. We published a paper at USENIX Security 2017 that analysis the Alexa 1M. It's very low - the it's less than 2%. Jody Kolker - Why do largest retailers on the web (like Amazon) not use DNSSEC? TJ - I'm sorry, I have no idea. They should. Jody Kolker - As many domains are SMEs - they don't have an IT dept. and they don't really understand DNS so adding DNSSEC on top doesn't make that any better for them. TJ - Yes. But for small companies, we sometimes observe use of default name server provided by registrar - that's why we're encouraging registrars to support DNSSEC on their default name servers. If they do that then the SMEs don't need to care about DNSSEC because it will be enabled automatically. No further questions. Applause for TJ. # Wrap-up Colin Perkins - that concludes the meeting. Thanks again to TJ and Neta - both around for most of the week so please talk to them if you're interested in their work. Thanks all for your attention. Meeting adjourned.