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

[Achim Kraus <[e-mail]>]

Hi Ben,

at least at your point (from the e-mail before)

 > and not have to change it again.

I agree :-).

That will naturally become true, if the RFC gets released.

best regards
Achim



Am 26.10.20 um 17:56 schrieb Benjamin Kaduk:
> Hi Achim,
>
> On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:
>> Hi Ben,
>>
>>>>      Because each party sends the value in the "connection_id" extension
>>>>      it wants to receive as a CID in encrypted records, it is possible for
>>>>      an endpoint to use a globally constant length for such connection
>>>>      identifiers.  This can in turn ease parsing and connection lookup,
>>>>      for example by having the length in question be a compile-time
>>>>      constant.  Implementations, which want to use variable-length CIDs,
>>>>      are responsible for constructing the CID in such a way that its
>>>>      length can be determined on reception.  Such implementations must
>>>>      still be able to send CIDs of different length to other parties.
>>>>      Note that there is no CID length information included in the record
>>>>      itself.
>>>
>>> ...and thanks for the reminder about how we say so in the text already.
>>
>> (your example from a previous e-mail)
>>
>>   > Attempting to construct a trivial example on the fly, (hex)
>>
>>   > 01 01 02 02 01 <513 bytes of plaintext content>
>>
>>   > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
>>   > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
>>   > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
>>   > DTLSInnerPlaintext.content = <513 bytes>.
>>
>> I would feel much more comfortable, if you state,
>> that you consider now either
>>
>> 1. that example was not compliant to the draft,
>>
>> or
>>
>> 2. the draft is not clear enough about that.
>>
>> If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
>> closed.
>
> It is neither of those two.
>
> While the party that will be parsing packets that use a given CID value to
> identify the connection needs to be able to determine the length from the
> byte stream, the other party does not.  Accordingly, when computing the
> MAC, there is still malleability in terms of which "interpretation" of the
> byte stream was intended by the party computing the MAC.  The party
> receiving the packet (and MAC) will only use one interpretation, but the
> party generating the MAC could have been deceived into using the other
> interpretation.
>
> As I said previously, the CID values are not authenticated until the
> handshake completes, so there is a real window where this attack surface is
> exposed.  Note that I do not need to present a complete end-to-end attack
> that breaks the TLS guarantees in order for us to change the spec -- it is
> enough to have shown that the malleability of the cryptographic input
> stream is exposed to potential attack.  To leave such behavior in a
> published protocol spec would be irresponsible, in effect, publishing an
> algorithm with known weaknesses.
>
> Thanks,
>
> Ben
>