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

[Ted Hardie <[e-mail]>]

HI Mohamad,

Thanks for rechecking; some further comments in-line.

On Wed, Feb 22, 2017 at 11:21 PM, <[e-mail]> 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:[e-mail]]
> *Envoyé :* mercredi 22 février 2017 23:09
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* [e-mail]; [e-mail]
> *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, <[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
>
>
>