Ekr, can I ask you to clarify this a little? I fully agree that extensions to TLS which support a particular application-layer protocol should be done in that protocol’s working group unless and until it’s demonstrated that many unrelated applications will need something similar. (At which point, it probably makes sense to build the general thing, either in TLS or a new WG.) But this isn’t that.
For something that concerns the TLS exchange itself, the TLS WG does still seem like the natural home to me. Where are you suggesting the standards work happens instead? Are you suggesting that this should be registered to the I-D, or go to a new/different working group? The former path seems like it won’t get the review it needs, and I’m not sure any other WGs are appropriately chartered for the latter. Personally, I support adoption for the use case. It sounds like there’s an alternative design that might need to be hammered out, but since it appears a document may be needed for either path, let’s adopt and argue about that later. From: TLS <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Wednesday, April 3, 2024 10:28 AM To: Watson Ladd <watsonbl...@gmail.com> Cc: Christopher Patton <cpatton=40cloudflare....@dmarc.ietf.org>; TLS List <tls@ietf.org> Subject: Re: [TLS] Adoption call for TLS Flag - Request mTLS On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>> wrote: On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: Adoption should not be required to register a code point [0], as the policy is Specification Required. I'm mildly negative on adopting this document. What is the reason we need to spend WG time on this, rather than just having a code point assignment? Well, don't we want to say how this is supposed to work somewhere? Why? The attitude I am trying to get away from is that the TLS WG has to be involved in every extension to TLS. Rather, we should decide what things are important and spend time on them and then let others extend TLS independently in areas we don't think are important. -Ekr I doubt this will take much time. -Ekr [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13 should clearly have a policy which matches 8447 S 7, which is to say that an I-D is sufficient. On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton <cpatton=40cloudflare....@dmarc.ietf.org<mailto:40cloudflare....@dmarc.ietf.org>> wrote: I'd like to see this problem solved. There was some discussion about whether an I-D is needed or all we needed was to register a code point somewhere. If most agree that an I-D is needed, then let's adopt it. I'm happy to review. Chris P. On Tue, Apr 2, 2024 at 12:22 PM Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>> wrote: At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see previous list discussions at [0]. This message is to judge consensus on whether there is sufficient support to adopt this I-D. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this I-D, please send a message to the list and indicate why. This call will close on 16 April 2024. Thanks, Deirdre, Joe, and Sean [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/ _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
