Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensions format #10

Open
thibmeu opened this issue Mar 18, 2024 · 1 comment
Open

Extensions format #10

thibmeu opened this issue Mar 18, 2024 · 1 comment

Comments

@thibmeu
Copy link
Contributor

thibmeu commented Mar 18, 2024

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
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants