Hi Mohamed,
Some replies in-line.
On Fri, Feb 24, 2017 at 12:55 AM,
<mohamed(_dot_)boucadair(_at_)orange(_dot_)com> wrote:
Hi Ted,
Please see inline.
Cheers,
Med
*De :* Ted Hardie [mailto:ted(_dot_)ietf(_at_)gmail(_dot_)com]
*Envoyé :* vendredi 24 février 2017 00:40
*À :* BOUCADAIR Mohamed IMT/OLN
*Cc :* ietf(_at_)ietf(_dot_)org;
draft-hardie-privsec-metadata-insertion(_at_)ietf(_dot_)org
*Objet :* Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt>
(Design considerations for Metadata Insertion) to Informational RFC
HI Mohamad,
Thanks for rechecking; some further comments in-line.
On Wed, Feb 22, 2017 at 11:21 PM,
<mohamed(_dot_)boucadair(_at_)orange(_dot_)com> wrote:
Hi Ted,
Thank you for the reply and for implementing these changes.
I checked the diff, but I’m afraid the -06 version has the same issues as
the ones I reported in January 31.
I did respond to the particular comments and text proposals, so I assume
this is the more general issue. If I understand correctly, you would
prefer this document to be structured as a revision to the threat model
document or connected to a larger consideration of the issues. I
understand that, and it was considered, but I believe that this format is
still the most effective for the narrow issue it addresses.
[Med] That was one of my concerns; not the only one. In Particular, I’m
trying to understand how this document will be used in the future to better
strengthen forthcoming specifications. Further, the experience I had when
advancing some RFCs is that RFC7258 wording can be further enhanced to
provide clear guidance. Also, considerations such as the following are
missing from the document:
It's difficult to say how something will be used in the future. My intent
(and the understanding of other reviewers) is to highlight that these
mechanisms have a privacy-damaging result and that this should be
considered. In particularly, I'm concerned that some application functions
in the network (e.g. recursive resolvers or proxies) do not consider the
postive privacy implications of their aggregation and so do not consider
adding this data back as problematic. Highlighting this enables them to
see this traffic in a different context.
* that data may not be always available to the endhost
Understood, but even in this case, it is better to make the permission to
add the data explicit. It is also often possible for the end system to gain
this data at the cost of other traffic(e.g. the STUN server requests noted
in the document). If this can be done in parallel with other actions, then
the latency impact can be minimized.
* a misbehaving node may be tempted to spoof the data to be injected. A
remote device that will use that data to enforce policies will be broken.
This point was discussed extensively in the GEOPRIV work and essentially a
single carve-out was made: for emergency services, where falsely asserted
location data could be used to SWAT individuals or consume safety
resources. I don't think that falls into this narrow advice, but I would
be willing to add something like this to the security considerations:
"Note that some emergency service recipients, notably PSAPs (Public Safety
Answering Points) may prefer data provided by a network to data provided by
end system, because an end system could use false data to attack others or
consume resources. While this has the consequence that the data available
to the PSAP is often more coarse than that available to the end system, the
risk of false data being provided involved a risk to the lives of those
targeted."
* it was reported in the past that some browsers leak the MSISDN and other
sensitive data.
This is true, but it seems to me unrelated to the point of the document.
From that flow some of your other concerns about audience, at least as I
understand. As written, this is narrow advice for a broad audience:
basically, anyone who would consider the form of metadata insertion it
describes. You would, if I understand you, prefer a narrower description
of the audience in a larger context.
[Med] The key point here is about the practicality of implementing the
advice NOT changing the scope. For example, the document says that it is
better that a host is injecting the data but the document does not question
whether that supplied data can be trusted or not, or how the consent will
be obtained from a user.
In general, the point of the document is that the host should be able to
omit the data without mid-network devices adding it back. That's the point
of protecting the traffic in the first place, after all. I am saying that
if the protocols require the data, then getting it from the end host has
better privacy properties than getting from it from mid-network entities.
For example, the document states that the information in a Forward-For
header can be supplied by the host itself and then communicated to a remote
consumer. This is indeed possible, but because of abusing hosts some
servers implement whitelists to trust proxies; see
https://meta.wikimedia.org/w/extensions/TrustedXFF/trusted-hosts.txt.
The Wikimedia case is a very interesting one to raise, because it derives
from a set of assumptions about the network that are somewhat flawed and
then attempts to patch those flaws in ways that actually damage the
mechanisms of the system they originally built.
Wikimedia wants to allow folks to edit without login credentials. This
allows for anonymous users to make corrections or additions; this is a
goal. The consequence of that goal being achieved is that trolls or
malicious editors can have at anything they want.
Rather than institute credentials and ACLs, Wikimedia attempts to
substitute blocking by IP for blocking by credential. The property they
are looking for in IPs is not really there, though: they are not unique to
individuals, especially over time.
This damages those who share IP addresses (due to NATs or proxies). As far
as I can tell, the NAT problem is simply treated as collateral damage. For
the proxies, they attempt to work around the damage using XFF. That's
spoofable, though, so they attempt to limit it to specific proxies whose
XFF they trust--many of which require logins. That shifts the information
about who is editing Wikipedia out of their hands, but leaves it in the
network and thus not truly anonymous. I understand the engineering balance
they are trying to strike, but I'm not sure I can recommend their solution.
I’m reiterating that most of my comments are still unaddressed in -06.
I realize that the document did not change to address the audience or
document integration you preferred; I think there we simply disagree on how
to make this advice effective. I'm sorry that first message apparently did
not describe the disagreement effectively.
If I have misunderstood your comments, please accept my apologies. I would
be happy of further clarification and suggested text to illustrate your
preferences would be especially welcome.
[Med] Sure. Before that, can you please consider rechecking the detailed
list of comments available at: https://www.ietf.org/mail-
archive/web/ietf/current/msg101629.html. Thank you.
Thanks again for your engagement on this,
regards,
Ted
thanks,
Ted Hardie
Cheers,
Med
*De :* Ted Hardie [mailto:ted(_dot_)ietf(_at_)gmail(_dot_)com]
*Envoyé :* mercredi 22 février 2017 23:09
*À :* BOUCADAIR Mohamed IMT/OLN
*Cc :* ietf(_at_)ietf(_dot_)org;
draft-hardie-privsec-metadata-insertion(_at_)ietf(_dot_)org
*Objet :* Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt>
(Design considerations for Metadata Insertion) to Informational RFC
Hi Mohamed,
Thanks for your review. I've uploaded a draft -06 with updates from your
and other reviews. Some notes in-line.
On Tue, Jan 31, 2017 at 1:49 AM,
<mohamed(_dot_)boucadair(_at_)orange(_dot_)com> wrote:
Dear Ted,
Please find below my general review of the document and also my detailed
comments.
* Overall:
- I don't think the document is ready to be published as it is. It does
not discuss the usability and implications of the advice. Further, it may
be interpreted that a client/end system/user can always by itself populate
data that is supplied by on-path nodes (in current deployments). That's
assumption is not true for some protocols.
- The purpose of publishing this advice is not clear. For example, how
this advice will be implemented in practice? What is its scope?
- I would personally prefer an updated version of RFC7258 with more strict
language on the privacy-related considerations. This is more actionable
with concrete effects in documents that will required to include a
discussion on privacy related matters.
Detailed comments are provided below:
* The abstract says the following:
The IAB has published [RFC7624] in response to several revelations of
pervasive attack on Internet communications. This document considers
the implications of protocol designs which associate metadata with
encrypted flows. In particular, it asserts that designs which do so
by explicit actions of the end system are preferable to designs in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
which middleboxes insert them.
I suggest you explicit what is meant by "the end system".
I have updated this to clarify that this is the host/end system not the
user.
If you mean the owner/user, then the text should say so. If you mean a
client software instance, then bugs/inappropriate default values may lead
to (privacy leak) surprises too. It was reported in the past that some
browsers inject the MSISDN too.
* Introduction: "To ensure that the Internet can be trusted by users"
Rather « To minimize the risk of Internet-originated attacks targeted at
users ».
I've adopted this language.
It's reasonable to claim the Internet can be trusted by users; see how the
usage of social networks has become severely twisted for example
I've also considered your point that an updated version of RFC7258 might
be a better outlet for advice like this. We did consider several
approaches, including incorporating the text in an update to RFC 3552 or
as part of a document describing the full set of companion mitigations to
the threats in RFC 7624 (draft-iab-privsec-confidentiality-mitigations
would be one approach). Those are all valid approaches, but it seemed that
short, easily read documents tackling a single point might be easier to
produce and consume.
Thanks again for your review,
Ted Hardie