ietf
[Top] [All Lists]

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

2017-02-24 02:56:16
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<mailto: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:
* that data may not be always available to the endhost
* 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.
* it was reported in the past that some browsers leak the MSISDN and other 
sensitive data.
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. 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.

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,
Ted Hardie


Cheers,
Med

De : Ted Hardie 
[mailto:ted(_dot_)ietf(_at_)gmail(_dot_)co<mailto:ted(_dot_)ietf(_at_)gmail(_dot_)co>m]
Envoyé : mercredi 22 février 2017 23:09
À : BOUCADAIR Mohamed IMT/OLN
Cc : ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>; 
draft-hardie-privsec-metadata-insertion(_at_)ietf(_dot_)org<mailto: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