[lp-wan] FW: [TLS] SCHC for DTLS

[[e-mail]]

Hello lpwaners,

I’m crossposting this conversation taking place on the TLS mailing list, for those of you who have not subscribed to it.
Any takers to discuss DTLS compression with SCHC?

Dominique


From: TLS [mailto:[e-mail]] On Behalf Of Robert Moskowitz
Sent: 30 May 2022 15:28
To: Hannes Tschofenig <[e-mail]>; Eric Rescorla <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] SCHC for DTLS

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]<mailto:[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]<mailto:[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.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.