Hi Thomas, The draft makes a far broader claim of risks than you describe: > Access to the content of a file in SSLKEYLOGFILE format allows an attacker to break the confidentiality and integrity protection on any TLS connections that are included in the file. That this includes passwords is definitely a problem. But passwords aren't special. There are many things that could be equally problematic. HTTP cookies often convey more power than a password, for example. I don't agree that a media type makes abuse more of a problem. I've received a number of text/plain files at various times that use this format. Having a media type potentially makes it easier to identify and block any (likely accidental) attempt to leak secrets in this form. Cheers, Martin On Fri, Jul 26, 2024, at 23:49, Thomas Lußnig wrote: > Hi, > > in the risk description there is not mentioned that decryption of the > messages allow to see the plaintext passwords, > used for identification that are otherwise not visible on the system if > they are hashed and salted. So the risk is even > larger than compromising the old and current session. It will > compromise also the user accounts independently of the > ssl protocol. So any access to this will allow impersonation long after > the recording and even after the ssl sessions. > > Another risk is adding an mime-type to this filetype can encourage > developers to send/publish this highly sensitive file via email or web. > > > > Gruß Thomas Lußnig > > > > > > -------------------------------------------------------- > >> Message: 1 >> Date: Thu, 25 Jul 2024 12:13:23 -0700 >> From: The IESG <iesg-secretary@xxxxxxxx> >> Subject: Document Action: 'The SSLKEYLOGFILE Format for TLS' to >> Informational RFC (draft-ietf-tls-keylogfile-02.txt) >> To: "IETF-Announce" <ietf-announce@xxxxxxxx> >> Cc: The IESG <iesg@xxxxxxxx>, draft-ietf-tls-keylogfile@xxxxxxxx, >> paul.wouters@xxxxxxxx, rfc-editor@xxxxxxxxxxxxxx, tls-chairs@xxxxxxxx, >> tls@xxxxxxxx >> Message-ID: <172193480302.1044038.13275141107936697882@dt-datatracker- >> 659f84ff76-9wqgv> >> Content-Type: text/plain; charset="utf-8" >> >> The IESG has approved the following document: >> - 'The SSLKEYLOGFILE Format for TLS' >> (draft-ietf-tls-keylogfile-02.txt) as Informational RFC >> >> This document is the product of the Transport Layer Security Working Group. >> >> The IESG contact persons are Paul Wouters and Deb Cooley. >> >> A URL of this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ >> >> >> >> >> Technical Summary >> >> A format that supports the logging information about the secrets used >> in a TLS connection is described. Recording secrets to a file in >> SSLKEYLOGFILE format allows diagnostic and logging tools that use >> this file to decrypt messages exchanged by TLS endpoints. >> >> Working Group Summary >> >> >> The one thing that worried some people (including your responsible AD) >> was the fact that this could be used as pervasive monitoring tool if this >> file is offloaded/shared on production systems. Numerous warnings were >> added to the document to not do this. As the feature is already readily >> available (Firefox, Chrome, Wireshark, openssl, libcurl, etc.) those >> who are building such monitoring devices can already do so anyway. >> >> Document Quality >> >> This is documenting a widely deployed feature that is used for development >> and debugging major crypto libraries and browsers (see above) >> >> Personnel >> >> The Document Shepherd for this document is Sean Turner. The Responsible >> Area Director is Paul Wouters. >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 25 Jul 2024 12:14:09 -0700 >> From: The IESG <iesg-secretary@xxxxxxxx> >> Subject: Last Call: >> <draft-ietf-teas-applicability-actn-slicing-07.txt> (Applicability of >> Abstraction and Control of Traffic Engineered Networks (ACTN) to >> Network Slicing) to Informational RFC >> To: "IETF-Announce" <ietf-announce@xxxxxxxx> >> Cc: draft-ietf-teas-applicability-actn-slicing@xxxxxxxx, >> james.n.guichard@xxxxxxxxxxxxx, teas-chairs@xxxxxxxx, teas@xxxxxxxx, >> vbeeram@xxxxxxxxxxx >> Message-ID: <172193484951.1042453.12495308827630261210@dt-datatracker- >> 659f84ff76-9wqgv> >> Content-Type: text/plain; charset="utf-8" >> >> >> The IESG has received a request from the Traffic Engineering Architecture and >> Signaling WG (teas) to consider the following document: - 'Applicability of >> Abstraction and Control of Traffic Engineered >> Networks (ACTN) to Network Slicing' >> <draft-ietf-teas-applicability-actn-slicing-07.txt> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-call@xxxxxxxx mailing lists by 2024-08-08. Exceptionally, comments may >> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> Network abstraction is a technique that can be applied to a network >> domain to obtain a view of potential connectivity across the network >> by utilizing a set of policies to select network resources. >> >> Network slicing is an approach to network operations that builds on >> the concept of network abstraction to provide programmability, >> flexibility, and modularity. It may use techniques such as Software >> Defined Networking (SDN) and Network Function Virtualization (NFV) to >> create multiple logical or virtual networks, each tailored for a set >> of services that share the same set of requirements. >> >> Abstraction and Control of Traffic Engineered Networks (ACTN) is >> described in RFC 8453. It defines an SDN-based architecture that >> relies on the concept of network and service abstraction to detach >> network and service control from the underlying data plane. >> >> This document outlines the applicability of ACTN to network slicing >> in a Traffic Engineered (TE) network that utilizes IETF technologies. >> It also identifies the features of network slicing not currently >> within the scope of ACTN, and indicates where ACTN might be extended. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-teas-applicability-actn-slicing/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> IETF-Announce mailing list -- ietf-announce@xxxxxxxx >> To unsubscribe send an email to ietf-announce-leave@xxxxxxxx >> >> >> ------------------------------ >> >> End of IETF-Announce Digest, Vol 243, Issue 18 >> ********************************************** > -- > last-call mailing list -- last-call@xxxxxxxx > To unsubscribe send an email to last-call-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
