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 <ynir.i...@gmail.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
