Re: [Tsv-art] Tsvart last call review of draft-gont-numeric-ids-sec-considerations-06

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492