TDoc: S4-260024

1) Technical Accuracy

Scenario 1 (Roaming S8HR/N9HR): “LI implies these interfaces should not be confidentiality protected”

• Questionable / likely incorrect framing. LI requirements do not generally imply that roaming interfaces (S8HR/N9HR) “should not be confidentiality protected.” 3GPP LI is typically realized via network-internal interception functions and handover interfaces (HI), not by mandating plaintext on service interfaces.


• If SA2 suggested “make traffic visible to VPLMN by removing encryption,” SA3 is right to flag it as problematic, but SA3’s wording risks implying that LI requires no confidentiality protection on those interfaces. That is not a safe or accurate generalization.


• Missing distinction between “interceptability” and “decryptability.” LI can be satisfied by delivering IRI/CC from an entity that legitimately terminates security (or has access to keys under lawful authorization), rather than forcing “no encryption” on the bearer.

“VPLMN could access DC content copy … using DTLS 1.2 with NULL cipher”

• Technically dubious as a practical proposal.


• DTLS 1.2 does define NULL cipher suites, but real-world stacks often disable them, and many security policies prohibit negotiating NULL. Even if “possible,” it is operationally unrealistic and would be non-compliant with common security baselines.


• More importantly: if the IMS Data Channel is end-to-end protected between UE and some home-network function, the VPLMN cannot simply “choose” NULL cipher unless it is a DTLS endpoint (i.e., terminating DTLS). If VPLMN is not the DTLS endpoint, cipher choice is irrelevant.


• DTLS 1.3 statement needs specification anchoring. It is broadly correct that DTLS 1.3 removes NULL cipher suites, but the document should cite the relevant IETF RFC(s) and the 3GPP normative references that mandate/recommend DTLS versions for IMS Data Channel (if any).

“DTLS 1.3 is recommended from Rel-19 onwards”

• Potentially inaccurate / at least unsupported in this summary. 3GPP does not “recommend DTLS1.3 from Rel-19 onwards” in a vacuum; it depends on the specific feature/spec. If SA3 is making a normative direction claim, it must be backed by:


• the exact 3GPP spec(s) and clause(s) where DTLS versioning is specified for IMS Data Channel, and


• whether it is a “shall”/“should”/informative recommendation.


• As written, it reads like a policy statement rather than a spec-grounded fact.

“Security downgrade must be applied to all HPLMN UEs to avoid LI detectability”

• Overstated and not rigorously justified.


• LI “undetectability” requirements exist in many jurisdictions, but the conclusion that all HPLMN UEs must be downgraded is not necessarily true. There are alternative approaches (e.g., lawful key access, network termination points, targeted duplication at trusted functions) that do not require global downgrade.


• If the argument is “targeted downgrade is detectable by the target,” that needs a threat model and evidence (what signals are observable to the UE? handshake parameters? cipher suite list? certificate chains?).

“Conflicts with regulatory requirements (e.g., EU Cyber Resilience Act)”

• Risk of being misleading.


• The EU CRA is not a simple “must encrypt data in transit by default” rule in the way stated here; it is broader product security regulation with essential requirements. The document should be careful not to assert a specific legal obligation without precise citation and interpretation.


• Also, 3GPP generally avoids making strong legal compliance claims without careful wording. This should be framed as “may create compliance challenges” rather than a definitive conflict, unless SA3 has legal analysis.

2) Completeness

Missing normative references and clause-level grounding

The summary lacks:

- Exact spec references for IMS Data Channel security architecture (e.g., where DTLS is specified, endpoints, cipher requirements).

- LI architecture references (TS 33.107/33.108, and any IMS-specific LI specs such as TS 33.108 annexes or relevant SA3-LI outputs). The document should explicitly map the scenarios to LI requirements: IRI, CC, and where interception points are expected.

Missing analysis of alternative LI-compliant architectures

Scenario 1 focuses on “NULL cipher / no confidentiality” as the implied solution and rejects it. What’s missing:

- Options such as anchoring/termination in a trusted network function (home or visited) that can lawfully provide CC.

- Key escrow / lawful key access models (even if controversial) should be mentioned as possibilities and then rejected with rationale if SA3 opposes them.

- Split interception (IRI in VPLMN, CC in HPLMN) and how that meets regulatory needs in roaming.

Missing threat model and detectability analysis

Claims about detectability and downgrade need:

- What the UE can observe (DTLS handshake, cipher suite negotiation, ALPN, certificate, fingerprinting).

- Whether “undetectability” is a requirement in the relevant LI requirements baseline for this feature.

Scenario 2: insufficient technical detail

• The “DC Application Proxy” applicability question is good, but incomplete:


• What is the exact TS 23.228 text being referenced?


• What is the call flow for UE-initiated P2P DC in each proxy mode?


• Where is MF located (home/visited), and what are the trust boundaries?

Scenario 3: acceptance of “no gaps” is weak

• SA3’s “will not explore further” is not robust. Even if SA2 sees no gaps, SA3 should at least:


• sanity-check LI coverage for interworking conversions (DC ↔ RTP video, DC ↔ SMS/HTTP) and whether CC remains meaningful (content transformation, loss of metadata, timing).


• confirm whether existing LI specs cover new identifiers (DC session IDs, MF anchoring identifiers, DTLS fingerprints, etc.).

3) Impact Assessment

On security posture and interoperability

• If any solution implies weakening DTLS (NULL cipher or forced downgrade), the impact is severe:


• breaks modern security baselines,


• likely breaks interoperability with implementations that disallow NULL,


• creates a long-term maintenance and compliance burden.

On existing IMS/DC implementations

• If the proposal (or SA2’s implied approach) requires VPLMN access to plaintext, it may require:


• architectural changes (visited network termination of DTLS, new trust relationships, new keying models),


• updates to MF/DC AS behavior,


• potential changes in UE behavior (cipher suite support, negotiation constraints).

On LI specifications and handover interfaces

• Any new interception point (MF/DC AS) may require:


• new or updated IRI/CC definitions,


• correlation identifiers for DC sessions,


• clarification of where CC is produced (visited vs home) in roaming.

4) Feasibility

DTLS NULL cipher approach

• Low feasibility:


• often disabled in libraries,


• unacceptable to security certification regimes,


• incompatible with DTLS 1.3 direction,


• operationally fragile (middleboxes, policy enforcement, audits).

“Apply downgrade to all HPLMN UEs”

• Not feasible operationally:


• massive blast radius,


• unacceptable user/security impact,


• likely to be rejected by operators and regulators focused on cybersecurity.

Proxy-mode anchoring for LI (Scenario 2)

• Feasible in principle, but needs:


• clear normative permission in architecture specs (TS 23.228 and related),


• clear definition of when MF may anchor UE-initiated P2P,


• performance/latency considerations and scaling impact.

5) Weaknesses

• Over-reliance on a strawman solution (NULL cipher / no confidentiality) without systematically evaluating other LI mechanisms.


• Insufficient specification grounding: multiple claims (“DTLS1.3 recommended from Rel-19”, “TS 23.228 says…”) are not backed by clause references.


• Legal/regulatory assertions are too strong and not properly cited; risks undermining credibility in 3GPP.


• Scenario 3 is prematurely dismissed; SA3 should independently validate LI completeness for interworking and content transformation.


• No clear recommendation: SA3 flags concerns but does not propose a concrete path forward for SA2/SA3-LI.

6) Suggestions for Improvement

A) Add precise references and tighten wording

• Cite:


• the exact clauses in TS 23.228 regarding DC Application Proxy applicability and session initiation conditions,


• the IMS Data Channel security spec(s) that define DTLS usage and versioning,


• LI baseline specs (TS 33.107/33.108) and any IMS/DC-specific LI requirements.


• Replace “LI implies interfaces should not be confidentiality protected” with a more accurate statement, e.g.:


• “Some LI deployment models may seek access to plaintext in the visited network; this conflicts with end-to-end protection assumptions.”

B) Provide an explicit options analysis for Scenario 1

Include at least 3–4 candidate approaches with pros/cons:

1. Home-network interception only (CC produced in HPLMN; VPLMN provides IRI and routing info).

2. Visited-network anchoring/termination (MF in VPLMN terminates DTLS under defined trust model).

3. Lawful key access (if considered at all—likely controversial; document why it is/ isn’t acceptable).

4. Service restriction in roaming (if LI cannot be met without weakening security, consider policy-based disablement of DC in certain roaming cases—again, controversial but should be analyzed).

C) Clarify the threat model and “undetectability” requirement

• State whether LI undetectability is a requirement for this feature in 3GPP scope or jurisdictional.


• If claiming detectability, explain what the UE can observe and why targeted changes are detectable.

D) Strengthen Scenario 2 with concrete call flows

• Provide call flows for:


• UE-initiated P2P DC in HTTP Proxy / DC App Proxy / UDP Proxy modes,


• where DTLS terminates,


• where CC can be generated.


• If SA3 believes TS 23.228 restricts DC App Proxy to network-initiated sessions, propose:


• a spec change request (CR) to extend applicability, or


• a clear statement that LI cannot be met for UE-initiated P2P under that mode.

E) Do not dismiss Scenario 3 without validation

• At minimum, add a checklist:


• identifiers available for correlation,


• whether CC content is preserved after interworking,


• whether MF/DC AS becomes an interception point requiring new LI definitions.

F) Reframe regulatory discussion

• Replace definitive legal conflict statements with:


• “may create compliance challenges with emerging cybersecurity regulations and operator security policies,”


• and cite sources carefully (or move to informative annex / liaison note with cautious language).

Bottom line

The document correctly flags that “weakening encryption to satisfy LI” is problematic, but it is not sufficiently rigorous or complete: it lacks normative references, overstates some claims (DTLS versioning, “interfaces should not be protected,” “must downgrade all UEs”), and does not provide a structured set of feasible alternatives. Strengthening the contribution requires clause-level grounding, explicit architectural options, and concrete call flows—especially for roaming and UE-initiated P2P cases.