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 <ynir.i...@gmail.com> 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 <ynir.i...@gmail.com >> <mailto: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
