On 5/30/22 13:03, Eric Rescorla wrote:
On Mon, May 30, 2022 at 9:38 AM Robert Moskowitz
<rgm-...@htt-consult.com> 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.
My way of thinking is that the DTLS length is protected. So the SCHC
rule has the source and dest UDP ports as static and derives the UDP
length from the DTLS length. The CRC is just built as if the ICV is
bad, the packet gets dropped there.
So pick up 7 bytes. May or may not make a difference...
Well actually the target size is 16 bytes, as this is what is spent in
MAVlink for Seq#, CRC, and keyed MAC. You can't equal that with 8 bytes
UDP, 12 bytes GCM-12, and whatever DTLS is.
One thing we have discussed on the IPSECME list is inbound packet
processing. With the IP protocol being ESP, how does the ESP layer
'know' that this is a diet-esp compressed header? Well the first byte
would have to map to a SPI that is uniquely diet-esp and rule out
looking at 4-byte full SPIs. This (inbound SPI selection) can be
controlled by IKE.
So a similar thing here. Assume that UDP is compressed to zero, so if
the beginning of the DTLS header would look like a UDP source port, but
map to the SCHC rule, then for this limited use case, it would not be
necessary to have SCHC as an IP protocol and use 1 byte for
over-the-wire SCHC rule.
-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
<rgm-...@htt-consult.com> 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 <tls-boun...@ietf.org>
<mailto:tls-boun...@ietf.org> *On Behalf Of * Eric Rescorla
*Sent:* Friday, May 27, 2022 5:30 PM
*To:* Robert Moskowitz <rgm-...@htt-consult.com>
<mailto:rgm-...@htt-consult.com>
*Cc:* <tls@ietf.org> <mailto:tls@ietf.org> <tls@ietf.org>
<mailto:tls@ietf.org>
*Subject:* Re: [TLS] SCHC for DTLS
On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz
<rgm-...@htt-consult.com> 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
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
