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 <achimkr...@gmx.net>
An: Benjamin Kaduk <ka...@mit.edu>
Kopie (CC): draft-ietf-tls-dtls-connection...@ietf.org, tls@ietf.org
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!
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.
best regards
Achim
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
