[DNSOP] Agenda - Additional DNSOP meeting on DNS Privacy, Thursday 1840-1940, Sovereign

Tim Wicinski <tjw.ietf@gmail.com> Wed, 05 March 2014 19:27 UTC

Message-ID: <53177A7A.9060703@gmail.com>
Date: Wed, 05 Mar 2014 19:26:50 +0000
From: Tim Wicinski <tjw.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0a2
MIME-Version: 1.0
To: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/spOpNLlSfC043m_EiEiQr71Js2c
Cc: Brian Haberman <brian@innovationslab.net>, ted.lemon@nominum.com
Subject: [DNSOP] Agenda - Additional DNSOP meeting on DNS Privacy, Thursday 1840-1940, Sovereign
Precedence: list

dnsop,

To avoid conflict with UTA, which seems to have a lot to say about this 
topic, and turned into a conflict, we've set this meeting up.  Here is a 
very rough agenda.  Our AD will make sure other groups are informed as 
well.

Our focus is to attempt to nail down the problem space (or problem 
spaces as someone pointed out). The solutions listed below are just what 
is current, and we are attempting to take a step back and look for the 
pros and cons of each option.

thanks
tim
-----------


WG:             DNS Operations (dnsop)
Meeting:        IETF 89, London
Location:       Hilton Metropole, Sovereign
Date:           Thursday, 6 March 2014
Time:           1840-1940 GMT
Chairs:         Tim Wicinski <tjw.ietf@gmail.com>
                 Suzanne Woolf <suzworldwide@gmail.com>



Special Meeting to discus DNS Privacy

1) Introduction

     * Summarize problem statement
         Formal adoption, anointing of reviewers

     * DNSE summary
         * Interest in the problem
         * Overview of obvious existing protocol solutions
         * Where from here on specification/analysis of problem space?

     * Requirements/tradeoffs
         * UDP/TCP
         * Middlebox Problem
         * Small enough protocol changes to take only finite time
         * Clarity on what we can’t do, e.g. prevent traffic analysis
             entirely
         * Which parts of the relationship/transaction trying to
             protect? From what threats? (priorities)

     * Solution space
         * A Comparison of solution space ala RFC 5479 is needed
             * draft-bortzmeyer-dnsop-privacy-sol
             * draft-wijngaards-dnsop-confidentialdns-00
             * draft-rafiee-intarea-cga-tsig
             * draft-hzhwm-start-tls-for-dns
             * QNAME minimization

2) Next steps
     * Adopt/review problem statement
     * Missing document on requirements/tradeoffs:
         * who wants to write this?
     * How to approach solutions?
         * How much complexity is tolerable?
         * Can we do anything simple?
         * Backwards compatibility required?
     * How much of the work can we do here (charter discussion)
     * Call for someone shepherd for topic in the WG

[DNSOP] Agenda - Additional DNSOP meeting on DNS … Tim Wicinski