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.
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.
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.
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