Subject: [alto] Roman Danyliw's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 09 Mar 2020 14:17:53 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-alto-incr-update-sse-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 7.1.  “To prevent an attacker from forging a stream control URI and
sending bogus requests to disrupt other update streams, stream control URIs
SHOULD contain sufficient random redundancy to make it difficult to guess valid
URIs.”

-- This approach provides no protection against an on-path attacker if https
isn’t used (Section 8.3.5 of RFC7285 only says that “ALTO server
implementations … MUST support the ‘https’ URI scheme”, not MUST use).

-- The words “random redundancy” wasn’t clear to me, but contextually, I
understood the intent.

** Section 9.1. Per “For stable resources with minor changes, the update stream
server may choose to send incremental changes; for resources that frequently
change, the update stream server may choose to send a full replacement after a
while.”, it isn’t clear what guidance this is providing as both statements are
“mays”.  The server always has the ability to choose the approach of returning
the updates.

** Section 9.1.  Per “Other JSON-based incremental change format may be
introduced in the future”, this statement doesn’t seem to have value in an
archival format without citation. Section 10.  With the addition of the URI
parameter for the stream control service, the attack surface described in
Section 15.1.1 of RFC7285 gets larger (as this could cause redirection to a
host of choice) – same mitigation though (use TLS).

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 9 Mar 2020 20:35:53 -0400

Dear Roman,

Thanks a lot for the review. Please see inline below.

> understood the intent.

Good points.  To address these two points, how about the following revision:

"To prevent an attacker from forging a stream control URI and sending bogus
requests to disrupt other update streams, the service should consider two
security issues. First, if http, not https, is used, the stream control URI
can be exposed to an on-path attacker. To address this issue, in a setting
where the path from the server to the client can traverse such an attacker,
the server SHOULD use https. Second, even without direct exposure, an
off-path attacker may guess valid stream control URIs. To address this
issue, the server SHOULD choose stream control URIs with enough randomness,
to make guessing difficult; the server SHOULD introduce mechanisms that
detect repeated guesses indicating an attack (e.g., keeping track of the
number of failed stream control attempts).

> “mays”.  The server always has the ability to choose the approach of
It is a good point to clarify as clearly as possible. How about the
following revision to clarify the
guidance (the whole paragraph):

"  The choice on data update messages depends on both how frequently the
   resources will change, and how extensive those changes will be.  For
   stable resources with minor changes, the update stream server may
   choose to send incremental changes; for resources that frequently
   change, the update stream server may choose to send a full
   replacement after a while.  Whether to send full replacement or
   incremental change depends on the update stream server."

->

"  The update stream server should be cognizant of the effects of its
update schedule,
    which includes both the choice of timing (i.e., when/what
   to trigger an update) and the choice of message format (i.e., given an
update, send
   a full replacement or an incremental change). In particular, the update
schedule can have
   effects on both the overhead and the freshness of information. To
minimize overhead,
   the server may choose to batch a sequence of updates for resources that
frequently
   change, by sending cumulative updates or a full replacement after a
while. The update stream
   server should be cognizant that batching reduces the freshness of
information. The server
   should also consider the effect of such delays on client behaviors (see
below on client timeout
   on waiting for updates of dependent resources).

> archival format without citation.

Agree. How about we just delete this sentence?

> Section 10.  With the addition of the URI

Good to clarify. How about a slight revision of the first and second
paragraphs of Section 10:

"  The Security Considerations (Section 15) of the base protocol fully apply
   to this extension.  For example, the same authenticity and integrity
considerations
   (Section 15.1 of [RFC7285]) still fully apply; the same considerations
for the privacy
   of ALTO users (Section 15.4 of [RFC7285]) also still fully apply.

   The additional services (addition of update streams and stream control
URIs)
   provided by this extension extend the attack surface described in
Section 15.1.1 of RFC7285.
   Below we discuss the additional risks and their remedies.

Thanks a lot,
Richard