Re: [dns-privacy] Potential re-charter text

[Brian Haberman]

All,
 The updated charter is on the IESG's agenda for their May 24th
telechat. If all goes well there, it will be sent to the IETF community
for review.

Regards,
Brian

On 4/10/18 11:30 AM, Brian Haberman wrote:
> All,
>  Thanks for the feedback. Tim and I will add some milestones to the
> proposed charter and get it to our illustrious AD for review/handling.
> 
> Regards,
> Brian
> 
> On 3/21/18 9:44 AM, Brian Haberman wrote:
>> Slightly updated text to capture a missing work item...
>>
>> https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt
>>
>> Regards,
>> Brian
>>
>> On 3/19/18 11:07 AM, Brian Haberman wrote:
>>> All,
>>>  The chairs have been chatting with our AD about re-chartering the
>>> WG. The text below is our proposed charter that we will discuss in our
>>> session this week.
>>>
>>> Regards,
>>> Brian & Tim
>>>
>>>
>>> DPRIVE Charter 2.0
>>>
>>> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
>>> provide confidentiality to DNS transactions in order to address concerns
>>> surrounding pervasive monitoring (RFC 7258).
>>>
>>> The set of DNS requests that an individual makes can provide an attacker
>>> with a large amount of information about that individual.  DPRIVE aims
>>> to deprive the attacker of this information (The IETF defines pervasive
>>> monitoring as an attack [RFC7258]).
>>>
>>> The initial focus of this Working Group was the development of
>>> mechanisms that provide confidentiality and authentication between DNS
>>> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
>>> proposed standard solutions for the client-to-iterative resolvers
>>> published, the working group turns its attention to the development of
>>> documents focused on: 1) providing confidentiality to DNS transactions
>>> between Iterative Resolvers and Authoritative Servers, and 2) measuring
>>> the performance of the proposed solutions against pervasive monitoring.
>>> Some of the results of this working group may be experimental. There are
>>> numerous aspects that differ between DNS exchanges with an iterative
>>> resolver and exchanges involving DNS root/authoritative servers. The
>>> working group will work with DNS operators and developers (via the DNSOP
>>> WG) to ensure that proposed solutions address key requirements.
>>>
>>> DPRIVE is chartered to work on mechanisms that add confidentiality to
>>> the DNS. While it may be tempting to solve other DNS issues while adding
>>> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
>>> will not work on any integrity-only mechanisms.  Examples of the sorts
>>> of risks that DPRIVE will address can be found in [RFC 7626], and
>>> include both passive wiretapping and more active attacks, such as MITM
>>> attacks. DPRIVE will address risks to end-users' privacy (for example,
>>> which websites an end user is accessing).
>>>
>>> DPRIVE Work Items:
>>>
>>> - Develop requirements for adding confidentiality to DNS exchanges
>>> between recursive resolvers and authoritative servers (unpublished
>>> document).
>>>
>>> - Investigate potential solutions for adding confidentiality to DNS
>>> exchanges involving authoritative servers (Experimental).
>>>
>>> - Define, collect and publish performance data measuring effectiveness
>>> of DPRIVE-published technologies against pervasive monitoring attacks.
>>>
>>>
>>>
>>> ___
>>> dns-privacy mailing list
>>> dns-privacy@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 



signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Brian Haberman]

All,
 Thanks for the feedback. Tim and I will add some milestones to the
proposed charter and get it to our illustrious AD for review/handling.

Regards,
Brian

On 3/21/18 9:44 AM, Brian Haberman wrote:
> Slightly updated text to capture a missing work item...
> 
> https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt
> 
> Regards,
> Brian
> 
> On 3/19/18 11:07 AM, Brian Haberman wrote:
>> All,
>>  The chairs have been chatting with our AD about re-chartering the
>> WG. The text below is our proposed charter that we will discuss in our
>> session this week.
>>
>> Regards,
>> Brian & Tim
>>
>>
>> DPRIVE Charter 2.0
>>
>> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
>> provide confidentiality to DNS transactions in order to address concerns
>> surrounding pervasive monitoring (RFC 7258).
>>
>> The set of DNS requests that an individual makes can provide an attacker
>> with a large amount of information about that individual.  DPRIVE aims
>> to deprive the attacker of this information (The IETF defines pervasive
>> monitoring as an attack [RFC7258]).
>>
>> The initial focus of this Working Group was the development of
>> mechanisms that provide confidentiality and authentication between DNS
>> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
>> proposed standard solutions for the client-to-iterative resolvers
>> published, the working group turns its attention to the development of
>> documents focused on: 1) providing confidentiality to DNS transactions
>> between Iterative Resolvers and Authoritative Servers, and 2) measuring
>> the performance of the proposed solutions against pervasive monitoring.
>> Some of the results of this working group may be experimental. There are
>> numerous aspects that differ between DNS exchanges with an iterative
>> resolver and exchanges involving DNS root/authoritative servers. The
>> working group will work with DNS operators and developers (via the DNSOP
>> WG) to ensure that proposed solutions address key requirements.
>>
>> DPRIVE is chartered to work on mechanisms that add confidentiality to
>> the DNS. While it may be tempting to solve other DNS issues while adding
>> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
>> will not work on any integrity-only mechanisms.  Examples of the sorts
>> of risks that DPRIVE will address can be found in [RFC 7626], and
>> include both passive wiretapping and more active attacks, such as MITM
>> attacks. DPRIVE will address risks to end-users' privacy (for example,
>> which websites an end user is accessing).
>>
>> DPRIVE Work Items:
>>
>> - Develop requirements for adding confidentiality to DNS exchanges
>> between recursive resolvers and authoritative servers (unpublished
>> document).
>>
>> - Investigate potential solutions for adding confidentiality to DNS
>> exchanges involving authoritative servers (Experimental).
>>
>> - Define, collect and publish performance data measuring effectiveness
>> of DPRIVE-published technologies against pervasive monitoring attacks.
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 



signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Tony Finch]

Let's retry the tests with a hot cache, since that's maybe a bit more
fair. I've picked the shortest times I could get, which involved heating
up the resolver until it was no longer waiting 10s or 30s on lame
authoritative servers.

Unbound 1.6.0 TCP 8s
Unbound 1.6.0 UDP 0.4s
BIND 9.11 TCP 0.5s
BIND 9.11 UDP 0.5s
BIND 9.10 TCP 3s
BIND 9.10 UDP 0.5s
1.1.1.1 TCP 0.5s
1.1.1.1 UDP 0.4s
8.8.8.8 TCP 5s # drops connection after 60 queries
8.8.8.8 UDP 220s # it hates me
9.9.9.9 TCP 1s
9.9.9.9 UDP 3s
64.6.64.6 TCP 0.5s
64.6.64.6 UDP 0.5s

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Trafalgar: Cyclonic gale 7 to severe gale 9, occasionally storm 10 for a time
in northwest, becoming northwesterly 5 to 7 later. Very rough or high,
occasionally very high for a time in west, becoming rough or very rough later.
Rain or showers. Good, occasionally poor.

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

Re: [dns-privacy] Potential re-charter text

[Erik Kline]

Charter 2.1 looks fine to me.

On 5 April 2018 at 12:44, Brian Haberman  wrote:
> Tim & I are still looking for feedback on this updated charter. Please
> chime in or we will have to close the WG down.
>
> Brian
>
>
> On 3/21/18 9:44 AM, Brian Haberman wrote:
>> Slightly updated text to capture a missing work item...
>>
>> https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt
>>
>> Regards,
>> Brian
>>
>> On 3/19/18 11:07 AM, Brian Haberman wrote:
>>> All,
>>>  The chairs have been chatting with our AD about re-chartering the
>>> WG. The text below is our proposed charter that we will discuss in our
>>> session this week.
>>>
>>> Regards,
>>> Brian & Tim
>>>
>>>
>>> DPRIVE Charter 2.0
>>>
>>> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
>>> provide confidentiality to DNS transactions in order to address concerns
>>> surrounding pervasive monitoring (RFC 7258).
>>>
>>> The set of DNS requests that an individual makes can provide an attacker
>>> with a large amount of information about that individual.  DPRIVE aims
>>> to deprive the attacker of this information (The IETF defines pervasive
>>> monitoring as an attack [RFC7258]).
>>>
>>> The initial focus of this Working Group was the development of
>>> mechanisms that provide confidentiality and authentication between DNS
>>> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
>>> proposed standard solutions for the client-to-iterative resolvers
>>> published, the working group turns its attention to the development of
>>> documents focused on: 1) providing confidentiality to DNS transactions
>>> between Iterative Resolvers and Authoritative Servers, and 2) measuring
>>> the performance of the proposed solutions against pervasive monitoring.
>>> Some of the results of this working group may be experimental. There are
>>> numerous aspects that differ between DNS exchanges with an iterative
>>> resolver and exchanges involving DNS root/authoritative servers. The
>>> working group will work with DNS operators and developers (via the DNSOP
>>> WG) to ensure that proposed solutions address key requirements.
>>>
>>> DPRIVE is chartered to work on mechanisms that add confidentiality to
>>> the DNS. While it may be tempting to solve other DNS issues while adding
>>> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
>>> will not work on any integrity-only mechanisms.  Examples of the sorts
>>> of risks that DPRIVE will address can be found in [RFC 7626], and
>>> include both passive wiretapping and more active attacks, such as MITM
>>> attacks. DPRIVE will address risks to end-users' privacy (for example,
>>> which websites an end user is accessing).
>>>
>>> DPRIVE Work Items:
>>>
>>> - Develop requirements for adding confidentiality to DNS exchanges
>>> between recursive resolvers and authoritative servers (unpublished
>>> document).
>>>
>>> - Investigate potential solutions for adding confidentiality to DNS
>>> exchanges involving authoritative servers (Experimental).
>>>
>>> - Define, collect and publish performance data measuring effectiveness
>>> of DPRIVE-published technologies against pervasive monitoring attacks.
>>>
>>>
>>>
>>> ___
>>> dns-privacy mailing list
>>> dns-privacy@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Benno Overeinder]

Hi Ian,

> On 7 Apr 2018, at 08:05, Ian Maddison  wrote:
> 
> Hi Benno,
> 
> On Sat, 7 Apr 2018, at 01:35, Benno Overeinder wrote:
>> 
>> 
>> All solutions above are stable performant DNS-over-TLS implementations.
>> The open-source developers of all DNS resolvers mentioned above are
>> actively engaged and work closely together to secure interoperability.
> 
> Do they support rfc7828 EDNS0 keepalive and provide out of order responses ?
> 

Fair point.  

In the server implementation table 
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status the 
ticks with RFC7828 EDNS0 keep alive and OOP in the “context” of TCP/TLS 
features are currently BIND only. 

But to put things in perspective, we have now a colourful bag of caching 
resolvers/forwarders, with or without reverse proxies (e.g., NGINX, HAProxy or 
dnsdist) that can be used in various setups to run a DNS-over-TLS service.  I 
very much appreciate your operational perspective on the DNS-over-TLS 
implementations, either providing them to customers (running the servers) or 
how you would like to see these services made available (from a client 
perspective).  I hope to continue this discussion with you and other network 
engineers/operators.

To end in a positive swing, there is a lot of energy with the open-source DNS 
software developers and we are close to put the final ticks in the 
implementation table.  Unbound will do so in one of the next releases, Knot 
resolver made good progress in the past period, BIND developers are 
implementing DNS-over-TLS natively, and the PowerDNS developers support 
DNS-over-TLS in their product range.

Cheers,

— Benno


-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

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

Re: [dns-privacy] Potential re-charter text

[Ian Maddison]

Hi Benno,

On Sat, 7 Apr 2018, at 01:35, Benno Overeinder wrote:
> For information to the WG, Unbound and Knot Resolver have implemented> 
> DNS-over-TLS for one or two years now, and both are in use.
> Also qname> minimalisation has been implemented in Unbound and Knot Resolver 
> for 2> years already, and the feature is used by operators.
> 
> An other DNS-over-TLS solution is PowerDNS recursor in
> combination with> dnsdist; and in a similar way, BIND setups are a combination
> with NGINX> or HAProxy.
> 
> All solutions above are stable performant DNS-over-TLS
> implementations.> The open-source developers of all DNS resolvers mentioned 
> above are
> actively engaged and work closely together to secure interoperability.
Do they support rfc7828 EDNS0 keepalive and provide out of order
responses ?
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Bill Woodcock]

> On Apr 6, 2018, at 3:28 PM, Ian Maddison  wrote:
> I'd be extremely disappointed to see hear of the premature demise of this WG.
> As we approach the fifth anniversary of the summer of Snowden, I've the 
> impression
> of a job half one, despite all the commendable efforts of the IETF, this 
> group,
> individuals like Stéphane and the getdns team, etc, etc.

Agreed.

> Privacy enabled public recursives such as the very useful quad9.net service 
> are still relatively slow while the quicker ones from the good folks at 
> Sinodun suffer from a lack of clients

I take it the comparison you’re drawing is to the ones that John and Sara are 
running at 145.100.185.15/16?  If so, I’m not sure it’s useful to compare two 
servers in one location to 800 servers in 180 locations, but if you’re seeing 
poor performance from any Quad9 node, please open a bug report with a 
traceroute, so one of our folks can see what’s wrong and get it fixed.

> I see a lot of effort going into outreach but it still still seems like the 
> general public and journalists have yet to catch on to the scale and breadth 
> of this DNS problem

Agreed.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Benno Overeinder]

Hi,

Not necessarily reacting on the re-charter text discussion, but trying
to clear-out some potential misunderstanding (with me maybe?).

On 04/07/2018 12:28 AM, Ian Maddison wrote:
> Solid stub to recursive and qnamemin standards have been established but
> currently bind is the only performant DoT system and they've only
> recently announced work on qname minimalisation. 

For information to the WG, Unbound and Knot Resolver have implemented
DNS-over-TLS for one or two years now, and both are in use.  Also qname
minimalisation has been implemented in Unbound and Knot Resolver for 2
years already, and the feature is used by operators.

An other DNS-over-TLS solution is PowerDNS recursor in combination with
dnsdist; and in a similar way, BIND setups are a combination with NGINX
or HAProxy.

All solutions above are stable performant DNS-over-TLS implementations.
The open-source developers of all DNS resolvers mentioned above are
actively engaged and work closely together to secure interoperability.

> I see a lot of effort going into outreach but it still still seems like
> the general public and journalists have yet to catch on to the scale and
> breadth of this DNS problem, while the engineering community may have
> lost some of their initial momentum.

Only speaking for the open-source DNS implementers, this is certainly
not the case.  We all invest substantial time in the continued
development of DNS privacy features/functionality in our software.

Best regards,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/

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

Re: [dns-privacy] Potential re-charter text

[Ian Maddison]

Dear DPriv

On Thu, 5 Apr 2018, at 21:44, Brian Haberman wrote:
> Tim & I are still looking for feedback on this updated charter. Please> chime 
> in or we will have to close the WG down.

At first I was quite surprised to read this, especially in the current
climate, but on second thoughts despite all the recent press attention
regarding privacy, I don't think I've seen any mention of DNS.
I'd be extremely disappointed to see hear of the premature demise of
this WG. As we approach the fifth anniversary of the summer of Snowden,
I've the impression of a job half one, despite all the commendable
efforts of the IETF, this group, individuals like Stéphane and the
getdns team, etc, etc.
Solid stub to recursive and qnamemin standards have been established but
currently bind is the only performant DoT system and they've only
recently announced work on qname minimalisation. Privacy enabled public
recursives such as the very useful quad9.net service are still
relatively slow while the quicker ones from the good folks at Sinodun
suffer from a lack of clients, according to their published qps and
therefore can't be considered a viable solution whilst recursive to
authoritative remains unprotected.
I see a lot of effort going into outreach but it still still seems like
the general public and journalists have yet to catch on to the scale
and breadth of this DNS problem, while the engineering community may
have lost some of their initial momentum. This despite privacy becoming
a major public issue recently. So please just recharter the WG and
finish the job you started so well ! Please fix the recursive to
authoritative problem and look at alternatives to DoT, such as QUIC and
HTTPS before you go.
Many thanks :o)

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

Re: [dns-privacy] Potential re-charter text

[Paul Hoffman]

The new charter text seems fine, even if we don't actually do all four 
work items.


--Paul Hoffman

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

Re: [dns-privacy] Potential re-charter text

[Stephen Farrell]

On 05/04/18 20:44, Brian Haberman wrote:
> Tim & I are still looking for feedback on this updated charter. Please
> chime in or we will have to close the WG down.

LGTM. Don't close it down. Get folks to do the work:-)

S

> 
> Brian
> 
> 
> On 3/21/18 9:44 AM, Brian Haberman wrote:
>> Slightly updated text to capture a missing work item...
>>
>> https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt
>>
>> Regards,
>> Brian
>>
>> On 3/19/18 11:07 AM, Brian Haberman wrote:
>>> All,
>>>  The chairs have been chatting with our AD about re-chartering the
>>> WG. The text below is our proposed charter that we will discuss in our
>>> session this week.
>>>
>>> Regards,
>>> Brian & Tim
>>>
>>>
>>> DPRIVE Charter 2.0
>>>
>>> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
>>> provide confidentiality to DNS transactions in order to address concerns
>>> surrounding pervasive monitoring (RFC 7258).
>>>
>>> The set of DNS requests that an individual makes can provide an attacker
>>> with a large amount of information about that individual.  DPRIVE aims
>>> to deprive the attacker of this information (The IETF defines pervasive
>>> monitoring as an attack [RFC7258]).
>>>
>>> The initial focus of this Working Group was the development of
>>> mechanisms that provide confidentiality and authentication between DNS
>>> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
>>> proposed standard solutions for the client-to-iterative resolvers
>>> published, the working group turns its attention to the development of
>>> documents focused on: 1) providing confidentiality to DNS transactions
>>> between Iterative Resolvers and Authoritative Servers, and 2) measuring
>>> the performance of the proposed solutions against pervasive monitoring.
>>> Some of the results of this working group may be experimental. There are
>>> numerous aspects that differ between DNS exchanges with an iterative
>>> resolver and exchanges involving DNS root/authoritative servers. The
>>> working group will work with DNS operators and developers (via the DNSOP
>>> WG) to ensure that proposed solutions address key requirements.
>>>
>>> DPRIVE is chartered to work on mechanisms that add confidentiality to
>>> the DNS. While it may be tempting to solve other DNS issues while adding
>>> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
>>> will not work on any integrity-only mechanisms.  Examples of the sorts
>>> of risks that DPRIVE will address can be found in [RFC 7626], and
>>> include both passive wiretapping and more active attacks, such as MITM
>>> attacks. DPRIVE will address risks to end-users' privacy (for example,
>>> which websites an end user is accessing).
>>>
>>> DPRIVE Work Items:
>>>
>>> - Develop requirements for adding confidentiality to DNS exchanges
>>> between recursive resolvers and authoritative servers (unpublished
>>> document).
>>>
>>> - Investigate potential solutions for adding confidentiality to DNS
>>> exchanges involving authoritative servers (Experimental).
>>>
>>> - Define, collect and publish performance data measuring effectiveness
>>> of DPRIVE-published technologies against pervasive monitoring attacks.
>>>
>>>
>>>
>>> ___
>>> dns-privacy mailing list
>>> dns-privacy@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Brian Haberman]

Slightly updated text to capture a missing work item...

https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt

Regards,
Brian

On 3/19/18 11:07 AM, Brian Haberman wrote:
> All,
>  The chairs have been chatting with our AD about re-chartering the
> WG. The text below is our proposed charter that we will discuss in our
> session this week.
> 
> Regards,
> Brian & Tim
> 
> 
> DPRIVE Charter 2.0
> 
> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
> provide confidentiality to DNS transactions in order to address concerns
> surrounding pervasive monitoring (RFC 7258).
> 
> The set of DNS requests that an individual makes can provide an attacker
> with a large amount of information about that individual.  DPRIVE aims
> to deprive the attacker of this information (The IETF defines pervasive
> monitoring as an attack [RFC7258]).
> 
> The initial focus of this Working Group was the development of
> mechanisms that provide confidentiality and authentication between DNS
> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
> proposed standard solutions for the client-to-iterative resolvers
> published, the working group turns its attention to the development of
> documents focused on: 1) providing confidentiality to DNS transactions
> between Iterative Resolvers and Authoritative Servers, and 2) measuring
> the performance of the proposed solutions against pervasive monitoring.
> Some of the results of this working group may be experimental. There are
> numerous aspects that differ between DNS exchanges with an iterative
> resolver and exchanges involving DNS root/authoritative servers. The
> working group will work with DNS operators and developers (via the DNSOP
> WG) to ensure that proposed solutions address key requirements.
> 
> DPRIVE is chartered to work on mechanisms that add confidentiality to
> the DNS. While it may be tempting to solve other DNS issues while adding
> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
> will not work on any integrity-only mechanisms.  Examples of the sorts
> of risks that DPRIVE will address can be found in [RFC 7626], and
> include both passive wiretapping and more active attacks, such as MITM
> attacks. DPRIVE will address risks to end-users' privacy (for example,
> which websites an end user is accessing).
> 
> DPRIVE Work Items:
> 
> - Develop requirements for adding confidentiality to DNS exchanges
> between recursive resolvers and authoritative servers (unpublished
> document).
> 
> - Investigate potential solutions for adding confidentiality to DNS
> exchanges involving authoritative servers (Experimental).
> 
> - Define, collect and publish performance data measuring effectiveness
> of DPRIVE-published technologies against pervasive monitoring attacks.
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 



signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[tjw ietf]

Stephane

Good catch.  I had excised it from the Work Items, but missed the one in
the main text.

Tim


On Mon, Mar 19, 2018 at 4:11 PM, Stephane Bortzmeyer 
wrote:

> On Mon, Mar 19, 2018 at 11:07:24AM -0400,
>  Brian Haberman  wrote
>  a message of 115 lines which said:
>
> > DPRIVE Charter 2.0
>
> Basically OK for me.
>
> > exchanges involving DNS root/authoritative servers.
>
> I would just say "DNS authoritative servers". Root servers are not
> really special in that respect.
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Potential re-charter text

[Brian Haberman]

All,
 The chairs have been chatting with our AD about re-chartering the
WG. The text below is our proposed charter that we will discuss in our
session this week.

Regards,
Brian & Tim


DPRIVE Charter 2.0

The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
provide confidentiality to DNS transactions in order to address concerns
surrounding pervasive monitoring (RFC 7258).

The set of DNS requests that an individual makes can provide an attacker
with a large amount of information about that individual.  DPRIVE aims
to deprive the attacker of this information (The IETF defines pervasive
monitoring as an attack [RFC7258]).

The initial focus of this Working Group was the development of
mechanisms that provide confidentiality and authentication between DNS
Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
proposed standard solutions for the client-to-iterative resolvers
published, the working group turns its attention to the development of
documents focused on: 1) providing confidentiality to DNS transactions
between Iterative Resolvers and Authoritative Servers, and 2) measuring
the performance of the proposed solutions against pervasive monitoring.
Some of the results of this working group may be experimental. There are
numerous aspects that differ between DNS exchanges with an iterative
resolver and exchanges involving DNS root/authoritative servers. The
working group will work with DNS operators and developers (via the DNSOP
WG) to ensure that proposed solutions address key requirements.

DPRIVE is chartered to work on mechanisms that add confidentiality to
the DNS. While it may be tempting to solve other DNS issues while adding
confidentiality, DPRIVE is not the working group to do this.  DPRIVE
will not work on any integrity-only mechanisms.  Examples of the sorts
of risks that DPRIVE will address can be found in [RFC 7626], and
include both passive wiretapping and more active attacks, such as MITM
attacks. DPRIVE will address risks to end-users' privacy (for example,
which websites an end user is accessing).

DPRIVE Work Items:

- Develop requirements for adding confidentiality to DNS exchanges
between recursive resolvers and authoritative servers (unpublished
document).

- Investigate potential solutions for adding confidentiality to DNS
exchanges involving authoritative servers (Experimental).

- Define, collect and publish performance data measuring effectiveness
of DPRIVE-published technologies against pervasive monitoring attacks.



signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy