Original text:
"extension_data" contains information specific to the particular extension type.  The list of extension types is maintained by IANA as described in iana-considerations.

Reviewer comments:
This was already a compliance requirement, but spell it out more explicitly.
LGTM
AFAICT it isn't. URL also comes to mind
NAME Good catch.
It's already required. Length prefixes typically come from the syntax in the presentation language. Not only would a parser that allows trailing data be non-compliant, but it'd be totally incoherent. Vectors don't tell you the number of elements, so the only way to parse it is to loop until empty, peeling off s. That means, if there is any trailing data, it'll be immediately interpreted as another instance of , not trailing data. Whereas is a little different because it's an byte string whose contents happen to be another structure. TBH, I don't think this case needed a clarification either (it's pretty obvious, IMO), but a clarification doesn't hurt so whatever.
NAME I think that you are right when it comes to lists of things. I was thinking about structs in general. However, in QUIC, we have transport parameters, which would share the need for this exact treatment; that we decided to manage that within QUIC rather than use the TLS grammar means that we don't need to worry about it, but it suggests that nested extension points will hit this problem too. I was trying to find other such instances, but I can't find any offhand. I was looking at , and that uses a statement, which suggests that it is simply impossible to include a non-zero type value (another reason that server name extension is irredeemably busted; and of course, that's not how NSS implements it; from memory, we assume every type has a 1 byte length prefix...). I thought that handshake messages might need this, but the grammar seems to prevent that in the same way as servername. An unknown handshake message hits a switch statement and falls out, presumably into an error condition. So even though the format might allow an unknown handshake message to be ignored the grammar suggests that it is always an error (which, to be clear, is a good thing from a protocol perspective). The encapsulation of handshake messages in records is another place that is interesting. In TLS, that doesn't matter much because the extra bytes roll over and we are back in your "next instance of " case, but it is a problem in DTLS where each record needs to contain discrete fragments. So I do think that it would be better to have this be a general statement, even if it there is precisely one instance where we know it definitely applies.
the only place where trailing data is allowed is after ClientHello for implementations that don't support extensions
A receiver will not necessarily parse every entry in the vector, if it finds what it's looking for before it gets through the whole vector.
Hmm. Where were you envisioning putting this generally? The definition of various length prefixes are kind of scattered all over the place.
Section 3.9?
As far as I can tell, there is no requirement in RFC 8446 for receiving endpoints to verify that the self-encoded length on outer headers corresponds to the self-encoded lengths of component items. Mangled extensions that do this kind of thing are likely going to end up with decoding errors, but if the outer length is too long many implementations might survive, assuming they support the extension. If it's not too onerous on implementations, it would be good to require a fatal alert if receivers detect this condition, to make behavior more predictable and ease debugging.
Which lengths are you referring to? I can't think of any length prefixes in RFC8446 that receivers are allowed to ignore. Are you saying that, if the length prefix on is longer than the structure inside it, receivers are allowed to ignore trailing data? I'd consider any implementation that allowed this non-compliant. The spec often contains text like: It doesn't say the body has a prefix of a CertificateAuthoritiesExtension structure. (And, of course, if the length prefix is too short, you'll hit the end of before you finish parsing the inner structure at all.)
Obviously, bogus extension_data lengths are wrong, but there's no enforcement mechanism. If receivers MUST check that these match and abort if they don't, that would have the benefits described above. I think we're agreeing that ignoring trailing data would be wrong, but it's not actually written anywhere AFAICT. Equally obviously, this is not the end of the world and TLS has apparently operated fine like this for a long time. But it's also the kind of problem that QUIC has spent a fair amount of energy to avoid.
I think it is already the case that receivers MUST check this. Receivers that don't are non-compliant. It's written somewhat implicitly by way of saying the body "consists of" such-and-such structure, but I think the most reasonable interpretation of this would be that you don't allow trailing data. I'd support adding a sentence or two to the section 4.2 to clarify how extension definitions work in general. Though I've never heard of an implementation that misinterpreted this and did the wrong thing.
Agree and NAME I don't know of any implementation that allows extending a field with arbitrary data and then ignoring it. They all do "I have 'n' bytes and am expecting a CertificateList" and if they finish with data left over it's a parse error.
If the consensus is that this is a non-problem I am happy to have the editors close the issue.
It's entirely possible that I missed a MUST in 8446 somewhere, but I couldn't find it.
I don't think a sentence to make this clear would be harmful.
How's URL
Why is this specific to extension_data? Why not require this for every length-prefixed construct that contains fields that might not extend to the full length?

Revised text:
"extension_data" contains information specific to the particular extension type. <ins> The contents of the "extension_data" field are typically defined by an extension-specific structure defined in the TLS presentation language.  Unless otherwise specified, trailing data is forbidden. That is, senders MUST NOT include data after the structure in the "extension_data" field.  When processing an extension, receivers MUST abort the handshake with a "decode_error" alert if there is data left over after parsing the structure.  This does not apply if the receiver does not implement or is configured to ignore an extension. </ins> The list of extension types is maintained by IANA as described in iana-considerations.