Paul Hoffman has sent us the draft of the minutes from the DPRIVE
session. I've taken a look, and I'm impressed in his capturing of the
wonderful DKG discussion.
https://www.ietf.org/proceedings/99/minutes/minutes-99-dprive-00.txt
please send any corrections to the chairs
tim
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 dns-privacy.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
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy