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

[Sean Turner <[e-mail]>]

Yoav,

Thanks for moving this along.

spt

> On Oct 20, 2021, at 16:11, Yoav Nir <[e-mail]> wrote:
> 
> 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]> wrote:
>>> 
>>> Hi.
>>> 
>>> To address Michael StJohns comment from 19-July, I submitted PR #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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls