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

[Benjamin Kaduk <[e-mail]>]

Hi Achim,

On Sun, Oct 11, 2020 at 07:43:14PM +0200, Achim Kraus wrote:
> Hi Watson,
> 
> > 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".

Since apparently this was not fully clear, allow me to link the wikipedia
article corresponding to "injective map (in the mathematical sense)" in my
earlier description: https://en.wikipedia.org/wiki/Injective_function

> > 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

In my opinion a useful example from start to end is not a prerequisite for
making a change to the spec in the face of a demonstrated local weakness.
Attacks only ever get better, and we should not leave known building blocks
for them in place.

> use a unique/deterministic encoding. If that encoding ambiguous, as
> others imply/assume in their "numbers game", the whole record gets
> ambiguous.

Yes, an entity assigning its own CIDs has to be able to distinguish them on
receipt based on the record bitstream (which does not supply its own
framing for the CID length).  The current text may not be as explicit about
this requirement as it could be (it may only list a requirement that the
values given out have to be recognized, not that there has to be a unique
parsing of all potential CID bytestreams in a received record that rejects
invalid ones?  I didn't check).

> 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.)

Just to check my understanding: your forecast of an attack is predicated on
implementations that accept both potential MAC calculations proposed (CID
length before CID and CID length after CID)?  I do not think we should
allow things to progress to a state where accepting both forms is
encouraged, precisely because it leads to this sort of difficulty.   Hence,
my suggestion to assign a different extension codepoint, so an
implementation knows exactly which procedure to use.

-Ben