Skip to main content

DNS PRIVate Exchange
charter-ietf-dprive-02

Yes

(Alissa Cooper)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)

No Objection

(Alia Atlas)
(Richard Barnes)
(Ted Lemon)

Note: This ballot was opened for revision 00-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Adrian Farrel Former IESG member
Yes
Yes (2014-10-01 for -00-00) Unknown
I'm really glad that this work is happening.

At the level of nits, "The primary focus of this Working Group will be" could s/will be/is/
Alissa Cooper Former IESG member
Yes
Yes (for -00-00) Unknown

                            
Barry Leiba Former IESG member
Yes
Yes (2014-09-23 for -00-00) Unknown
A fine charter, and one I fully support.

Just one small point that I question in the text:

     Some of the main design goals (in no particular order) are:

...

     - Focus on developing deployable solutions.

It would seem to me that developing deployable solutions would be an absolute requirement, not one of the "in no particular order" design goals?  Of what value is a solution we deem not to be deployable?

It would also seem that some of the other design goals are part of how we get to deployable solutions: backward compatibility, minimal configuration effort, and so on.

I suggest just removing that bullet.  To maintain the "deployable" aim, you could also change "develops mechanisms" in the very first paragraph to "develops deployable mechanisms".
Brian Haberman Former IESG member
Yes
Yes (for -00-00) Unknown

                            
Jari Arkko Former IESG member
Yes
Yes (for -00-00) Unknown

                            
Martin Stiemerling Former IESG member
Yes
Yes (for -00-00) Unknown

                            
Pete Resnick Former IESG member
Yes
Yes (for -00-00) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (for -00-00) Unknown

                            
Stephen Farrell Former IESG member
Yes
Yes (2014-09-23 for -00-00) Unknown
Yes, let's do this. 

I love (but just don't believe) your timing optimism but am fine with
that if its a useful fiction.

I forget if this was discussed or if a conclusion was reached: would
it save time to mention now that some of the results here might be
experimental or not? (I'm fine with any answer btw.)
Alia Atlas Former IESG member
No Objection
No Objection (for -00-00) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2014-10-02 for -00-00) Unknown
Examples of the sorts of risks that DPRIVE will address can be found in
[draft-bortzmeyer-dnsop-dns-privacy], and include both sniffing traffic on the
wire and more active attacks, such as MITM attacks.

I'm not too sure what kind of "risks" you have in mind here. Risk of doing what?, risk for whom?
Do you have in mind the "security threats"? 
By spending about 1 min on [draft-bortzmeyer-dnsop-dns-privacy], I see that "privacy risk" is mentioned
Joel Jaeggli Former IESG member
No Objection
No Objection (2014-10-02 for -00-00) Unknown
- Provide confidentiality to DNS transactions.

(for the querier)

resielience against pervasive monitoring is maybe not the only consequence. certain kinds of dns based gtm may also be rendered less useful by them.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-10-01 for -00-00) Unknown
I support this effort and just have a non-blocking wording question.

Instead of sniffing, should the term "passive wiretapping" be used instead? I don't care too much either way on the wording as the intent is clear, but RFC4949 says the term sniffing has been deprecated.

Examples of the sorts of risks that DPRIVE will address can be found in
[draft-bortzmeyer-dnsop-dns-privacy], and include both sniffing traffic on the
wire and more active attacks, such as MITM attacks.

To maybe:
Examples of the sorts of risks that DPRIVE will address can be found in
[draft-bortzmeyer-dnsop-dns-privacy], and include both passive wiretapping 
and more active attacks, such as MITM attacks.
Richard Barnes Former IESG member
No Objection
No Objection (for -00-00) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -00-00) Unknown