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

[Benjamin Kaduk <[e-mail]>]

Hi Achim,

On Fri, Oct 09, 2020 at 07:56:00AM +0200, Achim Kraus wrote:
> 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".

Ah, I see what you mean now.

If we are concerned about changing the behavior, we can (and, arguably,
should) allocate a new TLS extension codepoint to indicate the new
behavior.  That would leave existing implementations able to function with
the old semantics until they age out/are upgraded/etc.

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

I understood your previous message, as well -- yes, the CID length is not
encoded in the message on the wire, and is implicit based on what the
entity allocating it has advertised.  I am asserting that the cryptographic
construction we are using is flawed, which is independent of what is
actually on the wire.

To be frank, I'm actually surprised that this is even seen as a matter for
discussion.  We've been doing quite well recently (e.g., for TLS 1.3) at
using rigorous and veriviable cryptographic constructions that are provably
secure at the smallest modular level.  This scheme is a regression in that
regard -- it relies not only on the cryptography for secure operation, but
also on some specific behavior of the application that is external to the
cryptographic processing (relating to how the application extracts the CID
and looks up the DTLS association/key material).  The behavior we should
demand from our cryptographic constructions is that the cryptography itself
correctly returns "valid" or "invalid" based on the input message, provided
that the application inputs the correct key material.  (It should also
return "invalid" if incorrect key material is supplied, of course.)  The
ability to produce two different messages for which the cryptography
returns "valid" violates this principle; even if we do not see an obvious
path by which a reasonable application might supply those inputs to the
cryptographic code, it is still a flawed construction.

-Ben

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