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

From: "Christopher Wood" <[email-masked]>
Date: Fri, 16 Jul 2021 16:55:49 -0700

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

---

From: Watson Ladd <[email-masked]>
Date: Sun, 18 Jul 2021 14:39:36 -0700

> Please review this document and send your comments to the list by July 30, 2021. The GitHub repository for this draft is available here:

I support publication.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Astra mortemque praestare gradatim

---

From: Michael StJohns <[email-masked]>
Date: Sun, 18 Jul 2021 19:26:52 -0400

> Chris, on behalf of the chairs

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: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Jul 2021 14:35:20 -0400

>     https://github.com/tlswg/tls-flags

Just one editorial comment, I think that the initial registration code
point of 0x8 (hex) is potentially confusing, is it the 8th bit, or the
or bit 3?  The bit positions range from 0 to 2047 and are easier to
understand in decimal, especially with the registration ranges given
in decimal.  So in this document, and in the IANA registry, the code
points should be decimal.

-- 
    Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Jul 2021 22:50:00 +0300

> On 22 Jul 2021, at 21:35, Viktor Dukhovni <[email-masked]> wrote:
> 

Makes sense. Created a pull request:

https://github.com/tlswg/tls-flags/pull/7

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Jul 2021 22:01:32 +0300

Thanks for the review. Comments inline.

> On 19 Jul 2021, at 2:26, Michael StJohns <[email-masked]> 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.

I prefer the hard error, but this should be discussed in the WG. Perhaps a PR is in order?

> 
> 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.
> 

The way it works with all the TLS registries is that IANA asks the expert for advice on which numbers to assign regardless of how the registry is segmented.  So it’s up to the experts anyway.

Yoav

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 30 Jul 2021 18:59:26 -0700

Given the few responses received thus far, we're going to extend this WGLC for another two weeks. It will now conclude on August 13, alongside the WGLC for draft-ietf-tls-cross-sni-resumption.

Best,
Chris, for the chairs

On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
> Please review this document and send your comments to the list by July 
> 30, 2021. The GitHub repository for this draft is available here:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 31 Jul 2021 17:28:40 +0000

This draft is simple, has had various consensus-things done, and might encourage future experiments.  Ship it.