Subject: [Doh] Privacy Considerations Text (#2)

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 14:43:07 -0400

Hi All,

We may be getting close to bridging the important points here - so we've
made an update to the PR. (its still not merged into the working copy, but
it has changed). and we can iterate from there. Thank you for the comments,
and especially text proposals - they really help.

The live copy is at
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and I'll
snapshot it again at the end of this email

The deltas make more explicit comparisons between DoH and Do(TLS), calls
out some rationale about the full ecosystem in the same text that asks you
to consider the cost/benefits of http features, and includes the new text
about a minimal data set.

-Patrick

# Privacy Considerations {#PrivacyConsiderations}

{{RFC7626}} discusses DNS Privacy Considerations in both "On the
wire" (Section 2.4), and "In the server" (Section 2.5) contexts. This
is also a useful framing for DoH's privacy considerations.

## On The Wire {#OnTheWire}

DoH encrypts DNS traffic and requires authentication of the
server. This mitigates both passive surveillance {{RFC7258}} and
active attacks attempting to divert DNS traffic to rogue servers
({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides
similar protections, while direct UDP and TCP based transports are
vulnerable to this class of information leak.

Additionally, the use of the HTTPS default port 443 and the ability to
mix DoH traffic with other HTTPS traffic on the same connection can
deter on-path devices from interfering with DNS operations and make
DNS traffic analysis more difficult.

## In The Server {#InTheServer}

A DoH application is built on IP, TCP, TLS, and HTTP. Each layer
contains one or more common features that can be used to correlate
different queries to the same identity. DNS transports will generally
carry the same privacy properties of the layers used to implement
them. For example, the properties of IP, TCP, and TLS apply to DNS
over TLS implementations.

The privacy considerations of using the HTTPS layer in DoH are
incremental to those of DNS over TLS. DoH is not known to introduce
new concerns beyond those associated with HTTPS.

At the IP level, the client address provides obvious correlation
information. This can be mitigated by use of a NAT, proxy, VPN, or
simple address rotation over time. It may be aggravated by use of a
DNS server that can correlate real-time addressing information with
other personal identifiers, such as when a DNS server and DHCP server
are operated by the same entity.

TCP-based solutions may seek performance through the use of TCP Fast
Open {{RFC7413}}. The cookies used in TCP Fast Open allow servers to
correlate different TCP sessions together.

TLS based implementations often achieve better handshake performance
through the use of some form of session resumption mechanism such as
session tickets {{RFC5077}}. Session resumption creates trivial
mechanisms for a server to correlate different TLS connections
together.

HTTP's feature set can also be used for identification and tracking in
a number of different ways. For example, authentication request header
fields explicitly identify profiles in use, and HTTP Cookies are
designed as an explicit state tracking mechanism between the client
and serving site and often are used as an authentication mechanism.

Additionally, the User-Agent and Accept-Language request header fields
often convey specific information about the client version or locale.
This facilitates content negotiation and operational work-arounds for
implementation bugs. Request header fields that control caching
can expose state information about a subset of the client's
history. Mixing DoH requests with other HTTP requests on the same
connection also provides an opportunity for richer data correlation.

The DoH protocol design allows applications to fully leverage all the
features of the HTTP ecosystem, including features not enumerated
here. Implementations of DoH clients and servers need to consider the
benefit and privacy impact of these features, and their deployment
context, when deciding whether or not to enable them. Implementations
should expose the minimal set of data needed to achieve the desired
feature set.

---

From: "Hewitt, Rory" <[email-masked]>
Date: Thu, 21 Jun 2018 18:50:09 +0000

+1 - new text looks good AND is readable.

From: Patrick McManus [mailto:[email-masked]]
Sent: Thursday, June 21, 2018 11:43 AM
To: DoH WG <[email-masked]>
Subject: [Doh] Privacy Considerations Text (#2)

Hi All,

We may be getting close to bridging the important points here - so we've made 
an update to the PR. (its still not merged into the working copy, but it has 
changed). and we can iterate from there. Thank you for the comments, and 
especially text proposals - they really help.

The live copy is at 
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dohwg_draft-2Dietf-2Ddoh-2Ddns-2Dover-2Dhttps_pull_200&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=rHk_4z4OwUA_g3kaoRhg_WqOtJkx91PA4rISmv5Wk3I&s=qMyTSeJFZ_PRxu5ZamUK2J9r1BjdanWU0u2rS-03i8I&e=> 
and I'll snapshot it again at the end of this email

The deltas make more explicit comparisons between DoH and Do(TLS), calls out 
some rationale about the full ecosystem in the same text that asks you to 
consider the cost/benefits of http features, and includes the new text about a 
minimal data set.

-Patrick

TCP-based solutions may seek performance through the use of TCP Fast
Open {{RFC7413}}.. The cookies used in TCP Fast Open allow servers to
correlate different TCP sessions together.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jun 2018 11:56:06 -0700

Can you please enable comments on the PR so that people can provide
detailed feedback

-Ekr

On Thu, Jun 21, 2018 at 11:43 AM, Patrick McManus <[email-masked]>
wrote:

> The live copy is at https://github.com/dohwg/
> draft-ietf-doh-dns-over-https/pull/200 and I'll snapshot it again at the
> end of this email
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jun 2018 19:10:37 +0000

On Jun 21, 2018, at 11:56 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Can you please enable comments on the PR so that people can provide detailed feedback

We had them on earlier, and there was a request to turn them off and have all the comments here on the list. Can you provided detailed feedback on the full text Patrick included in his message?

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 15:16:58 -0400

hi - I'm pretty sure ekr is referring to a sidebar suggestion he made to me
that would strengthen the cookie specific text (as these are the primary
and, most concerning, flexible state tracking mechanism in http). Its a
good suggestion - stay tuned and I'll write it up.

On Thu, Jun 21, 2018 at 3:10 PM, Paul Hoffman <[email-masked]>
wrote:

> We had them on earlier, and there was a request to turn them off and have
> all the comments here on the list. Can you provided detailed feedback on
> the full text Patrick included in his message?
>
> --Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jun 2018 12:38:40 -0700

On Thu, Jun 21, 2018 at 12:10 PM, Paul Hoffman <[email-masked]>
wrote:

> all the comments here on the list.

Who made that request? That's not how any other group I work with is using
Github.

Can you provided detailed feedback on the full text Patrick included in his
> message?

Not as conveniently as in Github, no

-Ekr

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 20:07:00 +0000

> and especially text proposals - they really help.

Is this iteration supposed to address or include previous comments from [1]?
I don't see [1] addressed.

Specifically it does not _explicitly_ convey that 
"DoH introduces new privacy concerns".

I propse to change:
> incremental to those of DNS over TLS.

to be more explicit about it:
"DoH introduces new privacy concerns 
when compared with DNS over UDP, TCP or TLS (RFC7858)."
(this sentence - and more - has been proposed in [1] before by others)

> new concerns beyond those associated with HTTPS.

Actually I think it does because it combines two protocols (DNS + HTTPS) that haven't been
combined before and DNS+HTTPS has more privacy implications than just the sum of IP, TCP, TLS and HTTP
when DoH server are not used exclusively for DoH.

Sara wrote [1]:
> [...] [DoH] introduces new privacy concerns when compared
> with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decision is that 
> retaining the ability to leverage the full functionality of the HTTP ecosystem is more
> important than placing any constraints on this new protocol based on privacy considerations."

Also the rationale behind the design decision is important.

[1] https://mailarchive.ietf.org/arch/msg/doh/_ju-J52e5cf7UNpgwhCbq5pln5Y
 
-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 16:57:24 -0400

> I don't see [1] addressed.
I believe it addresses where we are converging related to those comments
and others. The text includes, among other things, the notion that HTTPS is
an incremental consideration to TLS and that the HTTPS considerations deal
with a large number of features because DoH design allows leveraging of the
full HTTP ecosystem.

---

From: Mateusz Jończyk <[email-masked]>
Date: Fri, 22 Jun 2018 17:34:02 +0200

> over TLS implementations.

The sentence above is misleading. We are talking about DOH, not DNS over TLS.

> new concerns beyond those associated with HTTPS.

I have been thinking that a DoH client would open a long-running connection to a
DoH server. In such a case, request correlation could be simple and we should
drop the "is not known to introduce new concerns" sentence.

> Open {{RFC7413}}.. 

Double dot here.

> The cookies used in TCP Fast Open allow servers to

"and server" would be better.

> [...]

It would be IMHO better to write "Implementations are advised to expose the
minimal set of data..." to avoid the use of the word "should" (as this is not a
RFC2119 SHOULD and IMHO shouldn't be, as I explained previously on the list [1]).

Greetings,
Mateusz Jończyk

[1] https://www.ietf.org/mail-archive/web/doh/current/msg00819.html

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jun 2018 15:42:52 +0000

On Jun 22, 2018, at 8:34 AM, Mateusz Jończyk <[email-masked]> wrote:
> Signed PGP part

Earlier, the WG wanted the document to compare (where appropriate) DoH and DoT. It seems appropriate to do so in the privacy considerations to show that DoH has one more layer that can  make user tracking more possible.

> drop the "is not known to introduce new concerns" sentence.

Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend opening long-running connections, and explain the operational pros and cons of doing so.

>> TCP-based solutions may seek performance through the use of TCP Fast

Thanks; fixed in editor's copy.

> "and server" would be better.

Agree; fixed in editor's copy.

> RFC2119 SHOULD and IMHO shouldn't be, as I explained previously on the list [1]).

Will do.

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Fri, 22 Jun 2018 17:57:46 +0200

W dniu 22.06.2018 o 17:42, Paul Hoffman pisze:
> Earlier, the WG wanted the document to compare (where appropriate) DoH and DoT. 
> It seems appropriate to do so in the privacy considerations to show that DoH > has one more layer that can  make user tracking more possible.
> 
OK

> Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend opening long-running connections, and explain the operational pros and cons of doing so.

OK, now I have read that passage again and understand it.
I would argue that this should be discussed explicitly in the "Privacy
considerations" section.

Greetings,
Mateusz Jończyk

---

From: Patrick McManus <[email-masked]>
Date: Fri, 22 Jun 2018 12:08:06 -0400

> Agree; fixed in editor's copy.
quick note on the scope of an HTTP cookie is actually the site, not the
server you are connected to which is why it uses that language.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jun 2018 16:15:28 +0000

On Jun 22, 2018, at 9:08 AM, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
> On Fri, Jun 22, 2018 at 11:42 AM, Paul Hoffman <[email-masked]> wrote:
> 
> >> and serving site and often are used as an authentication mechanism..
> > 
> quick note on the scope of an HTTP cookie is actually the site, not the server you are connected to which is why it uses that language.
> 

quick note that having both HTTP and DNS people active in this discussion is being amazingly educational for both teams.

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Jun 2018 17:26:16 +0100

On 22/06/2018 17:08, Patrick McManus wrote:

> server you are connected to 

Or any other site that's covered by the same cookie (if it's a
dot-prefixed domain cookie)

Ray

---

From: Mateusz Jończyk <[email-masked]>
Date: Sat, 23 Jun 2018 13:22:34 +0200

> I would argue that this should be discussed explicitly in the "Privacy

I would propose to add the following text:

	Because of performance reasons, DOH clients are advised to open
	long-running connections to the DOH server. However, in such a case the
	server is able to correlate all the requests within a connection.
	Therefore it is advisable for DOH clients to close and reopen the
	connection to the DOH server e.g. every hour or when outside IP address
	changes - to make request correlation more difficult.

I am happy to live in the EU. AFAIK our law makes doing such request
correllation for tracking purposes illegal in most cases.

Greetings,
Mateusz Jończyk

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Jun 2018 09:14:47 -0400

It might make sense to mention that TCP correlates different requests
together on the same connection when talking about TCP (though you could
argue this is pretty much just IP correlation).

I don't think we can or should craft a specification recommendation in this
space though. Chartering advice for HTTP has consistently required better
use of long lived connections, clients demand low latency, etc. and there's
no science behind any particular number as it relates to correlation.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 25 Jun 2018 16:30:03 +0100

> On 21 Jun 2018, at 21:57, Patrick McManus <[email-masked]> wrote:
> 
> On Thu, Jun 21, 2018 at 4:07 PM, nusenu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I believe it addresses where we are converging related to those comments and others. The text includes, among other things, the notion that HTTPS is an incremental consideration to TLS and that the HTTPS considerations deal with a large number of features because DoH design allows leveraging of the full HTTP ecosystem.

Hi Patrick, 

Thanks for the updates, I think the discussion on cookies is particularly helpful. I’m not sure it yet addresses everything that has been raised on the list, I believe the PR proposed below does.

> On 21 Jun 2018, at 21:07, nusenu <[email-masked]> wrote:

Actually, I think this is a very salient point. DoH is the combination of DNS wireformat messages and the HTTP layer. That combination alone introduces new privacy concerns beyond that of either standalone protocol so I think this does need to be framed differently. 

I’ve done a PR
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/205 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/205>
which removes the above text and more clearly breaks down the issue along the lines of the layer model already used. Specifically it add this text:

---
Session resumption creates trivial mechanisms for a server to correlate TLS 
connections together.

+ ### DNS Specific considerations
+
+ Whilst DNS transports will generally carry the same privacy properties of the
+ layers used to implement them the standard DNS wireformat itself notably
+ contains no client identifiers. Using HTTPS as a transport therefore introduces
+ new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with regard to
+ additional data that may be visible to a DoH server compared to a DNS resolver.

+ ### HTTP Specific considerations (#HTTPconsiderations)

+ This section provides guidance but places only minor restrictions on HTTP
+ features (specifically HTTP cookies) that may be used in DoH. The design
+ rationale for this decision is that retaining the ability to leverage the full
+ functionality of the HTTP ecosystem is more important than placing any
+ constraints on this new protocol based on privacy considerations.

—

Sara.

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 25 Jun 2018 15:30:30 +0000

Hey Mateusz,

I like that. Here's an alternate way of saying it (not 'better', just 'different'):

	Users with concerns about request correlation within a
	connection may choose to close and reopen any connections
	between a DoH client and the DoH server on a regular basis
	(e.g. when the outside IP address changes). However, this
	may reduce the performance gains realized by using a
	long-running connection between client and server.

Thanks,

Rory

-----Original Message-----
From: Mateusz Jończyk [mailto:[email-masked]] 
Sent: Saturday, June 23, 2018 4:23 AM
To: Paul Hoffman <[email-masked]>; DoH WG <[email-masked]>
Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2)

W dniu 22.06.2018 o 17:57, Mateusz Jończyk pisze:
>>> I have been thinking that a DoH client would open a long-running 
>>> connection to a DoH server. In such a case, request correlation 
>>> could be simple and we should drop the "is not known to introduce new concerns" sentence.
>>

I am happy to live in the EU. AFAIK our law makes doing such request correllation for tracking purposes illegal in most cases.

Greetings,
Mateusz Jończyk

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Jun 2018 19:40:20 -0400

Hi Sara,

> + contains no client identifiers.
>

That's mostly true imo (modulo perhaps edns client subnet)

Using HTTPS as a transport therefore introduces
> + additional data that may be visible to a DoH server compared to a DNS
I do agree that HTTP adds additional considerations, which is what the
existing text describes. But I don't agree with this sentence which,
significantly through the use of therefore, indicates HTTPS has client
identifiers and other transports do not.

The previous several paragraphs have enumerated client identifiers also
present in IP (therefore UDP), TCP, and TLS. Everything that transports
wireformat.

What if, instead, we add a new first paragraph to the "In the server"
section along the lines of

"The original DNS wireformat contains no client identifiers, however
various transports of the DNS wireformat do provide data that can be used
for request correlation. HTTPS presents new considerations for correlation
ranging from explicit HTTP cookies to implicit fingerprinting of the unique
set and ordering of request headers."

> + ### HTTP Specific considerations (#HTTPconsiderations)
I think this is largely what the paragraph that begins "The DoH protocol
design allows applications to fully leverage.." is conveying. Maybe it can
move towards what you are thinking.. wdyt of:

The DoH protocol design allows applications to fully leverage the HTTP
ecosystem, including features not enumerated here. Utilizing the full
set of HTTP features enables DoH to be more than an HTTP tunnel, but
also opens implementations up to the full set of privacy
considerations of HTTP.

Implementations of DoH clients and servers need to consider the
benefit and privacy impact of these features, and their deployment
context, when deciding whether or not to enable them. Implementations
are advised to expose the minimal set of data needed to achieve the desired
feature set.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jun 2018 22:00:19 -0400

On Mon, Jun 25, 2018 at 07:40:20PM -0400, Patrick McManus wrote:
> What if, instead, we add a new first paragraph to the "In the server" section
> along the lines of
> 
> "The original DNS wireformat contains no client identifiers, however various
> transports of the DNS wireformat do provide data that can be used for request
> correlation. HTTPS presents new considerations for correlation ranging from
> explicit HTTP cookies to implicit fingerprinting of the unique set and ordering
> of request headers."

I think this is good (sorry for my recent silence, but I've been
watching this discussion avidly & thank the editors for their good
work).  I particularly agree that it is fair to note that lots of
servers have been doing various kinds of request correlation for a
long time.

> are advised to expose the minimal set of data needed to achieve the desired

I think this is good, too -- it's neutral while yet raising the right
degree of alarm.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 26 Jun 2018 08:44:50 -0400

> I think this is good, too -- it's neutral while yet raising the right

Is there something this text could reference that DOH implementers could
read that would allow them to navigate privacy in HTTP? (That is, rather
than just raising the alarm, point to some reference that could allow them
to choose a minimal set for their needs, etc.)

best, Joe

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Jun 2018 09:11:06 -0400

> to choose a minimal set for their needs, etc.)
Mark and I discussed that a little bit - because it certainly should exist
in the HTTP world and ideally this section would just point to that and be
90% shorter. However we couldn't identify anything satisfying - but we did
open an issue on BCP56bis which would be, imo, a fine place to cover this
in more detail. But that doc isn't going to be complete soon.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 26 Jun 2018 10:11:38 -0400

> in more detail. But that doc isn't going to be complete soon.

Cool! Thanks and makes sense...

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 26 Jun 2018 17:50:30 +0100

> On 26 Jun 2018, at 00:40, Patrick McManus <[email-masked]> wrote:
> 
> Hi Sara,

> I do agree that HTTP adds additional considerations, which is what the existing text describes. But I don't agree with this sentence which, significantly through the use of therefore, indicates HTTPS has client identifiers and other transports do not.

Thats a pretty defensive reading of this given the 3 paragraphs that precede it… it is intended to illustrate that the delta from DNS-over-UDP/TCP/TLS to DoH introduces _additional_ transport client identifiers, which it does. 

> 
> The previous several paragraphs have enumerated client identifiers also present in IP (therefore UDP), TCP, and TLS. Everything that transports wireformat.
> 
> What if, instead, we add a new first paragraph to the "In the server" section along the lines of
> 
> "The original DNS wireformat contains no client identifiers, however various transports of the DNS wireformat do provide data that can be used for request correlation. HTTPS presents new considerations for correlation ranging from explicit HTTP cookies to implicit fingerprinting of the unique set and ordering of request headers.”

But I can live with this suggested text… we could say ‘standard’ (at the time or writing) here because RFC7871 (EDNS Client Subnet) is actually only an Informational RFC and ‘original’ could be read to imply there are later identifiers defined. 

> I think this is largely what the paragraph that begins "The DoH protocol design allows applications to fully leverage.." is conveying. Maybe it can move towards what you are thinking.. wdyt of:
> 
> 

I’d like to see this say ‘at the cost of opening up implementations to the..’ to fully recognise the trade off but otherwise I think we are as converged as we are ever going to be :-) 

Thanks

Sara.

---

From: nusenu <[email-masked]>
Date: Tue, 26 Jun 2018 18:16:00 +0000

> + additional data that may be visible to a DoH server compared to a DNS resolver.

+1 to this, especially the following sentence is clear and explicit about the privacy delta of
DoH vs. i.e. DoT:
"Using HTTPS as a transport therefore introduces new privacy concerns over DNS over UDP, TCP or TLS (RFC7858)"

---

From: nusenu <[email-masked]>
Date: Tue, 26 Jun 2018 18:18:00 +0000

> set and ordering of request headers."

"various transports" is less specific than previous proposals.

Note the delta between "HTTPS presents new considerations for correlation" and clearly stating: "introduces new privacy concerns" (previously proposed)

Generally speaking I consider this less frank about the privacy implications of DoH than previous proposals
from Sara but it is understandable that draft authors dislike having "introduces new privacy concerns" in their draft.

> also opens implementations up to the full set of privacy

also here, note "considerations" vs. "concerns"
 
I find Sara's version made it more clear that here has been made a 
deliberate design decision to accept the privacy concerns 
to retain full functionality.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Jun 2018 14:44:12 -0400

Hi Sara. Thanks again for this.
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/206

On Tue, Jun 26, 2018 at 12:50 PM, Sara Dickinson <[email-masked]> wrote:

>
> But I can live with this suggested text… we could say ‘standard’ (at the
> time or writing) here because RFC7871 (EDNS Client Subnet) is actually only
> an Informational RFC and ‘original’ could be read to imply there are later
> identifiers defined.
>
>
my PR ended up saying "DNS wireformat {{RFC1035}}" ..

>
> I’d like to see this say ‘at the cost of opening up implementations to
> the..’ to fully recognise the trade off but otherwise I think we are as
> converged as we are ever going to be :-)
>
>
sounds ok to me.

---

From: Howard Chu <[email-masked]>
Date: Wed, 27 Jun 2018 15:15:52 +0100

Agree with nusenu, Sara's original text is more explicit and that's what you 
need when the topic is privacy considerations.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/