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’m reiterating that most of my comments are still unaddressed in -06.
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<mailto: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