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

[Achim Kraus <[e-mail]>]

Hi Wadson,

my bad, I mislead in understanding "injective".
It's not related to "injection".

best regards
Achim Kraus


> Hi Wadson,
>
>> The doubt is because of where it appears not that it appears. If every
>> value was preceded by its length the encoding would obviously be
>> injective.
>
> I hope, this is just a "typo" or "mistake".
>
> Prepending the length is the change, Ben want to use to protect against
> injection. You now say, this will be "obviously injective".
>
>> Here though it isn't clear if two different inputs to the
>> encoding could end up the same.
>
> Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
> all examples so far are just incomplete. They must declare, if the
> "different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.
>
> "different MAC_write_key" => obviously "end up" different.
> "same MAC_write_key" => the decoding of the records gets ambiguous
>
>> In fact I think in the MAC setting
>> there almost certainly is a problem as the length of the ciphertext is
>> right after the cid length, and with some cleverness you can come up
>> with a cid and ciphertext that could be interpreted multiple ways.
>> Unfortunately I haven't followed the draft's discussions that closely.
>>
>> I do not understand how a CID is supposed to be parsed by a recipient
>> when the length can change and the length field is not encoded, but
>> perhaps I'm misreading the intent of the [] notation in the record
>> layer of the draft.
>
> That's just a theroretical numbers game. No one os far made any really
> useful example from start to end. FMPOV, "CID with dynamic length" MUST
> use a unique/deterministic encoding. If that encoding ambiguous, as
> others imply/assume in their "numbers game", the whole record gets
> ambiguous.
>
> Just as forecast:
> Without agreement, that the CIDs must be encoded using deterministic
> interpretation, which in my opinion obsoletes these "number games",
> next Summer either Raccoon or Kenny will write up their next
> "time side channel attack" on this.
> (The ambiguity will end up in try out the MAC for both "different
> MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
> the receiver will not know by the failing MAC, which interpretation is
> the right. I guess, this will end up in decrypt twice, also obvious time
> signal.)
>
> best regards
> Achim Kraus
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls