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
