[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

[Arnaud Taddei <[e-mail]>]

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: [phone]

Geneva, Switzerland

[e-mail] | broadcom.com


On Mon, Feb 24, 2025 at 6:02 AM Aaron Zauner (azet) <azet=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 
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.