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

[Achim Kraus <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>