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
