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

[Achim Kraus <[e-mail]>]

Hi Ben,

 >> If that is going to be changed, the early adopters run into trouble with
 >> their deployments!
 >
 > I'm not sure I follow.  Are you saying that if there is a theoretical
 > problem with the construction it would have been exposed by
implementation
 > testing?

No, I don't say that.
"Early adopters" means, there people using
draft-ietf-tls-dtls-connection-id-07 in real world systems with that
current definiton of the MAC. If that MAC calculation is changed, then
they need to adapt their deployments in the field, which is not too easy
(and potential dangerous). Sure, draft-ietf-tls-dtls-connection-id-07 is
still only a draft and could be changed. But not without trouble for
those "early adopters".

 > My primary concern is not actually about a specific situation where
 > injection occurs, but rather for cryptographic hygiene -- whenever we
 > assemble an input for a cryptographic operation (especially MAC or
signing)
 > it is important to ensure that the sequence of bits used as input to the
 > cryptographic operation can only be produced by a single combination of
 > logical inputs to the protocol-level operation or message that we are
 > applying cryptographic protection to.  This property is known as
 > "injectivity", because the map from protocol-level values to bitstrings
 > (themselves used as input for cryptographic operations) is an injective
 > mapping in the mathematical sense.  I believe that I have
demonstrated that
 > the current MAC construction does not use an injective mapping and is
thus
 > not consistent with best practices.

*** protocol-level operation or message ***

I understood your example in your previous mail.
I tried to explain, that the data of your example, especially the
cid-length, is not in the message. Please, find the time to check that
current record defintion! There the CID is encoded in the protocols
tls-cid-records without the explicit CID length.

With that, I can't see the posssiblity to inject the cid-length.
It's simply not "in" and so can't be "injected".

best regards
Achim Kraus

Am 09.10.20 um 01:34 schrieb Benjamin Kaduk:
> Hi Achim,
>
> Sorry for the long silence on this front; my attention had cycled elsewhere
> and I was just overall operating slowly for a couple weeks (sick, maybe,
> but no clear symptoms).
>
> My primary concern is not actually about a specific situation where
> injection occurs, but rather for cryptographic hygiene -- whenever we
> assemble an input for a cryptographic operation (especially MAC or signing)
> it is important to ensure that the sequence of bits used as input to the
> cryptographic operation can only be produced by a single combination of
> logical inputs to the protocol-level operation or message that we are
> applying cryptographic protection to.  This property is known as
> "injectivity", because the map from protocol-level values to bitstrings
> (themselves used as input for cryptographic operations) is an injective
> mapping in the mathematical sense.  I believe that I have demonstrated that
> the current MAC construction does not use an injective mapping and is thus
> not consistent with best practices.
>
> However, in particular...
>
> On Sun, Oct 04, 2020 at 04:35:49PM +0200, Achim Kraus wrote:
>> Hi Ben,
>>
>> any progress on the cid-length / calculate MAC topic?
>>
>> As I wrote, though the cid-length itself is not "on the wire" (it's only
>> the cid), I can't see, that the cid-length could be injected.
>> Do I oversee soemthing?
>>
>> best regrads
>> Achim Kraus
>>
>> -------- Weitergeleitete Nachricht --------
>> Betreff: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
>> Datum: Wed, 16 Sep 2020 08:31:19 +0200
>> Von: Achim Kraus <[e-mail]>
>> An: Benjamin Kaduk <[e-mail]>
>> Kopie (CC): [e-mail], [e-mail]
>>
>> Hi Ben,
>>
>> ...
>>
>>>>>
>>>>> The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
>>>>> DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
>>>>> and the DTLS (explicit) sequence number.  I do not see this
>>>>> concatenation given the name "seq_num" anywhere, so I think we need to
>>>>> reformulate this expression.
>>>>>
>>>>>               cid +
>>>>>               cid_length +
>>>>>
>>>>> Does this construction preserve injectivity?  It seems easier to reason
>>>>> about when the length of an element is always before or always after the
>>>>> element itself, but we put the length first for some of the other
>>>>> fields (that appear after these) so there seems to be some malleability.
>>>>
>>>> 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!
>>>
>>> Thanks for the pointer!
>>> I am not sure that the specific question about injectivity was raised
>>> there, though.  (The topic of whether "seq_num" includes epoch was raised
>>> but I did not see a clear resolution on my first reading, just
>>> https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)
>>>
>>> Specifically, the question of "injectivity" is referring to a scenario
>>> where I can use different actual values for (cid, cid_length,
>>> length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed
>>>
>>> cid + cid_length + length_of_DTLSInnerPlaintext + ...
>>>
>>> (Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte
>>> field...)
>>>
>>> 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>.  The possibility of such a
>>> collision weakens the cryptographic protection and should be avoided.
>>>
>>
>> If that is going to be changed, the early adopters run into trouble with
>> their deployments!
>
> I'm not sure I follow.  Are you saying that if there is a theoretical
> problem with the construction it would have been exposed by implementation
> testing?
>
>> The cid length is not on the wire, so on the wire is (cid 01 01)
>>
>>> 01 01 02 01 <513 bytes of plaintext content>
>>
>> Therefore I don't understand, WHO will inject something, which is not on
>> the wire. For me that would only be the peer's implementation, which
>> extracts it's "own" CID wrong, or a "spoofed CID" (maybe that's the time
>> to read my proposal about a CID Authentication Code, issue #74.). But
>> with the wrong CID, the wrong keys would be selected and the MAC will
>> fail anyway. So, I can't see that collision.
>
> Consider the MAC-then-Encrypt case.  We *know* that there are devices in
> the field that get TLS encryption but not MAC keys for use in monitoring
> situations (e.g., enterprises subject to particular compliance regimes).
> So it is perfectly reasonable to consider a case where a third party has
> encryption keys but not MAC keys, and is not expected to have the
> capability to modify the plaintext of the stream.  However, having stripped
> the encryption by using the keys that they already possess, it is possible
> to move a byte (or in general, multiple bytes) between the cid field in the
> outer portion of the record and the inner plaintext, without modifying the
> MAC value.  Encryption can be reapplied, again using the already-known
> keys, and the stream as received by the other TLS peer is modified,
> breaking the principle that the party not knowing the MAC key should not be
> able to modify the plaintext.
>
> (I am not entirely convinced that encrypt-then-mac is intrinsically immune,
> though a successful attack would seem to require knowledge of the
> underlying structure of the plaintext even if the specific content is not
> known.)
>
> -Ben
>