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
