[Teas] The SSLKEYLOGFILE Format for TLS

[Thomas Lußnig <[e-mail]>]

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<[e-mail]>
> Subject: Document Action: 'The SSLKEYLOGFILE Format for TLS' to
> 	Informational RFC (draft-ietf-tls-keylogfile-02.txt)
> To: "IETF-Announce"<[e-mail]>
> Cc: The IESG<[e-mail]>,[e-mail],
> 	[e-mail],[e-mail],[e-mail],
> 	[e-mail]
> 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<[e-mail]>
> 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"<[e-mail]>
> Cc:[e-mail],
> 	[e-mail],[e-mail],[e-mail],
> 	[e-mail]
> 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
> [e-mail]  mailing lists by 2024-08-08. Exceptionally, comments may
> be sent [e-mail]  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 [e-mail]
> To unsubscribe send an email [e-mail]
>
>
> ------------------------------
>
> End of IETF-Announce Digest, Vol 243, Issue 18
> **********************************************