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

[Achim Kraus <[e-mail]>]

Hi Ben,

> The attack does not require that both are valid for the same peer at the
> same time -- the attack can still occur when the party producing the MAC is
> induced to use the "wrong" (invalid CID) interpretation of the byte stream
> but then the version with valid CID is presented to the party verifying the
> MAC.

Though I consider the CID mainly as lookup-key for the security context,
including the MAC_write_key for Block Ciphers or the write_key /
write_IV for AEAD Ciphers provides in almost all casses the protection,
not the cid in the MAC. The only exclusion would be, if two different
cids point to the same security context. With a injective cid encoding,
that is mitigated.

As far as I understand your description:

1. The (server) peer 1 used cid "abcd" for it's encryption context.

2. An attacker modifies that cid "abcd" into a different cid (any
assumptions about that? Should it be "abcd12"? Or "ef3456"? Or no
special consideration?)

3. Then the other peer 2 uses the modified cid to place it into the
FINISH record and to calculate the MAC for that. The used security
context on peer 2 is NOT defined by that modified CID, it's defined by
peer 1's 5-tupel (according draft-ietf-tls-dtls-connection-id-07).

4. Now peer 1 will use the modified cid to
4.a. lookup the security context. What is assumed as result here?
4.b. calculated the MAC using the security context and modified cid

In my opinion, the MAC verfication generally fails, if at least one
input is different. So either a different security context or a
different cid will fail the MAC verification.

Though you say, that not both cids need to be valid for peer 1, the
consequence for me is, that peer 1 knows only the unmodified cid, but
not the modified cid. With that, peer 1 doesn't even have a security
context to calculate the MAC with.

It's totally mystic to me, what you assume as attack.

I guess, you adapt now your example. If so, would it be possible, that
you try to follow the above steps and show, where you deviate?

> If the internal structure (including length encoding) of the CID is
> opaque to the party producing the MAC, that party cannot validate the data
> used as input to the MAC.
>
> (Sorry for duplicating this previous paragraph here and on the github
> issue.)
>

 From the github issue:

 > In short, you asked me to show how having a cid-length (in a different
 > position than currently) will prevent an attack: the attack in
 > question occurs when the client is generating a (its first) MAC, not
 > at the time when the MAC is validated.

I still fail to follow your description, even with that amend.
Would it be possible, to get more information about an attack applied on
the generation of a MAC (above in step 3)? Or does the effect occur in
an other step (maybe 4)? Which effect should be considered?

Maybe, someone else has also an opinion about that attack or the
description.

best regards
Achim Kraus