On 29/12/20 01:33, Bernard Aboba wrote:
Fernando said:
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.
[BA] Under what circumstances is it not necessary?
I cannot think of any. The only step which I think could be opted out
would be #3 (i.e., suggest an algorithm that does not mitigate the
identified issues, if a case could be made.)
(or...are your arguing for "MUST"?)
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.
OK. Just double-checking. would the note and the change to
"vulnerability analysis" work for you?
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).
No. What we try to say is this:
There many possible issues associated with flawed IDs. One of them, in
some protocols, is the ability to perform data-injection attacks (e.g.
think predictable TCP SEQs). This kind of vulnerability can certainly be
mitigated via cryptographic authentication.
On the other hand, there are other issues that are associated with
flawed IDs, such as information disclosures. If you use things such as
global counters, these IDs will leak information to the remote endpoint.
e.g., think about connection-IDs selected from a global counter.
Cryptographic authentication or confidentiality will not mitigate the
information leakage: your remote peer will legitimately receive these
identifiers, but they will be leaking information they shouldn't leak.
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.
Will do.
I will s/numeric identifiers/transient numeric identifiers/g for the
sake of clarity.
[BA] Yes.
[BA] References?
Will add them. Thanks!
[BA] OK
Will apply these changes, too. Thanks!
[...]
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.
Fair enough. We will add it.
[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.
That is indeed what we mean. In other words, what we mean is:
Given a protocol that has two communicating parties (say "A" and "B"),
our threat model is that:
* the attacker can send packets to A
* the attacker can send packets to B
* the attacker could become "C", such that it legitimately communicates
with "A" or "B". (e.g. to "sample" IDs)
So, we do consider the case where e.g., a server is rogue and collects
transient numeric IDs.
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.
This is indeed a sensible threat model, and we do mean to consider these
cases. I will re-read the other two companion documents and check if we
have missed anything in this respect.
[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".
Fair enough. We can address this one by replacing "security and privacy
analysis" with "vulnerability 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.
This is indeed a fair concern. Besides the above change (s/security and
privacy analysis/vulnerability analysis/), we'll also add some text to
draft-irtf-pearg-numeric-ids-generation in this regard.
Question: do you think such text should/could be part of Section "8.2.
Information Leakage", or do you think it would be better to have a
standalone Section "8.X Fingerprinting" with some notes regarding
fingerprinting?
Thanks a lot for your feedback!
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
