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

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Aug 2021 16:50:12 +1000

I think that this is largely good.

I don't like how the IANA registry is structured and would like to discuss it more.  I think that it is 0-31 (Standards Action), 32+ (Specification Required), but it doesn't say that.  I think that the experimental range (64-79) should not be reserved.  That's relatively valuable space that is being effectively burned forever.  It is also highly dependent on judgment of experts, which gives those experts far more say in the use of the registry than is typical.

(It also says that the registry is initially empty in S2, but it then defines a flag.)

On Sat, Jul 17, 2021, at 09:55, 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "StJohns, Michael" <[email-masked]>
Date: Mon, 2 Aug 2021 03:13:52 -0400

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 <[email-masked]>
wrote:

> On 7/16/2021 7:55 PM, Christopher Wood wrote:
> 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
>
>
>
>
>

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 20 Aug 2021 13:25:41 -0700

This WGLC is now complete. Based on its outcome and past discussions, the chairs believe there is consensus to move forward. There was one important question raised during the WGLC around behavior when receiving unsolicited flags. We will work with the author to prepare a change that addresses this concern, as well as other editorial comments raised during the WGLC. If normative language changes as a result, we will do a brief consensus call on the changes before requesting publication.

Best,
Chris, for the chairs

On Sun, Aug 1, 2021, at 11:50 PM, Martin Thomson wrote:
> I don't like how the IANA registry is structured and would like to 
> discuss it more.  I think that it is 0-31 (Standards Action), 32+ 
> (Specification Required), but it doesn't say that.  I think that the 
> experimental range (64-79) should not be reserved.  That's relatively 
> valuable space that is being effectively burned forever.  It is also 
> highly dependent on judgment of experts, which gives those experts far 
> more say in the use of the registry than is typical.
>