On Fri, Jul 8, 2022 at 12:06 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Jul 07, 2022 at 09:25:15PM -0700, internet-dra...@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : IANA Registry Updates for TLS and DTLS > > Authors : Joe Salowey > > Sean Turner > > Filename : draft-ietf-tls-rfc8447bis-01.txt > > Pages : 24 > > Date : 2022-07-07 > > I find this from section 7 confusing: > > > * IANA [SHALL update/has updated] this registry to include a "TLS > > 1.3" column that lists the messages in which the extension may > > appear. This column [SHALL be/has been] initially populated from > > the table in Section 4.2 of [I-D.ietf-tls-rfc8446bis] with any > > extension not listed there marked as "-" to indicate that it is > > not used by TLS 1.3. > > The issue here is: > > - The [SHALL/has] language means pending change. > - The TLS 1.3 column in the registry already exists. > - There are about dozen TLS 1.3 extensions in the extensions registry > that are not in the table in RFC8446bis (few are even recommended). > - The text can be read to clear TLS 1.3 flags on those ~dozen > extensions, which I do not think is intended. > > > There's also this: > > > * IANA [SHALL update/has updated] this registry to include the > > "key_share", "pre_shared_key", "psk_key_exchange_modes", > > "early_data", "cookie", "supported_versions", > > "certificate_authorities", "oid_filters", "post_handshake_auth", > > and "signature_algorithms_cert", extensions with the values > > defined in [I-D.ietf-tls-rfc8446bis] and the "Recommended" value > > of "Y". > > As far as I can tell, the values in the registry already match what is > listed in rfc8446bis (other than maybe references). > > [Joe] Thanks for reviewing this draft. The current draft is written so it obsoletes rfc 8447. I think this is the main source of the issues you list. I think it would be clearer if this draft just updated RFC8447 so we don't have to repeat information that has already been acted upon. I think this would make it easier to review and easier for IANA to implement. I just submitted a new version with section 7 written as if it is an update. Does this make things clearer? Is there a reason why we should not take the update approach? > > And while going over this, I also found that extension #52 > transparency_info seems to have recommended=Y. The problem is that > the RFC9162 is Experimental, while recommended=Y requires standard > action. > > [Joe] RFC9162 did ask for a Y recommendation, however I'm not sure that an experimental draft is a "standards action" since I'm not sure it has to go through IESG review. For this particular instance the draft did go through IESG review and I think the Y value is intentional. Since experimental drafts do not need to go through IESG review. I added some text to the notes in section 7 that might help point this out during the process, but perhaps we should be explicit about mentioning the expectations around experimental and informational tracks. > > > -Ilari > > _______________________________________________ > 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
