Sorry to be extensively late on the overall TLS mailing list (1), on this one
Debugging and security need some level of visibility and they can't operate in the dark. The battle for a 'some of us need a respectful inspection full model precisely because there is one inspection that *wants* to be visible' was lost a long time ago and for the wrong reasons. Yet this is what I read 'en creux' in this discussion. Security practitioners need a minimum to defend and in this multiverse there is no way to go against juvenal law: who guards the guards. There is a price to pay in everything we do: - We keep it silent and the practitioners will still be able to do another form of inspection with no-one being aware on the line and with good, bad and ugly possibilities in the back - We standardize it and in this case we need to take a step back and come with a REAL design approach from anthropology, ethics, legal and technical approach Anyway the tide of the grand world is changing side ... buying a lot of popcorn PS: (1) struggling since 2 months from an extremely painful post surgery 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 6:02 AM Aaron Zauner (azet) <azet= 40azet....@dmarc.ietf.org> wrote: > 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 > -- 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
