Minutes IETF99: dprive
minutes-99-dprive-01

DNS Privacy Exchange (DPRIVE) WG
IETF 99, Prague
Tuesday, 18 July 2017, 09:30-12:00 CEST
Chairs: Tim Wicinski and  Brian Haberman
Minutes taken by Paul Hoffman
        Text from the slides is not reproduced here

draft-ietf-dprive-dtls-and-tls-profiles
        Give it a Review!
        People need to review and comment
        Want to get the ADs to remove their DISCUSSes
        Stephane Bortzmeyer; Most of the IESG remarks were on details
                DHCP was not important in the draft
                The draft didn't change a lot
        Francis Dupont: Maybe reach out to the various review teams to re-review

draft-ietf-dprive-padding-policy: Alex Mayrhofer
        Daniel Kahn Gillmor: Analysis is "what percentage of query/response
            pairs is in the same-size bucket"
                Adding random length doesn't improve benefit
        Christian Huitema: It's harder to impelement random padding correctly
        Daniel: DNScrypt uses a nonce in the query, and he used that in
            the research
        Christian: Don't merge the documents
                Padding strategy depends on which transport you use
                This is find for UDP, but maybe quite different for TCP or
                    other transports
        Alex: What other transports are in scope?
        Christian: Padding also helps protect from DoS
                Will send text to the list
        Daniel: Keep it as a separate draft
                Patches in many clients and servers
                Updating resolvers with new defaults is easy
        Shane Kerr: This seems like a good policy
                Maybe want to hear from crypto folks
        Stephane: Document is OK and we should move forward
                Will do a review
        Tim: this should be Experimental
                Need more reviewer
                        Olafur, DKG, Sara, Christian, Shane, David Lawrence
                            agree to review
        Wes Hardaker: DNSOP is working on extensions that will change sizes
        Brian: Do the slides include how the data was analyzed
                Daniel: Only in presentation format
                        Happy to share the programs used to analyze
                        Can run the code over datasets from other recursive
                            resolvers

draft-huitema-quic-dnsoquic: Christian
        Lots of people know what QUIC is
        Phill Hallam-Baker: Proposed something like QUIC before QUIC
                QUIC lets him have an idempotent server
                Can make recursive resolver completely idempotent?
                Chistian: We need to have some state for crypto, but can we
                    reduce the state needed?
                        Because this comes in application layer, you can try
                            new things more easily
        ?1: Current way QUIC is specified is that one UDP packet maps to
            one QUIC packet
                Proposal to make several UDP packets in one QUIC packet
        Ian Swett: Likes the proposal for QUIC
                Christian: Has data about current DNS works in here
        Ben Schwartz: Wants to be able to multiplex this over a single port
                Christian: There are use cases for DNS-over-HTTP-over-QUIC
                    for stealth
                        Flip side is that servers need a full HTTP stack,
                            with tradeoffs
                Ben: Wants this in parallel, not necessarily in HTTP
                        Christian: Allow multiple ALPNs,
        Alex: Joke about "QUIC over DNS"
                Reminds him of encrypted RTP problem from ten years ago
                Worried about proliferation of number of transports
        ?1: Doesn't QUIC seem heavyweight?
                Would prefer a simpler protocol that is DNS-specific
                Christian: We get implementation experience by working this out
        Andrew Sullivan: QUIC is pretty promising for our use cases
                Nervous about how this is framed as stub-to-recursive,
                    and recursive-to-authoritative
                Uncomfortable to make this split
                Christian: two reasons for QUIC: privacy and performance
                        Half of queries to resolvers are from cache
                        Thus need to think about UDP retransmission for
                            responses that take longer
                        Tradeoff of efficiency and performance
                Andrew: Retransmission hurt on the server side as well
        Phill: There was a proposal to do a DNS-specific transport
                QUIC is becoming new SSH
                Few proposals for new crypto protocol
                We are going to change the DNS protocol no matter what
                The spec for DNS is awful, and doesn't say everything
                    that it needs to
                        Doesn't say what the length of responses
                        QUIC will remove that limit
                Wants to see documents with traces so he doesn't have to read
                    the QUIC documents
        Olafur Gudmundsson: There is difference between the different hops
                Disagrees with Andrew
        David Lawrence: Agrees with Andrew
                Main interest is in authoritative servers
                Doesn't think this is useful to split
        Alex: This is interesting because we can look at things that are not
            TLS for maybe ten years from now
        Stephane: If we follow this path for DNS encryption, two problems
                DNS client needs to make a choice
                Marketing / PR to tell folks which to use
        Alex: Will run on UDP/53 forever due to NAT64
        Tim: QUIC is a work in progress
                We're getting ahead of the horse
                Christian: This work helps the QUIC development
                        We can do experiments and comparisons that can help us
                        inform the discussion
        Alex: We would need a significant recharter if we're going to change DNS
        Terry Manderson: It's great to have the discussion as long as it is
                not siloed here
                Keep working, keep thinking

draft-dkg-dprive-demux-dns-http: Daniel
    Christian: If you have a different ALPN, this will change
                Dan: ALPN differentiates between H1 and H2 here
        Demonstration of how to do this today
        Christian: This allows to block after first packet
        ?2: Distinguishability still is a problem because of SNI
                Daniel: Doesn't hide server name
                        Suspects that most network adversaries is
        Phill: What is the proposed final status?
                Daniel: Wrote this to make it visible, but hasn't proposed
                    that the WG adopt this
                Web services use HTTP to expand the number of ports
                Better to do this over QUIC
        Shane Kerr: This is not a terrible hack
                Reasonable approach
                Maybe doesn't belong in this group
        Martin Thompson: Just declare victory and don't publish as an RFC
        Patrick McManus: Why can't you just speak HTTP?
                Daniel: Existing DNS over TLS clients don't need to be modified
                This motivates the other work for long-term potential
        Eric Rescorla: Requires colocation
                If the host only does this, it become obvious
                Historically, this puts handcuffs on both protocols
                The number of deployed DNS-over-TLS clients is low, so add
                    stuff to the clients
                Why is this only good for DNS?
        Andrew: Agrees with Eric
                Disagrees with Martin
                We should be writing this down
                Using accidents of the internals of the protocol to determine
                    the transport
                Danial: This is a functional way of hiding a metadata to
                    adversaries
                We can't be burning this casually
        Ben: If we don't move forwards with DNS-over-HTTP, this is what you
            will end up with
        Phill: Disagrees with Eric's rant
                HTTP servers are required to look for "HTTP/1"
                Could use "GET DNS" instead
        Christian:
                There are many ways to multiplex
                The advantage of the .well-known is that everything is encrypted
                Multiplexing based on port doesn't work well because it
                    allows censorship
                We could instead use ALPN if it is hidden using tricks like
                    are used for SNI
                We are dealing with both privacy and censorship
                We can change TLS to encrypt the token used for demuxing
        Martin: This is a threat to the architecture
                Don't do this again
                The point is well-made, but it needs to be clearer
        Tim: People got too excited by trying to solve the problem, not
            seeing that there was a basic problem
                Drive future conversations
        Move your metadata into the envelope
        Brian: Maybe publish this with "don't do this"
                Daniel: Won't do that as long as network operators are
                    blocking traffic they don't understand
        Paul Wouters: We are doing the same think with IKE over TCP
                Were told "don't mention port 443"
                Doesn't think that is useful

What's next?: Tim
        How do we get more deployment?
        Sara Dickenson: See https://dnsprivacy.org for lists of who has adopted
                Not much seen in clients
                Maybe will show DNS-over-TLS on anycast
                Maybe add traffic levels and usage
        Shane: This isn't DNS Privacy Ops
                Tim: Wants to get operational data
                Maybe not in the current charter
                Maybe add DNS-over-TLS to their open resolver
                        Need to get it pushed into the components they are using
                        It's going to take a long time
        Sara: Challenge the idea of waiting for data on stub-to-recursive
            before we start
            recursive-to-authoritative
                Tim: We should start thinking about it because it will take
                    a long time
        Ben: Cares a lot about client side
                Time delay measured in years for clients to be able to use
                    the new code
                Tim: doesn't feel that it is a failure
        Alex: Ran some analysis for adding TLS to their authoritative
                Came up with 8x as multiplier for the amount of resources needed
        Terry: Importance of measuring is for the next question
        Shane: We saw earlier estimates of adding TCP is 6x
                But a lot of the overbuilding is for protecting DDoS over UDP
        Tim: Can people share their estimates for TCP
        Dan York: Measurements are important
                Help make the case for deployed
        Alex: If someone has grad students, try replaying actual traffic
        Sara: There are other problems with recursive-to-authoritative that
            are not about performance
        Stephane: There was very little discussion of the step 2 draft
                Maybe have a draft proposing one solution
                Would be to use DANE to publish certificate in DNS
        Daniel: Supports work on recursive-to-authoritative

Warren made slides of DNS usage