Re: [TLS] WGLC for draft-ietf-tls-flags

["StJohns, Michael" <[e-mail]>]

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 <[e-mail]>
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
> > [e-mail]
> > 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
>
>
>
>
>