Minutes IETF110: maprg

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

Meeting Minutes


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:
    * 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

 * 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:

* 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

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