Hey Hannes, This definitely looks like it needs attention.
This looks fairly lightweight, which is a good goal, but we have lots of experience with this in QUIC now that suggests that there are trivial denial of service attacks that can be mounted on simple designs. Have you looked at the connection migration section in QUIC in any detail? There are a few cases described there that don't appear to be covered in your proposed design. It's possible that you have a different threat model in mind, so maybe this doesn't apply. We might be well served by having a discussion about that though. On Tue, Jul 9, 2019, at 19:05, Hannes Tschofenig wrote: > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
