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

[Benjamin Kaduk <[e-mail]>]

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