Hello,

Theo Buehler wrote on Tue, May 06, 2025 at 06:26:55AM +0200:
> LWS wrote:

>> So it is an openbsd decision although it is not clear to me if it is a
>> security
>> design decision or rather a standards adherence decision, since it seems to
>> me
>> that the software that implements this feature does it outside the
>> standards.

> It's a debugging tool amounting to a complete compromise of the most
> important guarantees provided by TLS. It is not formally standardized
> yet but that's just a matter of time at this point:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
> 
> If the security considerations are about as long as the description of
> the thing you specify...

On top of that, the Internet-Draft quoted above that aims to define that
feature contains this gem (in paragraph 1.1. Applicability Statement):

   [...]
   this mechanism MUST NOT be used in a production system.
   For software that is compiled, use of conditional compilation
   is the best way to ensure that deployed binaries cannot be
   configured to enable key logging.

Given that OpenBSD is distributed in compiled form and end users are
not encouraged to recompile the system, but rather to use the
officially compiled binaries (which has proven useful to make
things easier for users and reduce the frequency of user errors,
resulting in improved security and convenience for users),
given that overuse of conditional compilation is among the chief
diseases of the OpenSSL code base, that an extensive use of the
unifdef(1) flensing knife has been among the chief tools of making
LibreSSL easier to understand, easier to audit, and hence more secure,
given that these efforts are still ongoing, meaning that unifdef(1)ing
remains an important goal and adding new conditionals is normally not
desirable, and that Portable LibreSSL does, as a matter of principle,
never provide functionality not provided in OpenBSD (which improves
security, too),

the above stipulation in the Internet-Draft itself essentially
says

   LibreSSL SHOULD NOT provide the functionality described
   in this memo.

(my paraphrase), so even in case this draft should eventually be
blessed into becoming an RFC, the standard itself RECOMMENDS that
LibreSSL SHALL ignore it and SHALL NOT implement it.

On top of that, OpenBSD sometimes declines implementing ill-designed
parts of standards that are unavoidably insecure even if the respective
standards say that those parts MUST be supported.  It seems highly
unlikely to me that OpenBSD might choose to implement a standard that
essentially says *itself* that OpenBSD SHOULD NOT implement it.

In the above, i intend the ALL CAPS words in the sense specified
in RFC 2119.

Yours,
  Ingo