Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design considerations for Metadata Insertion) to Informational RFC

[Ted Hardie <[e-mail]>]

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, <[e-mail]> 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