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
