On Mon, May 30, 2022 at 9:38 AM Robert Moskowitz <[email protected]> wrote:
> Great to know. thanks. My feable attempts to find this were coming up > empty. But now I should be able to put some things together. > > I am assuming that the DTLS header is part of the AEAD protection. Thus I > can squeeze out the UDP CRC? > The DTLS header is included in the AD, yes. > I recall seeing length in the DTLS header, but I do not have it in front > of me. Also want to drop that from the UDP header... > DTLS 1.3 has a header mode in which it omits the length and just uses the UDP length. That may be easier. -Ekr > Anyway, this is good info. > > On 5/30/22 12:12, Eric Rescorla wrote: > > We spent a fair bit of time working to shrink the DTLS 1.3 record layer, > so I'm not sure how much room there is for optimization. > See: > https://www.rfc-editor.org/rfc/rfc9147.html#name-the-dtls-record-layer > > Specifically, the longest header (w/o CID) is 5 octets and the shortest is > 2 octets. The sequence number is used for the IV, so there's no extra there. > > -Ekr > > On Mon, May 30, 2022 at 6:28 AM Robert Moskowitz <[email protected]> > wrote: > >> Greetings Hannes, >> >> This is for the record layer. And I really don't know how much would be >> gained. >> >> But as I would see it, this use of SCHC would be for UDP/DTLS/cipher. >> Since it is starting with UDP, SCHC would have to be an IP Protocol (not >> currently defined as such). So you loose 1 byte for the SCHC rule, against >> the 8 probably saved in compressing UDP to 0 bytes. Then there is the >> cipher. Try AES-GCM-12; what is currently used for the IV? Can something >> like rfc8750 be added to use the seq # in the DTLS header and gain maybe 16 >> bytes? I really don't know the DTLS header at all. I have tried to find >> some decent layout as I am use to for ESP in 4303 (Fig 1) for side-by-side >> comparison. >> >> But if it means being able to fit over some UHF carrier for unmanned >> aircraft (UA) Network Remote ID (Net-RID) and Command and Control (C2)? >> Worth the effort. >> >> So this is not something I could do myself, but something that I see >> using and thus pitching in on doing it. >> >> On 5/30/22 05:33, Hannes Tschofenig wrote: >> >> Bob, is this about compressing the DTLS record layer or the DTLS >> handshake protocol? >> >> For the former, I wonder how much is there actually to compress (when >> using DTLS 1.3)? >> >> >> >> *From:* TLS <[email protected]> <[email protected]> *On Behalf Of * >> Eric Rescorla >> *Sent:* Friday, May 27, 2022 5:30 PM >> *To:* Robert Moskowitz <[email protected]> >> <[email protected]> >> *Cc:* <[email protected]> <[email protected]> <[email protected]> <[email protected]> >> *Subject:* Re: [TLS] SCHC for DTLS >> >> >> >> >> >> >> >> On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz <[email protected]> >> wrote: >> >> Is there any activity to define SCHC rules for DTLS? >> >> >> >> Not to my knowledge. >> >> >> >> -Ekr >> >> >> >> >> I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID) >> communications from the UA to the Net-RID Service Provider (SP). >> >> See >> >> https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/ >> >> I am compressing ESP traffic using rfc 8750 and: >> >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ >> >> SCHC is negotiated in IKE (and will be in HIP) and SA tables allow the >> ESP receiver to recognize a SCHC compressed ESP Header and act properly. >> >> It is not so simple with DTLS. First UDP is below DTLS, so how do you >> compress it? The way I see it, SCHC would need to be assigned an IP >> Protocol type so that the transport processing can start right up with >> the SCHC rule for UDP and then on to DTLS and then the cipher. >> >> Or at least how I see the challenge. >> >> So I am looking for any extant work on SCHC for DTLS and/or interest in >> this activity. >> >> The CoAP SCHC work, rfc 8824, dodge DTLS compression. Or that is how I >> read it. >> >> Thanks >> >> Bob >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
