Hi Joe, > [Joe] It's unfortunate to find issues that require breaking change at > the end of the review cycle, especially for a draft that has taken a > long path to get here. If there is an issue that is exploitable, even > in a corner case, someone will develop an attack, clever name, logo and > website and we will all have to scramble to deploy a fix. It's better > to fix now rather than later.
Agreed, therefore I wrote at the begin of the discussion with Ben: >> I would prefer, if this is not changed again without strong >> arguments! > In this case, I don't have a way to > exploit this issue, but unless someone has a way to demonstrate that > this is not going to be an issue then I believe it is prudent to fix it > now. > In my opinion, ONE change may be possible. A server may be configured to use only the old, only the new, or both by "try on the client's finish". I'm not happy with such "dirty" work-around. I would prefer to do so for something more the "cryptographic hygiene". So, if the MAC is considered to be adpated again, should it not be discussed, why at all the cid-length should be put in? I asked this already in January 2019 https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915 The MAC contains already a overall length. Even in that discussion, no one mentioned the reason for adding it. So if there a doubts about injection, why not remove it at all? > Would this issue have been caught by formal verification? That may also be something to help, not to change still again and again. best regards Achim Kraus Am 11.10.20 um 00:26 schrieb Joseph Salowey:
On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus <achimkr...@gmx.net <mailto:achimkr...@gmx.net>> wrote: Hi Ben, > > To be frank, I'm actually surprised that this is even seen as a matter for > discussion. As developer, I'm surprised, that this discussion now spans a couple of years, starting on summer 2018 with: https://github.com/tlswg/dtls-conn-id/issues/8 There are many (proposed) changes since then. I already tried to point to that with my e-mail answer from 4. September >> That order was also discussed a lot. >> https://github.com/tlswg/dtls-conn-id/pull/29 >> I would prefer, if this is not changed again without strong arguments! For me, "cryptographic hygiene", which breaks the API, are not strong arguments. Sure, that's only my personal opinion. I'm not sure, if a new code-point helps, nor that a new one is emitted for changing a draft (I would not recommend to do so, draft is a draft). So let me try to find a end: As developer, I see it's very important to come to a stable definition of the MAC. If now the order of the cid/cid-length is changing the MAC (again), and in half a year the next "cryptographic hygiene" campaign removes the cid-length (because it's not on the header and some (including me) don't see the benefit), then FMPOV this "process" just demonstrates more weakness, than I appreciate. So: If there is a guideline for constructing MACs, is that guideline documented somewhere? If the guideline is changing over the time, are these changes documented? And I would really welcome, also based on the experience with the long history of this discussion, if more can give their feedback about changing the MAC again. Please, this year, not next :-). [Joe] It's unfortunate to find issues that require breaking change at the end of the review cycle, especially for a draft that has taken a long path to get here. If there is an issue that is exploitable, even in a corner case, someone will develop an attack, clever name, logo and website and we will all have to scramble to deploy a fix. It's better to fix now rather than later. In this case, I don't have a way to exploit this issue, but unless someone has a way to demonstrate that this is not going to be an issue then I believe it is prudent to fix it now. Would this issue have been caught by formal verification? best regards Achim Kraus _______________________________________________ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
