Re: [dns-privacy] DNS-over-TLS on the IETF network...

[Willem Toorop]

Thanks Warren,

The page mentions a very recent Android Open Source Project build.
Do you have pointers to this work?

Cheers,
-- Willem

Op 16-07-17 om 12:36 schreef Warren Kumari:
> Hi there all,
> 
> Just wanted to make sure that people had seen this:
> https://tickets.meeting.ietf.org/wiki/IETF99Experiments
> 
> Basically, we are running an experimental DNS-over-TLS service on the
> IETF 99 network. This is implemented as an stunnel, which proxies
> queries to the normal IETF servers.
> 
> The linked page has example Stubby / Unbound configs.
> 
> We are logging the number of packets going to port 853 (as a rough
> proxy for number of queries), but are not logging other info.
> 
> Feel free to use this and provide feedback, etc.
> 
> W
> 
> 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Draft Minutes from DPRIVE,

[Tim Wicinski]

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 

Re: [dns-privacy] Usage on DNS-over-TLS on IETF Network

[Stephane Bortzmeyer]

On Tue, Jul 18, 2017 at 01:29:27PM +0200,
 tjw ietf  wrote 
 a message of 5937 lines which said:

> Our former co-chair Warren sent us these slides on DNS usage on the
> IETF network and also DPRIVE usage.  It's a small number (but not
> zero!)

It also would be interesting to keep track of TCP sessions: how many
queries per TCP session in average, median duration of TCP sessions,
etc.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy