On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
