Dear Roman, Thanks a lot for the review. Please see inline below.
On Mon, Mar 9, 2020 at 5:18 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > 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. > 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). > > ** 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. > > 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). > ** 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. Agree. How about we just delete this sentence? > 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). > 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
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
