Hi Hannes, there was already a short discussion about that topic, see https://github.com/tlswg/dtls-conn-id/issues/64.
I also created a new issue https://github.com/tlswg/dtls-conn-id/issues/69, because I got aware of a pitfall (record reordering with address changes) close to that original issue. --------------------------- https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00#section-1 "This attack is possible because the network and transport layer identifiers, such as source IP address and source port numbers, are not integrity protected and authenticated by the DTLS record layer." FMPOV "This attack is possible because the network and transport layer identifiers, such as source IP address and source port numbers, could not be integrity protected and authenticated by the DTLS record layer." Doing so would break NATs, so I think it's better to express, that it is not possible to protect them. --------------------------- https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00#section-3 "Furthermore, when using CID, anti-replay protection MUST be enabled. This is to ensure that a man-on-the-middle attacker sending a previously captured record with a modified source IP address and port will not be able to successfully pass the above check (since the datagram is very likely discarded on receipt - if it falls outside the replay window)." With my new issue https://github.com/tlswg/dtls-conn-id/issues/69 above, I think this could be relaxed to keep the highest "epoch/sequence_number" and the address MUST only be updated, if the received record has a higher order according that "epoch/sequence_number". I'm not sure, maybe it's unusual, but I would mention https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-05 as example. --------------------------- https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00#section-4 "Return Routability Check --------> (cookie) Src-IP=B Dst-IP=Z" FMPOV, if a peer uses TLS12_CID records, all records should use that format and use the inner type to differentiate that type. https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#the-connection_id-extension "If DTLS peers have negotiated the use of a CIDs ... the new record layer format with the tls12_cid content type defined in {{dtls-ciphertext}} MUST be used." "Return Routability Check --------> <CID=100> (cookie) Src-IP=B Dst-IP=Z" Adding "<CID=100>" should point to that. As I wrote in https://github.com/tlswg/dtls-conn-id/issues/64, if the heartbeat is used as an inner type send in a TLS12_CID record, it may be also used for that check. Are there reasons not using the heartbeat? If not, I'm also not sure, if a new record_type pays off (Simon asked this also on his e-mail). Mit freundlichen Grüßen / Best regards Achim Kraus Engineering Cloud Services 4 Bosch IoT Hub (INST/ECS4) Von: TLS <tls-boun...@ietf.org> Im Auftrag von Hannes Tschofenig Gesendet: Dienstag, 9. Juli 2019 11:06 An: tls@ietf.org Betreff: [TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC) Hi all, working on the DTLS connection id drafts we noticed that there is one security aspect, which could benefit from an extra mitigation technique. The issue is that an on-path adversary could intercept and modify the source IP address (and the source port) of a DTLS datagram. Even if receiver checks the authenticity and freshness of the packet, the recipient is fooled into changing the CID-to-IP/port association. This can lead to black-holed or redirected traffic. Of course, an on-path adversary can do lots of things to traffic and the problem is self-fixing but it still lead us to work on a solution in form of a return-routability check. Here is the draft: https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00 Ciao Hannes 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
