Yoav, Thanks for moving this along.
spt > On Oct 20, 2021, at 16:11, Yoav Nir <ynir.i...@gmail.com> 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 <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> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
