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). _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
