Subject: [Last-Call] Tsvart last call review of draft-gont-numeric-ids-sec-considerations-06

From: Bernard Aboba via Datatracker <[email-masked]>
Date: Fri, 25 Dec 2020 02:26:23 -0800

Reviewer: Bernard Aboba
Review result: Not Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

 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 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.

An alternative to a BCP might be to attempt to achieve the goals in
some other way, such as adding the issues raised in the
predecessor documents to those considered in Directorate reviews.

Overall, if the intent is to move the IETF toward requiring privacy
considerations in documents, more extensive guidance is required than is
provided here. For example, SDOs such as the W3C now expend considerable effort
on identifying issues relating to fingerprinting, a topic which is only touched
on in this document.

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. 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).

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?

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?

  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?  Is the intent to restrict the examples only to unsecured
protocols and fields sent in cleartext?

As  a  result, advice in this area is warranted.

[BA] A BCP needs to go beyond "advice", to providing actionable (and normative)
guidance.

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?

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

   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).

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.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Dec 2020 20:31:21 -0300

Hello, Bernard,

Thanks for your feedback! In-line....

On 25/12/20 07:26, Bernard Aboba via Datatracker wrote:
[....]
> 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

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 ----

        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.

> 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.

> 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

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?

> [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

> broadening the scope of concern to issues such as fingerprinting. Was this

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.

> [BA] References? 

Will add them. Thanks!

> Is the intent to restrict the examples only to unsecured

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.

> [BA] A BCP needs to go beyond "advice", to providing actionable (and normative)

Fair enough. Please see above.

> [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.

> draft-irtf-pearg-numeric-ids-history

FWIW, the goal of having it here is as a brief summary and motivation 
for the recommendations.

> 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).

> vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8.

Fair enough. My suggestion above was to tweak Req #2 as:
---- cut here ----

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Dec 2020 20:33:51 -0800

Fernando said:

That's correct.

[BA] Under what circumstances is it not necessary?

---- cut here ----

...do?

[BA] "vulnerability" seems better. Adding a reference to examples is
helpful,
whether contained in the document or elsewhere.

"Use of cryptographic techniques for confidentiality and authentication

[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).

to

      contain a vulnerability analysis of any transient numeric
      identifiers specified by the protocol

[BA] That is better.

[BA] Yes.

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] OK.

[BA] It seemed odd that draft-irtf-pearg-numeric-ids-history did not have
its own summary.

Indeed!  Section 3 of

[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.

---- 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.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Dec 2020 02:17:50 -0300

> [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"?)

> whether contained in the document or elsewhere.

OK. Just double-checking.  would the note and the change to 
"vulnerability analysis" work for you?

> here. If so, I think you need to be more specific (e.g. cite a specific 

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.

>        identifiers specified by the protocol

Will do.

> I will s/numeric identifiers/transient numeric identifiers/g  for the

Will apply these changes, too. Thanks!

[...]
> [BA] It seemed odd that draft-irtf-pearg-numeric-ids-history did not 
> have its own summary.

Fair enough. We will add it.

> 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] 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 
> 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,