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(_at_)ietf(_dot_)org] De la
part de
The IESG
Envoyé : mardi 24 janvier 2017 18:46
À : IETF-Announce
Cc : draft-hardie-privsec-metadata-insertion(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org mailing lists by 2017-02-21. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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.