Skip to main content

Minutes IETF110: maprg
minutes-110-maprg-00

Meeting Minutes Measurement and Analysis for Protocols (maprg) RG
Date and time 2021-03-08 14:30
Title Minutes IETF110: maprg
State Active
Other versions markdown
Last updated 2021-03-23

minutes-110-maprg-00

MAPRG

Date: March 8 2021
* Notes from Spencer Dawkins and Oliver Gasser (and GGM)

Overview & Status - Mirja & Dave (MAPRG) (5 min)

  • Review of IRTF Note Well, Privacy/Code of Conduct slides, and IRTF Goals

Collecting "Typical" Domain Names for Web Servers - Paul Hoffman (10 min)
* See accompanying report here: https://www.icann.org/en/system/files/files/octo-023-24feb21-en.pdf
* work done for DPRIVE, ICANN
* Motivation: How long does it take to set up a TLS connection on a typical server?
* Alexa, Tranco, etc. are not representative, DNS resolvers tend to be local/regional
* Using Wikipedia external links from all languages as a better sample, after cleanup
* Actual analysis was performed on about 110,000 domain names
* If you are interested in large random samples of domain names, please see Paul privately
* around 17% dualstack. 4% DNSSEC signed

  • Comments/Questions:
    • Alexander Mayrhofer - did you consider CT? Paul at the time no, but subsequently yes.
    • Sample isn't "typical", but it is MORE typical - e.g. lots of online food orders going to local restaurants, domains are not in wikipedia, so not captured
    • Oliver Gasser - starting assumption toplists not representative: did you compare your dataset with them? Paul yes. IPv6 adoption was almost identical, DNSSEC adoption was not (2% on the tranco list) -shows there are variances (eg less likely to use DNSSEC on alexa class lists)

Measuring DNS over TLS from the Edge: Adoption, Reliability, and Response Times - Trinh Viet Doan (15 min)
* This is preview of an accepted paper for PAM 2021, March 29-31 2021: https://www.pam2021.b-tu.de/program/
* Interested how it looks from home networks
* Open resolver support for DoT increased by 23% from 0.17 to mid 2019 to early 2020
* Daily RIPE Atlas measurements, both DoT and Do53: only 13 of more than 3000 probes support DoT
* Most errors from timeouts, sockets errors, TCP/TLS errors (DoT exclusive, higher failure rate)
* Guessing that at least some failures are from middleboxes dropping DoT requests
* Failures differ based on continent
* Measuring response times for DoT is trickier than for DNS53 - measurements include full TCP/TLS handshakes
* Limitation of Atlas: experiment isolation == can't see benefit of keep-alive in TLS and other expensive connect protocols
* DoT response times inflated by more than 100ms from DNS53
* Again, response times vary by continent/region. South America and Africa are slowest response times

  • Comments/Questions:
    • Mirja - comment about DoH vs DoT in chat: TVD: cannot run DoH in Atlas. Some other papers have looked at that

Assessing the Privacy Benefits of Domain Name Encryption - Nguyen Phong Hoang (15 min)
* This paper was presented at ASIA CCS ’20, October 5–9, 2020, Taipei, Taiwan, and is available here: https://arxiv.org/pdf/1911.00563.pdf
* Domain names contain sensitive information, sent in plaintext during the traditional TLS handshake
* Looking at DoH/TLS and ESNI
* IP addresses are still visible to on-path observers and can be mapped to one or more domain names served by the IP address - single-server domains are "privacy-detrimental"
* Using Alexa and Majestic toplists (7.5 million domains) to back-map the commonality of the underlying IP authority/hosting
* Taking CDNs into consideration
* comes up with a metric to define 'privacy benefit'
* 70 percent of IP addresses host only one domain
* 80 percent of domains are hosted on multiple IP addresses
* The more domains you host on an IP address, the better the privacy benefit
* Top domain hosting providers use very small numbers of IP addresses often they are small enterprises
* Major providers have lots of IP addresses and a small degree of co-hosting
* Only 13% of domain-to-IP mappings are stable for at least two months
* Website: https://homepage.np-tokumei.net/publication/publication_2020_asiaccs/

  • Comments/Questions:
    • Andrew Campling - privacy benefit from colo/CDN, but did you consider the privacy risks, security risks of increased centralisation? NPH: another paper submitted last year on centralizing all queries to one resolver. Orthogonal problem, queries can be distributed to multiple resolvers
    • Eric Rescorla: looked at this, consequences of bad choices here terrible. Any assessment of relative impact of actual size of the sets. in some cases, 10 is good. eg. facebook/telegram hiding telegram in facebook is good. And, traffic analysis defences? NPH: sensitivity of website, debateable, what we consider is/is-not. an IP in AS-GOOGLE people don't really care, but anonimity set here can be 100-150. the whole set can be very sensitive. do Traffic-Analysis per website. 200,000 half are popular, half "sensitive" and solely on IP ad, can pinpoint 90% of them with high precision.

qlog: facilitating analysis of QUIC, HTTP/3 and other (encrypted) protocols - Robin Marx (5 min)
* https://github.com/quiclog
* Started about three years ago because QUIC encrypts everything
* Not everything is sent on the wire
* Using JSON allows comparison across implementations and congestion controllers
* Majority of QUIC implementations support QLOG, Facebook using it in production now. bringing to WG soon
* Would like to support more than QUIC and HTTP/3
* Goals: easily compare different implementations, share datasets

Explicit Congestion Notification (ECN) Deployment Observations - Pete Heist (10 min)
* This is about draft-heist-tsvwg-ecn-deployment-observations.
* Informative survey, not authoritative, but results likely useful
* Data collected at a Czech ISP upstream router
* Using iptables-ecn in Linux
* Low acceptance among clients, but looks widespread
* High ECN acceptance among servers
* Easy to miss AQMs on paths (need ECN-capable and congestion events to spot them)
* AQM seen on about 10% of random paths
* Much lower usage of ECN for non-TCP traffic, and apparent misuse of the ECN field
* Misuse could be historical, inadvertent, or malicious
* If you want to repeat the experiment from other observation points, please contact Pete and Jonathan