sorry, open source != standardisation and vice versa Arnaud Taddei
Global Security Strategist | Enterprise Security Group | ITU-T SG17 chair mobile: +41 79 506 1129 Geneva, Switzerland arnaud.tad...@broadcom.com | broadcom.com On Mon, Feb 24, 2025 at 11:30 PM Aaron Zauner <azet= 40azet....@dmarc.ietf.org> wrote: > Hey, > > On Mon 24. Feb 2025 at 22:54, Martin Thomson <m...@lowentropy.net> wrote: > >> On Tue, Feb 25, 2025, at 06:56, Aaron Zauner wrote: >> > To be clear; I agree with that in principle but have the feeling that >> > the discussion around an applicable threat model misses the issue of >> > what should be in IETF and what should be in development docs, >> > debugging tools etc entirely. I'm not currently working on maintaining >> > a crypto lib as many of you are but you can't honestly tell me it's not >> > possible to work on your end without IETF guidance on debug specifics >> > that allow encrypted traffic detail export -- which you already have in >> > place for debug and dev anyway. >> >> This also misses the point. The existence of this format (it will exist >> whether the IETF publishes a document or not) has enabled interoperation >> between a number of tools. The point of moving this work to the IETF was >> to transfer governance from what was ad hoc to something recognized and >> respected by the community of people who build the interoperating tools. >> >> Some people view interoperable standards as somehow changing the demand >> and availability of the thing they document. Maybe that's true in some >> markets, but my experience is that the demand is what causes the creation >> of standards, not the other way around. Also, if there were not already >> interoperation and you were concerned that interoperation would cause >> problems, this might be problematic, but this is a case where that >> interoperation already exists > > > I understand your point and just like config formats I see why you'd want > to have a published document. But just like with configs it's part of the > local tool chain and not a wire format. Open source projects have been able > to work with them and use them without involving IETF. I'm just not sure > this is the right place for the document. You've done the work and > documentation anyway already, and you're interoperable. What do you really > gain by having this in IETF? It's also a fringe topic; With that I mean in > this case that it's debug specific to a few projects related to TLS and > while this is the TLS WG it's still a tooling issue in my estimate. I'm > really not sure what the big upside is of having it published here. A lot > of chrome, openssl and other tool chain specifics are likewise only > documented in the relevant project documents and it works fine for everyone > involved; Is there any precedent that showed we need this in IETF - ie. > where interop and debugging didn't work out because you couldn't already > agree on a format and document it? Because it seems to me the community has > already achieved all of this due to your and other people's contribution > without adding it as an IETF doc. > > Thanks, > Aaron > > > >> _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
