Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus <achimkraus@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
> https://www.ietf.org/mailman/listinfo/tls
>