Fernando said:
I personally also wouldn't mind s/security and privacy/vulnerability/ if
necessary.
> [BA] Recommendations 1 and 3 seem reasonable, but probably should be couched in
> normative language. Recommendation 2 would appear to require reworking; the
> document is not specific enough to serve as a guideline for a privacy
> considerations section. Perhaps a reference should be provided to the security
> vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8.
Fair enough. My suggestion above was to tweak Req #2 as:
---- cut here ----
2. Provide a security and privacy analysis of the aforementioned
identifiers.
Note: Section 8 and Section 9 provides a general security and
privacy analysis of transient numeric identifiers, along with an
analysis of common algorithms for generating transient numeric
identifiers.
---- cut here ----
[BA] My concern relates to the term "privacy analysis". While Sections 8 and 9 do provide good examples, they do not provide complete enough guidance for considering privacy issues such as fingerprinting. As an example, the manner in which identifiers are chosen may lead to leaking information relating to hardware, operating system or application software or connected devices on the user's machine. Encrypting those identifiers is insufficient for mitigating the privacy risks if the identifiers can be collected by a server whose privacy interests may not coincide with those of the user.
That's correct.
How about introducing the numbered-list in Section 5 as:
" When a protocol specifies transient numerical identifiers, it SHOULD:"
And then continue with the numbered list.
How about introducing the numbered-list in Section 5 as:
" When a protocol specifies transient numerical identifiers, it SHOULD:"
And then continue with the numbered list.
[BA] Under what circumstances is it not necessary?
How tweaking recommendation#2 as:
---- cut here ----
2. Provide a security and privacy analysis of the aforementioned
identifiers.
Note: Section 8 and Section 9 provides a general security and
privacy analysis of transient numeric identifiers, along with an
analysis of common algorithms for generating transient numeric
identifiers.
---- cut here ----
...do?
How tweaking recommendation#2 as:
---- cut here ----
2. Provide a security and privacy analysis of the aforementioned
identifiers.
Note: Section 8 and Section 9 provides a general security and
privacy analysis of transient numeric identifiers, along with an
analysis of common algorithms for generating transient numeric
identifiers.
---- cut here ----
...do?
I personally also wouldn't mind s/security and privacy/vulnerability/ if
necessary.
[BA] "vulnerability" seems better. Adding a reference to examples is helpful,
whether contained in the document or elsewhere.
That's probably varies from one case to another. If one were to make a
general assertion, one might say something along the lines of:
"Use of cryptographic techniques for confidentiality and authentication
may readily mitigate some of the issues arising from predictable
transient numeric identifiers. For example, cryptographic authentication
could readily mitigate data injection attacks even in the presence of
some predictable transient numeric identifiers (such as "sequence
numbers"). However, use of flawed algorithms (such as global counters)
for generating transient numeric identifiers could result in information
leakages even when cryptographic techniques are employed."
Would this be a sensible addition?
That's probably varies from one case to another. If one were to make a
general assertion, one might say something along the lines of:
"Use of cryptographic techniques for confidentiality and authentication
may readily mitigate some of the issues arising from predictable
transient numeric identifiers. For example, cryptographic authentication
could readily mitigate data injection attacks even in the presence of
some predictable transient numeric identifiers (such as "sequence
numbers"). However, use of flawed algorithms (such as global counters)
for generating transient numeric identifiers could result in information
leakages even when cryptographic techniques are employed."
Would this be a sensible addition?
[BA] It sounds like you are referring to a cryptographic vulnerability here. If so, I think you need to be more specific (e.g. cite a specific example or paper).
That's the focus of this document. -- i.e., issues arising from flawed
transient numeric identifiers.
FWIW, as noted above, I wouldn't mind e.g. changing:
contain analysis of the security and privacy properties of
any transient numeric identifiers specified by the protocol.
to
contain a vulnerability analysis of any transient numeric
identifiers specified by the protocol
That's the focus of this document. -- i.e., issues arising from flawed
transient numeric identifiers.
FWIW, as noted above, I wouldn't mind e.g. changing:
contain analysis of the security and privacy properties of
any transient numeric identifiers specified by the protocol.
to
contain a vulnerability analysis of any transient numeric
identifiers specified by the protocol
[BA] That is better.
I will s/numeric identifiers/transient numeric identifiers/g for the
sake of clarity.
I will s/numeric identifiers/transient numeric identifiers/g for the
sake of clarity.
[BA] Yes.
> [BA] References?
Will add them. Thanks!
> [BA] References?
Will add them. Thanks!
[BA] OK
> [BA] Is the audience implementers or document authors?
Document authors. The above paragraph essentially notes that there are
cases where the spec does the right thing, and it's the implementers
that screw up. -- it's not for us to solve *that* particular case.
> [BA] Is the audience implementers or document authors?
Document authors. The above paragraph essentially notes that there are
cases where the spec does the right thing, and it's the implementers
that screw up. -- it's not for us to solve *that* particular case.
[BA] OK.
> 4. Common Flaws in the Generation of Transient Identifiers
>
> This Section would seem to fit well as a summary within
> draft-irtf-pearg-numeric-ids-history
FWIW, the goal of having it here is as a brief summary and motivation
for the recommendations.
> 4. Common Flaws in the Generation of Transient Identifiers
>
> This Section would seem to fit well as a summary within
> draft-irtf-pearg-numeric-ids-history
FWIW, the goal of having it here is as a brief summary and motivation
for the recommendations.
[BA] It seemed odd that draft-irtf-pearg-numeric-ids-history did not have its own summary.
> [BA] This can be relevant even if the identifier is encrypted (e.g. if the
> attacker is a website utilizing the identifier for fingerprinting).
Indeed! Section 3 of
https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-04.txt
says:
Throughout this document, we assume an attacker does not have
physical or logical access to the device(s) being attacked, and does
not have access to the packets being transferred between the sender
and the receiver(s) of the target protocol (if any). However, we
assume the attacker can send any traffic to the target device(s), to
e.g. sample identifiers employed by such device(s).
[BA] While this threat model is still commonly used within IETF security considerations documents, I would argue that it is not adequate for analyzing privacy issues, since in some scenarios the endpoint (e.g. a server) can be considered an attacker.
> [BA] This can be relevant even if the identifier is encrypted (e.g. if the
> attacker is a website utilizing the identifier for fingerprinting).
Indeed! Section 3 of
https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-04.txt
says:
Throughout this document, we assume an attacker does not have
physical or logical access to the device(s) being attacked, and does
not have access to the packets being transferred between the sender
and the receiver(s) of the target protocol (if any). However, we
assume the attacker can send any traffic to the target device(s), to
e.g. sample identifiers employed by such device(s).
[BA] While this threat model is still commonly used within IETF security considerations documents, I would argue that it is not adequate for analyzing privacy issues, since in some scenarios the endpoint (e.g. a server) can be considered an attacker.
As example, within the W3C, privacy concerns center on information that may be collected by malicious websites providing _javascript_ running within the user's browser. These websites may also collect information from packets sent from the browser, such as identifiers sent in either encrypted or in cleartext.
> [BA] Recommendations 1 and 3 seem reasonable, but probably should be couched in
> normative language. Recommendation 2 would appear to require reworking; the
> document is not specific enough to serve as a guideline for a privacy
> considerations section. Perhaps a reference should be provided to the security
> vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8.
Fair enough. My suggestion above was to tweak Req #2 as:
---- cut here ----
2. Provide a security and privacy analysis of the aforementioned
identifiers.
Note: Section 8 and Section 9 provides a general security and
privacy analysis of transient numeric identifiers, along with an
analysis of common algorithms for generating transient numeric
identifiers.
---- cut here ----
[BA] My concern relates to the term "privacy analysis". While Sections 8 and 9 do provide good examples, they do not provide complete enough guidance for considering privacy issues such as fingerprinting. As an example, the manner in which identifiers are chosen may lead to leaking information relating to hardware, operating system or application software or connected devices on the user's machine. Encrypting those identifiers is insufficient for mitigating the privacy risks if the identifiers can be collected by a server whose privacy interests may not coincide with those of the user.
On Mon, Dec 28, 2020 at 3:31 PM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
Hello, Bernard,
Thanks for your feedback! In-line....
On 25/12/20 07:26, Bernard Aboba via Datatracker wrote:
[....]
>
> The purpose of this document appears to be to distill lessons from
> draft-irtf-pearg-numeric-ids-history and draft-irtf-pearg-numeric-ids-generation
> (both of which I found informative) into actionable advice for draft authors.
>
> However, the document's Section 5 contains no normative statements
That's correct.
How about introducing the numbered-list in Section 5 as:
" When a protocol specifies transient numerical identifiers, it SHOULD:"
And then continue with the numbered list.
> and
> recommendation 2 is seems somewhat too broad in introducing a privacy
> considerations requirement. It may be possible to fix this Section by
> couching recommendations 1 and 3 probably as mandatory and focusing
> recommendation 2 on security while citing the details of potential
> security vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation
> Section 8.
Note that Sections 8-9 of
https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation
provides both a security and privacy analysis of IDs, including an
analysis of commmon ID-generation algorithms.
How tweaking recommendation#2 as:
---- cut here ----
2. Provide a security and privacy analysis of the aforementioned
identifiers.
Note: Section 8 and Section 9 provides a general security and
privacy analysis of transient numeric identifiers, along with an
analysis of common algorithms for generating transient numeric
identifiers.
---- cut here ----
...do?
I personally also wouldn't mind s/security and privacy/vulnerability/ if
necessary.
> Overall, if the intent is to move the IETF toward requiring privacy
> considerations in documents,
This is certainly not the intent. The intent of this document is for
specifications to analyze (and proactively mitigate) issues arising from
flawed transient numeric identifiers.
> The emphasis appears to be not on privacy issues in general as on implementation
> lessons learned from the use of transient identifiers used in unsecured
> protocols.
Not necessarily. Protocols that e.g. employ cryptographic authentication
might still employ flawed IDs that may e.g. leak information (e.g., a
QUIC implementation could use a global counter for generating
connection-IDs, thus leaking the number of connections being established
to the remote peer).
> If so, a BCP may not be the best way to influence implementers. If
> the focus is to be on draft authors, then as the IETF addresses some of the
> security gaps (e.g. QUIC versus TCP, DNS privacy) it would be useful to
> clarify how much of the advice remains relevant (e.g. which advice applies to
> fields that lack confidentiality and/or integrity protection, what threats
> persist even with end-to-end security).
That's probably varies from one case to another. If one were to make a
general assertion, one might say something along the lines of:
"Use of cryptographic techniques for confidentiality an authentication
may readily mitigate some of the issues arising from predictable
transient numeric identifiers. For example, cryptographic authentication
could readily mitigate data injection attacks even in the presence of
some predictable transient numeric identifiers (such as "sequence
numbers"). However, use of flawed algorithms (such as global counters)
for generating transient numeric identifiers could result in information
leakages even when cryptographic techniques are employed."
Would this be a sensible addition?
> Specific comments:
>
> Abstract
>
> Poor selection of transient numerical identifiers in protocols such
> as the TCP/IP suite has historically led to a number of attacks...
> To prevent such flaws in future protocols and
> implementations, this document updates RFC 3552, requiring future
> RFCs to contain analysis of the security and privacy properties of
> any transient numeric identifiers specified by the protocol.
>
> [BA] For a privacy analysis, why focus only on "transient" numeric identifiers?
That's the focus of this document. -- i.e., issues arising from flawed
transient numeric identifiers.
FWIW, as noted above, I wouldn't mind e.g. changing:
contain analysis of the security and privacy properties of
any transient numeric identifiers specified by the protocol.
to
contain a vulnerability analisys of any transient numeric
identifiers specified by the protocol
> 1. Introduction
>
> Network protocols employ a variety of transient numeric identifiers...
>
> poor selection of numeric identifiers, usually as a result of...
>
> [BA] The first paragraph mentions "transient numeric identifiers" whereas
> the second paragraph just uses the term "numerical identifiers", potentially
> broadening the scope of concern to issues such as fingerprinting. Was this
> intentional?
I will s/numeric identifiers/transient numeric identifiers/g for the
sake of clarity.
That said, Section 2 says:
We use the term
"transient numeric identifier" (or simply "numeric identifier" or
"identifier" as short forms) as a generic term to refer to any
data object in a protocol specification that satisfies the
identification property stated above.
> o Predictable TCP sequence numbers
>
> o Predictable transport protocol numbers
>
> o Predictable IPv4 or IPv6 Fragment Identifiers
>
> o Predictable IPv6 IIDs
>
> o Predictable DNS TxIDs
>
> [BA] References?
Will add them. Thanks!
> Is the intent to restrict the examples only to unsecured
> protocols and fields sent in cleartext?
Not really. FWIW, for the most part the analysis assumes the attacker is
off-path or that the attacker cannot see the identifiers "on-path". So
the same analysis applies if the protocol provides for confidentiality.
> As a result, advice in this area is warranted.
>
> [BA] A BCP needs to go beyond "advice", to providing actionable (and normative)
> guidance.
Fair enough. Please see above.
> 3. Issues with the Specification of Transient Identifiers
>
> Finally, there are protocol implementations that simply fail to
> comply with existing protocol specifications. That is, appropriate
> guidance is provided by the protocol specification (whether the core
> specification or or an update to it), but an implementation simply
> fails to follow such guidance. For example, some popular operating
> systems (notably Microsoft Windows) still fail to implement
> transport-protocol port randomization, as specified in [RFC6056].
>
> [BA] Is the audience implementers or document authors?
Document authors. Tee above paragraph essentially notes that there are
cases where the spec does the right thing, and it's the implementers
that screw up. -- it's not for us to solve *that* particular case.
> 4. Common Flaws in the Generation of Transient Identifiers
>
> This Section would seem to fit well as a summary within
> draft-irtf-pearg-numeric-ids-history
FWIW, the goal of having it here is as a brief summary and motivation
for the recommendations.
> When one identifier is employed across contexts where such constancy
> is not needed, activity correlation is made made possible. For
> example, employing an identifier that is constant across networks
> allows for node tracking across networks.
>
> [BA] This can be relevant even if the identifier is encrypted (e.g. if the
> attacker is a website utilizing the identifier for fingerprinting).
Indeed! Section 3 of
https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-04.txt
says:
Throughout this document, we assume an attacker does not have
physical or logical access to the device(s) being attacked, and does
not have access to the packets being transferred between the sender
and the receiver(s) of the target protocol (if any). However, we
assume the attacker can send any traffic to the target device(s), to
e.g. sample identifiers employed by such device(s).
> 5. Security and Privacy Requirements for Identifiers
>
> When a protocol specifies transient numerical identifiers, it is
> critical for the protocol specification to:
>
> 1. Clearly specify the interoperability requirements for the
> aforementioned identifiers (e.g., required properties such as
> uniqueness, along with the failure severity if such properties
> are not met).
>
> 2. Provide a security and privacy analysis of the aforementioned
> identifiers.
>
> 3. Recommend an algorithm for generating the aforementioned
> identifiers that mitigates security and privacy issues, such as
> those discussed in [I-D.irtf-pearg-numeric-ids-generation].
>
> [BA] Recommendations 1 and 3 seem reasonable, but probably should be couched in
> normative language. Recommendation 2 would appear to require reworking; the
> document is not specific enough to serve as a guideline for a privacy
> considerations section. Perhaps a reference should be provided to the security
> vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8.
Fair enough. My suggestion above was to tweak Req #2 as:
---- cut here ----
2. Provide a security and privacy analysis of the aforementioned
identifiers.
Note: Section 8 and Section 9 provides a general security and
privacy analysis of transient numeric identifiers, along with an
analysis of common algorithms for generating transient numeric
identifiers.
---- cut here ----
Please do let us know if this would address your comment.
Thanks a lot!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
