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

Bernard Aboba <bernard.aboba@gmail.com> Tue, 29 December 2020 04:34 UTC

Return-Path: <bernard.aboba@gmail.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 A2EC33A1066; Mon, 28 Dec 2020 20:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 l_xw6J_HwjjX; Mon, 28 Dec 2020 20:34:05 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEBE3A1065; Mon, 28 Dec 2020 20:34:05 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id x20so28236559lfe.12; Mon, 28 Dec 2020 20:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+vLf54JsRk04NRfB2WVm/lSoOytAqWxZLabifqVcQps=; b=pBw1S29a5Q1aENIW+zgFPxgi8+li4+QckNM+BEyoGm5ZyYT7SwpQIr9ii6A9FeM//B psi6ZjB1LAWA8ZQVc/3Mg1bRq2KPBtUr1c3Ac7euWCzh+QMndMiqnBludDi2z3rU+rac 6+7S/tH3inVaJ19BKJBF+4kmicFi5mCFlZb320XPjm7f8F4r4pZ+KC4KuNQj/rM6f3rl /Nuav5MnYCgnp56cIoKGIKWJIxfn9Q8yJzs+qmYFRjEYteye+8QuHBSOzzJF8vY8IZh/ tDqQoqQX3vYKgMG9x1iVIKZDm9FLqezcXhTyGzL2+s62Ncsdxzpl2Ecvv/x8hcApoXP5 vIkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+vLf54JsRk04NRfB2WVm/lSoOytAqWxZLabifqVcQps=; b=tOsEvUiX6iWX6+6/9DLAgMPiyZbD8h9M4KPOmwGDudCOsJue9WKbCxqKoT0C+JrLj/ srd0pGAIg+vfKbYEhCCBWOVEqZLA3UtOpoaJRHcj/587pQ7pjmBJVSLWzNmS06zZfzQt AMIjCGRm/TiecmMbl+jV2trLET5HAFdICOLY6nHJ1PkNZUtMHvHpfAhQPATRWnz+OrVD YhdSy5UDpYnrzcbIvqGjHqzk3aJvj9mw/j71sxOkQO5S7rcxydH6L/TNZ2DY9sX5UrsU DDyebi1WN0gIIRnYxgkPbycizTdNNJhcmyS/FUCAyyktjX6v9MZwiVvGbgILUtWEiQF2 fFDQ==
X-Gm-Message-State: AOAM530CFSgsMSbmZNZfr+CVGRbXDFug/5QDkl5i72P1BXkzYRlMzwwB yXvh4JJZbo59aEbkesriIzgYKDzhAtgZJwo7AlscJeMoYe2Rew==
X-Google-Smtp-Source: ABdhPJyNT6XzZGDXmKPIMsTZ/yx/zif98xRAONF9MATo7RWUi9YpSJy10j41V76PCv/PE1LfaCZUnJKs1pqjNPF5nBo=
X-Received: by 2002:ac2:51ab:: with SMTP id f11mr22029399lfk.510.1609216442769; Mon, 28 Dec 2020 20:34:02 -0800 (PST)
MIME-Version: 1.0
References: <160889198345.3885.12485634387688330689@ietfa.amsl.com> <fe40555d-7c83-0165-b0a7-c43714f3bbeb@si6networks.com>
In-Reply-To: <fe40555d-7c83-0165-b0a7-c43714f3bbeb@si6networks.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 28 Dec 2020 20:33:51 -0800
Message-ID: <CAOW+2duu+XioZa1CObDxhuLWN1zmBmT8uAV6Gdgw22BQ3yTwLg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: tsv-art@ietf.org, draft-gont-numeric-ids-sec-considerations.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="00000000000070240b05b792e6fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/S5RWP9aVpn8t3t7YBSyP0E5aDMo>
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: Tue, 29 Dec 2020 04:34:09 -0000

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?

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.

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


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.

I will s/numeric identifiers/transient numeric identifiers/g  for the
sake of clarity.

[BA] Yes.

> [BA] References?

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.

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

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

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.

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

On Mon, Dec 28, 2020 at 3:31 PM Fernando Gont <fgont@si6networks.com> wrote:

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