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

Fernando Gont <fgont@si6networks.com> Mon, 28 December 2020 23:31 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2F3A0EC6; Mon, 28 Dec 2020 15:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYBUrdLuQT2O; Mon, 28 Dec 2020 15:31:47 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4A73A0EC4; Mon, 28 Dec 2020 15:31:40 -0800 (PST)
Received: from [192.168.1.13] (unknown [190.179.97.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 47F93283A33; Mon, 28 Dec 2020 23:31:36 +0000 (UTC)
To: Bernard Aboba <bernard.aboba@gmail.com>, tsv-art@ietf.org
Cc: draft-gont-numeric-ids-sec-considerations.all@ietf.org, last-call@ietf.org
References: <160889198345.3885.12485634387688330689@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <fe40555d-7c83-0165-b0a7-c43714f3bbeb@si6networks.com>
Date: Mon, 28 Dec 2020 20:31:21 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <160889198345.3885.12485634387688330689@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/oPTxUiS2SPD7N_Uc1BQlfd67rJM>
Subject: Re: [Tsv-art] Tsvart last call review of draft-gont-numeric-ids-sec-considerations-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2020 23:31:50 -0000

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@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492