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 <[email protected]>
An: Benjamin Kaduk <[email protected]>
Kopie (CC): [email protected], [email protected]
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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
