You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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
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.
The text was updated successfully, but these errors were encountered:
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).
Current
The current draft defines
Extensions
as followAs observed by @armfazh, an Extension maximum length in network byte order being
2 (type) + 2 (data length) + 2^16 (data)
. This does not fit inExtensions
.Proposed
We suggest the following:
Changes:
opaque
to avoid confusion between the extension length being the number of extensions or the length in network byte order of the serialized extensionsExtensions
data structure.This should not change existing implementation, apart from adding one more constraint on what constitute a valid extension.
The text was updated successfully, but these errors were encountered: