On 17/07/2019, 16:33, "TLS on behalf of Martin Thomson" <tls-boun...@ietf.org on behalf of m...@lowentropy.net> wrote: > I'm really concerned about shipping a protocol that enables the sorts > of attacks that connection IDs enable. I think that we should discuss > that issue when we meet. I know that Hannes' new draft is an attempt > to tackle this issue, but that's a long way from being done. If we > ship a spec with this hole, it will only be usable in certain narrow > contexts, like with ICE, where this really isn't a concern anyway.
I share the same worry that the document as it is at the moment creates a dangerous situation if implemented in isolation, i.e. without RRC. Originally I had proposed the text in [1]. The two MUSTs in that PR should counter the man-on-the-side attacks described in [2]. They are self-contained, cheap and effective countermeasures that an endpoint can implement unilaterally. This was before RRC was drafted. Those paragraphs have now been moved there; however, I think they really belong to conn-id. My suggestion is we move that section back and point to RRC for the "final" solution. This doesn't give complete internal coherency to conn-id -- which is indeed suboptimal -- but the recommendation to provide peer address update call-backs provides at least a way out and looks to me like the least worse solution given where we are. Cheers, t [1] https://github.com/tlswg/dtls-conn-id/pull/65/files [2] https://github.com/tlswg/dtls-conn-id/issues/64#issue-448307810 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
