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
