Draft: draft-ietf-tls-rfc8446bis

Commentary: This was already a compliance requirement , but spell it out more explicitly . 
 LGTM 
 AFAICT it is n't . also comes to mind 
 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 do n'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 do n't think this case needed a clarification either ( it 's pretty obvious , IMO ) , but a clarification does n't hurt so whatever . 
 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 do n'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 ca n'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 does n'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 do n'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 ca n'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 does n'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 do n'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 do n'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 do n'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 I do n'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 could n't find it . 
 I do n't think a sentence to make this clear would be harmful . 
 How 's 
 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 ?
Paragraph (version B):
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.