Re: [TLS] SCHC for DTLS

[Robert Moskowitz <[e-mail]>]

On 5/30/22 13:03, Eric Rescorla wrote:
>
>
> On Mon, May 30, 2022 at 9:38 AM Robert Moskowitz 
> <[e-mail]> 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
>>     <[e-mail]> 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 <[e-mail]>
>>>         <mailto:[e-mail]> *On Behalf Of * Eric Rescorla
>>>         *Sent:* Friday, May 27, 2022 5:30 PM
>>>         *To:* Robert Moskowitz <[e-mail]>
>>>         <mailto:[e-mail]>
>>>         *Cc:* <[e-mail]> <mailto:[e-mail]> <[e-mail]>
>>>         <mailto:[e-mail]>
>>>         *Subject:* Re: [TLS] SCHC for DTLS
>>>
>>>         On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz
>>>         <[e-mail]> 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
>>>             [e-mail]
>>>             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. 
>>
>