Hi, On Mon 24. Feb 2025 at 13:02, Achim Kraus <achimkraus= 40gmx....@dmarc.ietf.org> wrote:
> Hi List, > > In my experience, this is mainly use to feed the "TlsKeyLog" from some > application into wireshark. And it's curious to me, that not having a > specified format within the IETF/TLS will provide any security. > > For me this sounds more like, > > "we know it's done, but we don't want to be aware of it" Sorry but I simply disagree. Not everything needs to be an IETF standard or document. We've all been able to run debug builds, wireshark and export key data for development, capture the flag challenges or whatever in the past. It's a non argument. While it might sound to you like we don't want to know it your argument to me sounds like we want to standardize crap we all know is not supposed to be in IETF and agreed on policy documents to that effect. We don't write standards on how to write invalid protocols or have worst practice guide lines for the same reason. Even if time and experience sometimes shows us that what we thought might have been a great idea actually in practice worked out to be the opposite. In that case I'm not sure how anyone can't see that right away. Not everything needs to be an IETF document. Shiny crap is still crap. These proposals have been around for a while and like Stephen said; they were supposed to document a deployed reality - but even then - they were heavily discussed and there's a reason we didn't agree on many proposals from middle box or client app vendors thus far. Aaron > > (In my case (new function in Eclipse/Californium 4.0.0-M3) it helps > people to debug their CoAP traffic regardless of the used DTLS > cipher suite and without exchanging credentials ahead.) > > br > Achim > > > Am 24.02.25 um 06:00 schrieb Aaron Zauner (azet): > > Hi, > > > > I haven't been active on IETF lists in a while but would also like to > state my clear intention not to have any feature as such standardized. As > has been discussed and pointed out in this thread repeatedly: this *is* > already and can always be a (preferably) default disabled implementation > specific feature. Any standardization and proliferation of features like > these will cause maybe otherwise unintended harm towards unsuspecting end > users. It took many in the community years past 2013 to disable, > compile-out/redact or otherwise remove many of the previously enormous > amount of options some Linux and Unix flavors distributed open source > crypto libs or network services for that enabled users to make stupid, > unreflected decisions when configuring otherwise standard network services > like http or smtp/imap etc.: from RNG inputs to DH params and exponent > files. As far as I know on eg. AIX even today OpenSSH still builds in the > most peculiar ways. But otherwise on most modern production distributions > and end user / development focused operating systems and programming > languages this has been ironed out over long discussions, amendments to man > pages and a complete Linux kernel RNG redesign. Please let's not do this > all over again. it's just another easy entry point for supply chain attacks > or might serve as a rationale for vendors like pegasus that their > intentions are really ours as long as they are under LI / gov contract no > matter what's the end result. > > > > All the best, > > Aaron Zauner > > _______________________________________________ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
