> > (*): Even if we optimize the CID away with cTLS the question about the > > security implications will surface again.
> I think that cTLS is the answer to the size issue. But there, the rule tends > to be that removing from the wire doesn't also remove from the canonical > value that is processed by the stack, so we > might be able to send without a > CID, but re-insert the value before processing. As the canonical form, DTLS > always including the value seems fine to me. On: "the rule tends to be that removing from the wire doesn't also remove from the canonical value that is processed by the stack" I fully agree, and whether true or not, that's the reason why so far I thought that an AEAD that's agnostic of compression techniques and operates as-if there's always a full header on the wire, is more robust than what we have at the moment. Regarding re-introducing the explicit CID in DTLS 1.3: My impression so far was that DTLS 1.3 attempts to already incorporate some record compression ideas through the flexible header format, and I'd find it cleaner to either explore and use those ideas fully (including implicit CIDs, for example), or leave them for c[D]TLS entirely and stick to a single header format for DTLS 1.3. But that's subjective. Apart from that, thanks Martin for sharing the paper https://felixguenther.info/Q20_RC.pdf in the other thread, I think it might be useful for this thread, too. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
