Hi Achim and all, > > Now, it turns out in the specific situation (and whenever the data > > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > > might as well buffer and coalesce all the application stuff into one > > single record, making the need for CID compression moot.
> I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size > of the UDP message (or that of the DTLS "application_data" part). Only > for TCP the size is explicitly encoded in the CoAP messages (but that's > not RFC7252). If I miss something about that, it would be great, if you > share some details to help me out. > In my opinion, introducing a new TLS Content Type > "multi_application_data" would help in a more general way. Even without > the "implicit CIDs" discussion it may help in some cases, where a couple > of "very small" "application_data"-messages are sent at once. As mentioned before, I second that wish for more efficient stacking of multiple records within a single datagram. Note that this goal could also be achieved without an additional content type if we'd go for the pseudo-header AAD. Namely, in this case, one could generalize the implicit CID to allow dropping further header fields and defining their implicit value for non-initial records, as Thomas mentioned before: (a) For CID, the value is the same as for the previous record in the datagram (perhaps transitively continued). (b) For record sequence numbers, an omitted sequence number means that it's the successor of the one used in the previous record. (c) For epochs, the value is the same as for the previous record in the same datagram. If you follow this through, you end up with the extreme possibility of having multiple DTLS records within a single datagram, where the explicit headers of the non-initial records consist solely of their length. This would still be longer than what you'd get with a multi_application_data content type, or application layer framing, because the authentication tag overhead occurs multiple times, but it comes at the benefit of not changing the protection of the records, since the input to the AEAD algorithm is unchanged. It's only the record header _format_ that can be chosen freely and optimized dynamically. Regards, Hanno ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Achim Kraus <achimkr...@gmx.net> Sent: Thursday, May 28, 2020 9:02 AM To: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] Banning implicit CIDs in DTLS Hi Thomas, > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size of the UDP message (or that of the DTLS "application_data" part). Only for TCP the size is explicitly encoded in the CoAP messages (but that's not RFC7252). If I miss something about that, it would be great, if you share some details to help me out. In my opinion, introducing a new TLS Content Type "multi_application_data" would help in a more general way. Even without the "implicit CIDs" discussion it may help in some cases, where a couple of "very small" "application_data"-messages are sent at once. best regards Achim Am 27.05.20 um 12:03 schrieb Thomas Fossati: > On 24/05/2020, 20:45, "Eric Rescorla" <e...@rtfm.com> wrote: >> In what context do you have a use for implicit CIDs? > > The specific use case I had in mind is that of an endpoint sending small > and frequent application data units to the same peer - e.g., sensor > readings through CoAP observe. In this (and similar) situation(s) where > the payload / header ratio is low one wants to have as little transport > overhead as possible. > > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. > > So, I am now convinced I don't have a compelling case to bring to the > table and might as well move into Martin's "vanishingly small use cases" > camp, therefore subscribing the gist of PR#148. > > > PS A note about the more general argument of a pure pseudo-header > approach: it'd enable compression boxes at ingress into a constrained > network, which would be really useful. Without a thorough analysis wrt > header malleability this is unfortunately out of reach. > > -- > > 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 > _______________________________________________ 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
