* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dprive Status Pages

DNS PRIVate Exchange (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2014-Oct-17 —  
Chairs
 
 


IETF-99 dprive minutes

Session 2017-07-18 0930-1200: Congress Hall III - Audio stream - dprive chatroom

Minutes

minutes-99-dprive-01 minutes



          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
          
          



Generated from PyHt script /wg/dprive/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -