Given that I got a response to a different message on this topic, and that Martin is making a similar point to that I made below, my guess is that this message got lost in the shuffle.
On Sun, Jul 18, 2021 at 19:26 Michael StJohns <m...@nthpermutation.com> wrote: > On 7/16/2021 7:55 PM, Christopher Wood wrote: > > This is the second working group last call for the "A Flags Extension > for TLS 1.3" draft, available here: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > Please review this document and send your comments to the list by July > 30, 2021. The GitHub repository for this draft is available here: > > > > https://github.com/tlswg/tls-flags > > > > Thanks, > > Chris, on behalf of the chairs > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > Hi - I have not followed the discussion of this document on the mailing > list so this review is only against the document itself. It's possible > that these concerns have already been discussed. > > > Section 2 requires (MUST) the generation of fatal illegal_parameter > alert upon reception of a mal-encoded extension (e.g. any trailing zero > bytes), but compare and contrast this with section 3 which is full of > MUST and MUST NOT declarations but with no concrete actions to be > taken. E.g. if I (server or client) send 0x01 0x10, and receive 0x01 > 0x11 from the client or server, wouldn't that be an illegal value as > I've added a bit not sent to me? Should that cause the same fatal > illegal_parameter alert? Alternately, "receiver MUST ignore received > bits that weren't sent" language could clean this up. > > Section 4 is a bit painful to read in that it took me three > read-throughs to understand that what the document is asking for is a > monolithic registry which requires "expert review" for all > registrations, but where the experts are responsible for the sub range > determinations. Usually, that's not the way the IANA works. If a > registry has distinct set of ranges, each range normally has a specific > registration procedure that the IANA follows before placing a parameter > in that registry. > > I'd strongly suggest reviewing RFC 8126 and chatting with the IANA to > see if its possible to reform the registration process along more normal > IANA lines. E.g.: > > 0-7 - Standards Action and Expert Request > 8-31 - Standards Action > 32 - 63 Specification Required or IETF Review (pick one) > 64-79 Private Use > 80-127 RFU or Expert Review > 128-2039 First Come First Served > > > > Absent these two points, the rest of the content looks good. I'd > recommend a draft pass to fix these two items. > > > Later, Mike > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
