Re: [TLS] tls-flags: abort on malformed extension

[Yoav Nir <[e-mail]>]

Hi.

I updated the PR.  If there are no further objections, I will commit and submit a new version in time for the submission deadline.

Yoav


> On 7 Oct 2021, at 21:37, Yoav Nir <[e-mail]> wrote:
> 
> Since I prefer to have the discussion in a single place, I’m copying below a comment by David Benjamin from GitHub:
> 
>> On 28 Aug 2021, at 23:36, Yoav Nir <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi.
>> 
>> To address Michael StJohns comment from 19-July, I submitted PR #12:
>> 
>> https://github.com/tlswg/tls-flags/pull/12 <https://github.com/tlswg/tls-flags/pull/12>
>> 
>> What is says is that any implementation receiving a malformed tls_flags extensions should abort the handshake. The text provides a list (which I hope is comprehensive) of all the ways this specific extension can be malformed. 
>> 
>> Please comment here or on the PR is this makes sense to everybody.
> 
> 
> My proposed text:
> 
>>    An implementation that receives an invalid tls_flags extension MUST 
>>    terminate the TLS handshake with a fatal illegal_parameter alert. 
>>    Such invalid tls_flags extensions include: 
>>     * zero-length extension
>>     * Multiple tls_flags extensions for the same message
>>     * A flag set in the tls_flags extension of the wrong message, as 
>>       specified in the document for that flag     
> 
> 
> 
> David’s comment about the zero-length extension:
>> If we want this to be invalid, we can put it in the TLS presentation language. Change FlagExtensions to:
>> 
>>       struct {
>>          opaque flags<1..255>;
>>       } FlagExtensions;
> 
> 
> David’s comment about the multiple extensions:
>> RFC8446 already prohibits this on the sender. We don't do a good job of defining the rules for the receiver, but that should probably be done uniformly across all extensions, rather than just in this one
> 
> 
> David’s comment about the flag on the wrong message:
>> This seems unimplementable. If I receive a message with a flag I don't recognize, I have no idea whether the flag is allowed in the message or not. Yet this text says I MUST enforce this rule. (There's probably some corresponding wording in RFC8446 we can borrow.)
>> 
>> Nit: It also seems better to phrase this in terms of the registry, rather than the document. We might have multiple documents for the flag if we have to update it.
> 
> OK, so now my response:
> 
> I agree with the first and second comments. About the third, what I meant was that a supported flag that is supposed to appear only in CH appears instead and CR, or more likely, a flag that should appear in EE apears in SH instead.
> 
> But I think the best way to resolve the issue is to remove the bullet point list and the last sentence before them, IOW: remove the examples.
> 
> If this is agreeable to everyone, I will modify it in my PR.
> 
> Yoav