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". 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 ». 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.
* Introduction:
s/it is necessary for the Internet technical community to address the vulnerabilities/the Internet technical community needs to address the vulnerabilities
* In the Introduction:
for the Internet technical community to address the vulnerabilities
exploited in the attacks document in [RFC7258] and the threats
^^^^^^^^
described in [RFC7624].
s/document/documented
* Section 2: Please double check this text
Terms introduced terms from there include: Pervasive Attack, Passive
^^^^^^^^^^^^^^^^^^^^^^
Pervasive Attack, Active Pervasive Attack, Observation, Inference,
and Collaborator.^
* Section 3 says the following:
"In some cases, other actors within a protocol context will continue.."
Not sure to understand what "actors within a protocol" means. Do you mean middleboxes? Probes? Proxies? Else? Please explicit it out.
* Section 3 includes the following
The restoration of information is particularly tempting for systems
whose primary function is not to provide confidentiality. A proxy
providing compression, for example, may wish to restore the identity
of the requesting party; similarly a VPN system used to provide
channel security may believe that origin IP should be restored .
- What is meant by "VPN system" here?
- The use of "believe" may not be technically sound here. Do you mean "be instructed to"?
* Section 3,
Actors considering restoring metadata may believe that they
understand the relevant privacy considerations or believe that,
because the primary purpose of the service was not privacy-related,
none exist. Examples of this design pattern include [RFC7239] and
[RFC7871].
- This text is a bit fuzzy: "considering", "may believe", "because the primary purpose". I'm afraid it is speculative and not elaborated. I would define (or exemplify) what an actor is, elaborate on what understanding "relevant privacy considerations" actually means (and maybe understanding is not enough), how actors acquire knowledge about the "primary purpose of the service". I think this text is not useful unless more elaboration is provided.
- BTW, both RFCs listed right after include a privacy considerations section!
* Section 4: "Avoid this design pattern": Which one?
* Section 4:
"It contributes to the overall loss of
confidentiality for the Internet and trust in the Internet as a..."
- What is meant by "confidentiality for the Internet"?
- Even if the data is fully encrypted, privacy-related data are/can still stored/manipulated by the end servers.
* Section 4:
Do not add metadata to flows at intermediary devices unless
a positive affirmation of approval for restoration has been received
from the actor whose data will be added.
- How an actor is defined?
- What about the usability considerations of such approach?
- How a positive affirmation will be captured if inserted metadata is for service delivery purposes?
* Section 4:
"Instead, design the protocol so that the actor can add such metadata
themselves so that it flows end-to-end,..."
- consider making this change:
OLD:
themselves so that it flows end-to-end,
NEW:
itself so that it flows end-to-end,
- Some metadata is added for network-assistance and service delivery purposes (e.g., service function chaining). The end user is not aware of such needs, so how a network provider can interact with that actor?
- Further, some information is not available to the client. For example, DHCP relays supply data that is required for proper operations. Do you exclude DHCP and the like from this advice?
* Section 4:
"In addition to improving privacy, this
approach ensures consistent availability between the communicating
parties, no matter what path is taken."
- What is meant by "consistent availability"?
- How the proposed approach ensures "consistent availability"?
* Section 4:
"...follow the advice in this document, that design would likely reverse
a core element of RFC 7871: rather than adding metadata at a proxy,
it would provide facilities for end systems to add it to their
initial queries."
I'm afraid this text should be double checked. A misbehaving node may add a fake/spoofed information to be influenced policy enforcement at the server side. While if the data is inserted by a trusted entity, the supplied data can be trusted by a remote server.
* Section 4:
By negotiating an EDNS0
option which allowed them to self-populate this data , clients would
be affirming their consent for its use and providing data at a
granularity with which they were comfortable. This variability would
change the caching behavior for responses from participating servers,
but the same considerations set out in section 7.3.2 and 7.5 apply to
client-supplied subnets as well as they do for proxy supplied
subnets.
- What about the implications of such design on multi-homed hosts?
- What does "granularity with which they were comfortable" mean here? That the injected metadata has the level of granularity that is selected by the end-host?
- Section 7.3.2 and 7.5 of which document? Please clarify in the text.
* Section 5:
- This section does not discuss the implications of instructing an endpoint that a given metadata is needed to be conveyed in data packets.
- Also, this section does not include any discussion related to the integrity of the metadata supplied by an endpoint.
- What is meant "more active management". Can you precise more in the text?
- You mentioned "is commonly under more active management and represents a much smaller number of elements", but this is compared to what?
- You say "this impacts both the general deployment difficulty and the number of systems which the origin server must trust."...but what is "the general deployment difficulty"?
- The text says
" work also implies introducing mechanisms for the end-to-end
provisioning of metadata when a user has actively consented to
provide it"
but how to assess that? How to determine which element will consume the supplied data?
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : IETF-Announce [mailto:ietf-announce-bounces@xxxxxxxx] De la part de
> The IESG
> Envoyé : mardi 24 janvier 2017 18:46
> À : IETF-Announce
> Cc : draft-hardie-privsec-metadata-insertion@xxxxxxxx
> Objet : Last Call: <draft-hardie-privsec-metadata-insertion-05.txt>
> (Design considerations for Metadata Insertion) to Informational RFC
>
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Design considerations for Metadata Insertion'
> <draft-hardie-privsec-metadata-insertion-05.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2017-02-21. Exceptionally, comments may be
> sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> 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.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-hardie-privsec-metadata-insertion/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-hardie-privsec-metadata-
> insertion/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
> There are some minor nits noted by I-D nits that we'll fix as we go.
>
>