SUD2 - Notifying other clients of the SUD2 methods supported

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
Posts: 73
Joined: 14 Nov 2010, 13:06

SUD2 - Notifying other clients of the SUD2 methods supported

Post by klondike » 30 Mar 2013, 16:34

I have realized that SUD2 is more composable than I expected and I think it would be cleaner to add a few INF fields so clients can know which methods can they use to speak between them without a need of updating the protocol version.

Basically SUD2 is composed of the following items: an obfuscation scheme (in the specification it is AES in CTR mode), an authenticated encryption with authenticated data scheme (in this case AES in SIV mode), if desired a compression scheme (in this case zlib), and also if desired a dictionary. I think than instead of just bumping the FOURCC version every time we need/want to update one of these, for example somebody may suggest we replace zlib with lzop or lz4 or come up with a better dictionary or even suggest using OFB mode when the patents expire, we should announce the supported schemes through INF fields so other clients can know and act in consequence.

As such I was thinking of the following named parameters:
SO: a coma separated list of the obfuscation modes supported by the client, 128 bit AES in CTR mode is number 0. In general we should avoid changing these as much as possible since each different obfuscation mode requires at least one decryption for key in order to know whether it is the correct one or not.
SE: a coma separated list of the authenticated encryption modes supported by the client, 128 bit AES in SIV mode is number 0.
SC: A field in the format mode,dictionary1, dictionary2,...:mode,dictionary1,dictionary2 ... (for example 0:1,1,2:2,3:5,1,2,4 would mean that mode 0 is supported (and no dictionaries can be used), 1 is supported with dictionaries 1 and 2, mode two is supported with the dictionary 3 and mode 5 is supported with the dictionaries 1,2 and 4) where mode 0 is no compression (where obviously no dictionaries are used) and mode 1 is DEFLATE (where 0 means no dictionary and 1 is the SUD2 dictionary). The dictionaries vary between compression modes, but in all of them the dictionary 0 is reserved to indicate no dictionary is needed.

Posts: 73
Joined: 14 Nov 2010, 13:06

Re: SUD2 - Notifying other clients of the SUD2 methods suppo

Post by klondike » 30 Mar 2013, 16:59

[17:41:52] <poy> my first impression is "over-engineered", but if it works... :)

[17:44:29] <klondike> poy: I thought is the best way to prevent for possible future cryptographic outbreaks

[17:45:07] <klondike> I'm also wondering if none encryption needs to be marked, I really can't see a reason to need it there since clients should just support it

[17:46:03] <poy> it's decent... the question is how often crypto/dicos are going to change in the future. if it's say every 2 years, i think raising the SUDP version would be enough.

[17:47:07] <poy> that's added data in INFs (dispatched to every user) for a rare event.

[17:48:58] <klondike> poy the hub can choose to filter this data for users not marking SUD2 support in their SUP

[17:50:15] <klondike> But yeah, you make a good point there, the other option I have is different FourCCs for clients supporting compression or not but I really don't feel that confortable for it

[17:50:43] <iceman50> compression

[17:51:01] <klondike> Also think that SUD2 already trusts the hub on distributing the fourCC to the clients for him since otherwise they won't be able to comunicate with him

Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: SUD2 - Notifying other clients of the SUD2 methods suppo

Post by Pretorian » 01 Apr 2013, 18:02

The following is simply a comment on the variety of ways one can manage new content with commands and fields. I'm not saying you have to choose one approach, I'm just pointing out that one can do different things.

A field in ADC can be structured in the following ways;
1) One field with no parsing required (not really applicable)
2) One field with parsing required ("SC0:1,1,2:2,3:5,1,2,4")
3) Multiple fields with no parsing required (not really applicable)
4) Multiple fields with parsing required (SC0 SC1,2,2 SC2,3) (This option can mean that the structure of the field can be e.g. "mode:dict1,dict2", which I find easier to read.)

I.e., one can break up the field by using multiple (with the same name) fields alleviating some parsing requirements. Using multiple fields also increase readability and may decrease any confusion.

The question is how often the dictionaries themselves change, as has been noted.

Are there requirements on what dictionaries one support in respective mode? If so, then one might consider omitting those (as they're implied).

By the way, a slight tangent, it might be interesting for clients to do a F-type INF for this content. It'd alleviate some concern on broadcasting this to everyone... (This should of course be in a recommendation, not the spec.)