Re: [TLS] WGLC for draft-ietf-tls-flags
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 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
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 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 > > 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
Re: [TLS] WGLC for draft-ietf-tls-flags
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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
This draft is simple, has had various consensus-things done, and might encourage future experiments. Ship it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
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: > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
Thanks for the review. Comments inline. > On 19 Jul 2021, at 2:26, Michael StJohns 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 >> 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
> On 22 Jul 2021, at 21:35, Viktor Dukhovni wrote: > > On Fri, Jul 16, 2021 at 04:55:49PM -0700, 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 > > 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. > Makes sense. Created a pull request: https://github.com/tlswg/tls-flags/pull/7 Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
On Fri, Jul 16, 2021 at 04:55:49PM -0700, 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 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-flags
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
Re: [TLS] WGLC for draft-ietf-tls-flags
On Fri, Jul 16, 2021 at 4:56 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: I support publication. > > 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 -- Astra mortemque praestare gradatim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC for draft-ietf-tls-flags
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
