Mike Bishop has entered the following ballot position for draft-ietf-tls-dtls-rrc-17: Discuss
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The RFC 9000 reference is currently informative, used to support the definition of the term "anti-amplification limit" in Section 2. However, conformance with this limit is normatively required in Section 6. Please rephrase Section 2 to include the full definition in this document that is required to understand the normative requirement; RFC 9000 can optionally be retained as an informative reference to a parallel usage, as done in Section 5. (Alternatively, you could make the RFC 9000 reference normative, but I don't think that's necessary.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.2.1 should describe in more detail that the case where "it is not possible to distinguish between an attack and an improvement in routing" will look different from the viewpoint of Sender and Receiver. Because the attacker is duplicating the Sender's packets from the old address to the new address, the Sender would see the RRC message as a re-validation for the current path and would generate a path-response, believing it is doing what Figure 6 illustrates. However, the attacker will forward this path-response to the Receiver; if it wins the race (or can cause packet loss on the old path), the Receiver will see the path-response message arrive from the new address, not the old. The behavior as defined in Section 6.2 addresses this by preventing a switch on receipt of a path_response without regard to the path on which it actually arrived. However, if the attacker is able to elicit a response of type path_drop to a given path_challenge, for example by injecting a modified copy of the path_challenge, that can be used to spoof dropping the challenged older path. This may need an additional branch in 6.2 step 3, prohibiting any response if the path where the message was received has never been a preferred path. In 10.1, consider advising that implementations log when responses to a single path_challenge are received, as this could also be suggestive of an attempt at the above attack. In 11.2, why is this extension not Recommended for implementations to support? That would seem to say that it either "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases." While the applicability is limited to DTLS, that is already communicated by the DTLS-Only column. In 11.3, please fully specify the name of the requested registry. Also, why is a DTLS-Only column needed in a registry which contains messages within a sub-protocol which only exists in DTLS? This restriction could be communicated with a note on the registry or in the title of the registry (e.g. "DTLS Return Routability Check Message Types"). (Obviously retain it if there is future work to support RRC outside of DTLS which will share this registry.) === NITS FOLLOW === - Section 3.1, "application layer specific" => "application-specific" or "application-layer" should be sufficient - Figure 7, '*' appears in the key but nowhere in the figure. I assume this is copied from other similar figures which use it, but it can be omitted here. - Section 7, "our" => "this" - Section 11.1, "entry to" => "entry in"; remove comma after "registry" _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
