Hi Ben,
at least at your point (from the e-mail before)
> and not have to change it again.
I agree :-).
That will naturally become true, if the RFC gets released.
best regards
Achim
Am 26.10.20 um 17:56 schrieb Benjamin Kaduk:
Hi Achim,
On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:
Hi Ben,
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers. This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time
constant. Implementations, which want to use variable-length CIDs,
are responsible for constructing the CID in such a way that its
length can be determined on reception. Such implementations must
still be able to send CIDs of different length to other parties.
Note that there is no CID length information included in the record
itself.
...and thanks for the reminder about how we say so in the text already.
(your example from a previous e-mail)
> 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>.
I would feel much more comfortable, if you state,
that you consider now either
1. that example was not compliant to the draft,
or
2. the draft is not clear enough about that.
If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
closed.
It is neither of those two.
While the party that will be parsing packets that use a given CID value to
identify the connection needs to be able to determine the length from the
byte stream, the other party does not. Accordingly, when computing the
MAC, there is still malleability in terms of which "interpretation" of the
byte stream was intended by the party computing the MAC. The party
receiving the packet (and MAC) will only use one interpretation, but the
party generating the MAC could have been deceived into using the other
interpretation.
As I said previously, the CID values are not authenticated until the
handshake completes, so there is a real window where this attack surface is
exposed. Note that I do not need to present a complete end-to-end attack
that breaks the TLS guarantees in order for us to change the spec -- it is
enough to have shown that the malleability of the cryptographic input
stream is exposed to potential attack. To leave such behavior in a
published protocol spec would be irresponsible, in effect, publishing an
algorithm with known weaknesses.
Thanks,
Ben
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
