Hi Martin, The attack described in Section 9.3.3 of https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 makes a lot of assumptions about the attacker.
I am not opposed to adding the recommendation but I want to understand it first since there is also a price to pay for it (in terms of complexity and performance). Like elsewhere there is no free lunch. Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the attacker needs to be able to * observe the packets sent by DTLS endpoints in both directions, and * replay the packets in such a way that they arrive faster than the original packets send by the DTLS endpoints, and * re-write both source and destination IP address to appear like a NAT for both endpoints. The last point is needed to ensure that the packet re-routing persists. IMHO these assumptions hint to an on-path attacker. An on-path attacker (such as a router) can already today perform a denial of service attack on DTLS secured communication by dropping all packets. Ciao Hannes -----Original Message----- From: Martin Duke via Datatracker <nore...@ietf.org> Sent: Tuesday, April 20, 2021 9:47 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; tls@ietf.org; Joseph Salowey <j...@salowey.net>; j...@salowey.net Subject: Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT) Martin Duke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. Section 9.3.3 of quic-transport, which deals with basically the same security model, also requires the receiving endpoint to probe the original address, not just the new one, to address a somewhat more difficult attack. It would be good to at least RECOMMEND this behavior for DTLS applications, and/or (repeat/informatively reference) the logic there. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
