ietf-wg-privacypass / draft-ietf-privacypass-auth-scheme-extensions

Other
0 stars 3 forks source link

`Extensions` format #10

Open thibmeu opened 6 months ago

thibmeu commented 6 months ago

Current

The current draft defines Extensions as follow

struct {
    ExtensionType extension_type;
    opaque extension_data<0..2^16-1>;
} Extension;

struct {
    Extension extensions<0..2^16-1>;
} Extensions;

The contents of Extensions are a list of Extension values, each of which is a type-length-value structure whose semantics are determined by the type. The type and length of each extension are 2-octet integers, in network byte order. The length of the extensions list is also a is a 2-octet integer, in network byte order.

As observed by @armfazh, an Extension maximum length in network byte order being 2 (type) + 2 (data length) + 2^16 (data). This does not fit in Extensions.

Proposed

We suggest the following:

const MAXIMUM_EXTENSION_DATA_LENGTH = 2^16 -2 -2 = 2^16-4;

struct {
    ExtensionType extension_type;
    opaque extension_data<0..MAXIMUM_EXTENSION_DATA_LENGTH-1>;
} Extension;

struct {
    opaque extensions<0..2^16-1>;
} Extensions;

The contents of Extensions are a list of Extension values, each of which is a type-length-value structure whose semantics are determined by the type. The type and length of each extension are 2-octet integers, in network byte order. The length of the extensions list is also a is a 2-octet integer, in network byte order.

Changes:

  1. Use opaque to avoid confusion between the extension length being the number of extensions or the length in network byte order of the serialized extensions
  2. Limit the extension data length to fit within Extensions data structure.

This should not change existing implementation, apart from adding one more constraint on what constitute a valid extension.

dvorak42 commented 2 months ago

I'd suggest keeping the language as it currently is in the draft, since afaik that matches what most structures created using TLS presentation language in other drafts tend to do (where you're explicit about the type of the embedded structure and the sizes internally aren't adjusted based on external constraints). It would be even more messy if Extension was embedded in multiple places with different maximum lengths based on the enclosing structs (ie SignedExtensions (max 2^16-1) with extensions list (max 2^16-3) with an Extension (max 2^16-5).