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

[Michael StJohns <[e-mail]>]

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