Export of TLS Handshake Information in IPFIX
draft-gao-opsawg-ipfix-term-and-app-02

opsawg                                                       X. Gao, Ed.
Internet-Draft                                                  S. Zhang
Intended status: Standards Track                            China Unicom
Expires: 16 November 2026                                         C. Lin
                                                    New H3C Technologies
                                                             15 May 2026

              Export of TLS Handshake Information in IPFIX
                 draft-gao-opsawg-ipfix-term-and-app-02

Abstract

   This document defines a set of new Information Elements (IEs) in the
   IPFIX Information Model for exporting raw TLS ClientHello handshake
   fields.  These IEs enable the collection of standardized client
   behavioral fingerprints from network traffic without decryption of
   the encrypted payload.  The exported fields facilitate network
   anomaly detection, threat identification, and fault diagnosis in
   encrypted traffic environments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Gao, et al.             Expires 16 November 2026                [Page 1]
Internet-Draft  Information Element for terminal and app        May 2026

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Sample Use Cases  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Problem Description . . . . . . . . . . . . . . . . . . .   3
     3.2.  Solution  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  New Information Elements  . . . . . . . . . . . . . . . . . .   4
     4.1.  tlsClientHelloSNI . . . . . . . . . . . . . . . . . . . .   4
     4.2.  tlsClientHelloVersion . . . . . . . . . . . . . . . . . .   5
     4.3.  tlsClientHelloCipherSuite . . . . . . . . . . . . . . . .   5
     4.4.  tlsClientHelloSSLExtension  . . . . . . . . . . . . . . .   5
     4.5.  tlsClientHelloEllipticCurve . . . . . . . . . . . . . . .   6
     4.6.  tlsClientHelloEllipticCurvePointFormat  . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     5.1.  Privacy and Sensitive Information Risks . . . . . . . . .   6
     5.2.  No Involvement of Traffic Decryption Operations . . . . .   7
     5.3.  Risk Control Against Misuse . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As encrypted transmission via TLS has become ubiquitous across all
   network traffic, the payload content of business communications is no
   longer visible.  The plaintext TLS ClientHello handshake fields have
   emerged as one of the few stable and exploitable analysis entry
   points in encrypted traffic.  Various types of malware, remote access
   trojans (RATs), ransomware, and DDoS attack tools all carry
   distinctive TLS client fingerprints, which serve as core identifiers
   for threat detection, attribution analysis, and forensic
   investigation in encrypted traffic scenarios.  Telecommunications
   operators, cloud service providers, and enterprise networks, when
   performing security operations such as anomaly detection, crawler
   identification, and attack attribution, urgently require
   standardized, interoperable, and comparable client fingerprinting
   features derived from the plaintext TLS ClientHello fields.

   Currently, TLS client fingerprint field export in the industry is
   predominantly implemented through proprietary vendor-specific
   solutions, which suffer from inconsistent data formats, divergent
   collection rules, and inability to perform collaborative parsing
   across devices.  To address these issues, it is necessary to define
   standardized specifications for core fingerprint fields within the

Gao, et al.             Expires 16 November 2026                [Page 2]
Internet-Draft  Information Element for terminal and app        May 2026

   IPFIX information model, so as to achieve unified collection,
   standardized export, universal parsing, and cross-domain comparison
   of fingerprinting features, thereby enhancing the compatibility and
   scalability of end-to-end security operations and situational
   awareness systems.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Sample Use Cases

3.1.  Problem Description

   Endpoints within home broadband networks, such as computers,
   smartphones, surveillance cameras, and routers, may, due to malware
   infection, firmware vulnerabilities, or unauthorized access,
   proactively initiate TLS connections to external suspicious servers
   without the user's awareness.  Such connections are typically
   employed for malware command and control, network scanning, or
   crawler access, representing a typical form of anomalous outbound
   traffic.  Due to TLS encryption, traditional traffic analysis methods
   are unable to identify client fingerprinting features.  The majority
   of malware, remote access tools, and crawler scripts utilize
   lightweight TLS libraries, whose handshake characteristics differ
   significantly from standard browsers.  By evaluating TLS handshake
   characteristics, it becomes possible to determine whether a
   connection originates from an anomalous client, thereby enabling
   precise detection and remediation.

3.2.  Solution

   By deploying IPFIX-based traffic collection and analysis capabilities
   on critical network gateways and boundary devices such as telecom
   operator residential broadband BRAS (Broadband Remote Access Server),
   cloud gateways, enterprise egress routers, and backbone network
   monitoring points, the system extracts key TLS client fingerprint
   characteristic fields losslessly from TLS handshake packets.  This
   enables feature export and centralized reporting without traffic
   decryption.  Through traffic collection and analysis platforms,
   fingerprint modeling, whitelist comparison, and anomalous feature
   analysis are performed, thereby achieving behavior identification and
   operational closed-loop remediation for encrypted traffic anomalous
   outbound connections, malware, remote access tools, crawlers, and

Gao, et al.             Expires 16 November 2026                [Page 3]
Internet-Draft  Information Element for terminal and app        May 2026

   similar threats.

   +-------------+  +------------+    +-------------+    +-------------+
   |   Vendor-A  |  |  Vendor-B  |    | Vendor-C    |    | Vendor-N    | 
   |    device   |  |   device   |    |  device     |... |   device    |  
   +-------------+  +------------+    +-------------+    +-------------+
          |                |               |                 |
          +----------------+---------------+-----------------+
                                   | IPFIX 
                                   v
       +-------------------------------------------------------+
        |                    Unified Collector                |
        |              +-------------------------+            | 
        |              |     TLS Field Parser    |            |
        |              |    Fingerprint Engine   |            |
        |              |   Fingerprint Database  |            |
        |              +-------------------------+            |
       +—------------------------------------------------------+ 
          Figure 1.   IPFIX-Based Unified TLS Fingerprint Collection

   The TLS field parser is responsible for parsing and extracting key
   TLS handshake field information from IPFIX exported elements.  The
   fingerprint engine performs the modeling and construction of client
   fingerprints based on raw TLS handshake field data collected via
   IPFIX.  The characteristic fingerprint database is a database used
   for the standardized storage of various known and identifiable
   feature sets，the system performs real-time comparison and matching of
   the collected and generated client fingerprints against the
   characteristic fingerprint database.

4.  New Information Elements

4.1.  tlsClientHelloSNI

   ElementID: TBD

   Name: tlsClientHelloSNI

   Abstract Data Type: string

   Data Type Semantics: identifier

   Description：The value of the Server Name Indication (SNI) extension
   in the TLS ClientHello message, which specifies the target server
   hostname (encoded in UTF - 8) as defined in Section 3 of RFC 6066 and
   used for certificate selection in multi - domain hosting
   scenarios.The Server Name Indication (SNI) extension enables a TLS
   client to indicate the name of the server it is attempting to connect
   to.This mechanism facilitates secure connections to servers hosting
   multiple virtual servers on a single network address.

   Reference：See RFC 6066 section 3 for the specification of Server Name
   Indication.

Gao, et al.             Expires 16 November 2026                [Page 4]
Internet-Draft  Information Element for terminal and app        May 2026

4.2.  tlsClientHelloVersion

   ElementID: TBD

   Name: tlsClientHelloVersion

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Description：The TLS protocol version number negotiated during the
   handshake and used in the TLS record layer header, encoded as a
   2-byte unsigned integer (e.g., 0x0304 for TLS 1.3) as defined in RFC
   8446 and RFC 5246.

   Reference：RFC 8446,RFC 5246

4.3.  tlsClientHelloCipherSuite

   ElementID: TBD

   Name: tlsClientHelloCipherSuite

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Description：A list of cipher suite values (each 2-byte unsigned
   integer) advertised by the client in the TLS ClientHello message.

   Reference：RFC 8446

4.4.  tlsClientHelloSSLExtension

   ElementID: TBD

   Name: tlsClientHelloSSLExtension

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Description：A list of TLS extension type codes (each 2-byte unsigned
   integer) from the ClientHello extensions field.

   Reference：RFC 8446

Gao, et al.             Expires 16 November 2026                [Page 5]
Internet-Draft  Information Element for terminal and app        May 2026

4.5.  tlsClientHelloEllipticCurve

   ElementID: TBD

   Name:tlsClientHelloEllipticCurve

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Description：A list of elliptic curve identifiers (each 2-byte
   unsigned integer) from the "elliptic_curves" extension in
   ClientHello.

   Reference：RFC 8446

4.6.  tlsClientHelloEllipticCurvePointFormat

   ElementID: TBD

   Name: tlsClientHelloEllipticCurvePointFormat

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Description：A list of elliptic curve point format identifiers (each
   1-byte unsigned integer) from the "elliptic_curves_point_formats"
   extension in ClientHello.

   Reference：RFC 8446

5.  Security Considerations

5.1.  Privacy and Sensitive Information Risks

   All fields defined in this document do not carry or process any user-
   sensitive information.  They solely represent client software
   implementation characteristics and TLS cipher suite configuration
   features, and cannot independently be used to identify natural
   persons.  These fingerprints are not uniquely bound to specific
   users, do not constitute personally identifiable information, and are
   not used for scenarios such as user behavior analysis or individual
   user identification.  This mechanism solely achieves network
   anomalous traffic identification through fingerprint feature
   comparison, and does not introduce any risk of privacy leakage.

Gao, et al.             Expires 16 November 2026                [Page 6]
Internet-Draft  Information Element for terminal and app        May 2026

5.2.  No Involvement of Traffic Decryption Operations

   All exportable metadata fields specified in this document are solely
   derived from the TLS plaintext handshake phase.  The data collection
   and processing workflow of this solution does not perform decryption,
   parsing, or storage of user encrypted communications.  Only publicly
   available handshake metadata is collected, without accessing the
   user-encrypted business data in transit.  Such transport layer
   behavioral characteristics have abundant mature application
   precedents in the IETF standards ecosystem, and are consistent with
   the application paradigm of traditional transport layer metadata
   mechanisms such as TCP options.

5.3.  Risk Control Against Misuse

   To prevent improper use or malicious abuse of the TLS fingerprint
   fields defined in this document, the following constraints and
   principles shall be strictly observed during the deployment and
   application of this mechanism:

   Legitimate use restrictions: This mechanism shall only be used for
   compliant network management scenarios, including but not limited to
   network operations, anomalous traffic detection, network fault
   troubleshooting, DDoS attack mitigation, and other legitimate
   business purposes.

   Prohibition of non-compliant use: This mechanism shall be strictly
   prohibited from being used in unauthorized, non-network-management
   scenarios such as cross-domain user tracking, user profiling, or
   individual behavior monitoring.

   Transmission access control: For TLS fingerprint data transmission
   based on the IPFIX protocol, communication privileges between
   collectors and exporters shall be restricted through mechanisms such
   as Access Control Lists (ACL) and authentication, so as to ensure
   transmission security.

   Data minimization: All collected traffic feature data shall strictly
   adhere to the data minimization principle.  Long-term storage of
   redundant or irrelevant traffic feature data is prohibited, so as to
   minimize potential security risks.

6.  IANA Considerations

   The document makes a request to IANA to register the Information
   Elements defined in section 4.

Gao, et al.             Expires 16 November 2026                [Page 7]
Internet-Draft  Information Element for terminal and app        May 2026

Authors' Addresses

   Xing Gao (editor)
   China Unicom
   Beijing
   China
   Email: gaox60@chinaunicom.cn

   Shuai Zhang
   China Unicom
   Beijing
   China
   Email: zhangs366@chinaunicom.cn

   Changwang Lin
   New H3C Technologies
   Beijing
   China
   Email: linchangwang.04414@h3c.com

Gao, et al.             Expires 16 November 2026                [Page 8]