| Internet-Draft | PQC escape | March 2025 |
| Li & Liu | Expires 3 September 2025 | [Page] |
In this contribution, a design of escape message mechanism is proposed, where the service provider sends an escape message to the service consumer using existing non-PQC connection and then starts to re-establish the quantum-safe protocol. The proposed escape message can potentially be used in a variety of protocols, including IPsec, TLS, or between the air interface of a cellpohone and a network device. We believe that for largely deployed networks and entities, escape messages can be provided as a plan B for legacy devices of the service provider and consumer that may not able to complete post-quantum migration in advance. It can mitigate negative migration impacts when potential Q-day occurs.¶
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 3 September 2025.¶
Copyright (c) 2025 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 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.¶
The post-quantum migration should be gradual in largely deployed networks and entities since one of the important feature of these networks such as telecom network is that a large number of legacy entities and devices have been deployed on the always-live network. The migration may cause complex effects in terms of confusing interfaces and reference point.¶
Considering the increased computational and payload burden of legacy equipment, many stakeholders may take risks and not be willing to embed a large number of equipments to complete the migration ahead of time. Considering billions of cellphones (aka., UE), hundreds of thousands of network entities, we propose to embed the post-quantum migration preparation gradually in advance, and to dynamically trigger and complete the post-quantum migration as required by extra messages and service mechanisms.¶
Therefore, regarding future quantum attacks (aka, Q-day attacks such as Shor's algorithm [shor]), one of the practical approaches is to notify entities to dynamically perform post-quantum migration using a new message, which we called the PQC escape message. The name was inspired by the history of the ESC key [ISO9995] in the keyboard, when ESC key is originally used for switching different mode of vi family [ESCKEY].¶
An PQC escape message should be sent in a proper procedure, for example, periodically or broadcast. In addition, except sending the escape message as a simply notification, it can also contain additional usage. It will be discussed in the session of the message design.¶
We believe that the need for escape messages exists widely in a variety of complex systems, not limit to largely deployed networks such as telecom networks. It is recommended to provide guidance of the format of the escape message.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The PQC escape message should be deployed between the service provider and the consumer. In general, the service provider and consumer are only concepts, multiple servers or consumers are also supported as long as having an established secure connection (e.g., IPsec [RFC4301], TLS [RFC8446], etc.).¶
+--------+ +---------+
| | | |
|Service | | Service |
|Consumer|<------------------------------------------->| Provider|
| | Communicate with current security | |
| | Connection (tls, ipsec, etc.) | |
+--------+ +---------+
Figure 1 System architecture applied escape message¶
The service consumer for example can be a UE, an APP client, a security gateway. The service provider for example can be a network function, an APP server, or a security gateway.¶
Escape messages should be designed to be as simple and efficient between service providers and consumers. Some requirements are listed as follows:¶
1. the message shall be dedicated for instruction to complete a live quantum migration. A dedicated message format helps the device identify the message rapidly. In term of the implementation level, the device can enter a dedicated migration mode to improve the success rate and shorten the response time.¶
2. the escape message shall contain a common security protection design including the integrity protection. This prevents attackers from sending false indications and causing the device to enter the migration state accidently.¶
3. the message shall be a standardized message format. A pre-shared key may be configured on both sides of the device to be migrated, which can be used for the protection of migration and a furtherly negotiation a post-quantum algorithm key. The sepcific format can be discussed in dedicated working group which are not in the scope of this docuement.¶
The pre-shared key can be either a dedicated pre-shared key. Optionally, it can also be the symmetric (pre-shared) key already used in the currently connection of TLS or IPsec, etc. Specifically, the following two mode can be used as options.¶
From the perspective of IETF PQUIP and this use case, the following analysis can be considered.¶
+----------+ +---------+
| | <---------------------------------------- | |
| | 1. Send Escape message | |
| | | |
| | ---------------------------------------> | |
| Consumer |2. Response Escape message and start migration| Service |
| | |Provider |
| | +--------------------------------------+ | |
| | | 3.Negotiate new security context | | |
| |---| to establish PQC secure connection |---| |
| | +--------------------------------------+ | |
+----------+ +---------+
Figure 2. Basic steps of escape message¶
The following steps shall be performed between consumer and service provider:¶
1. The service provider sends escape message to the consumer.¶
2. The consumer responses the escape message and starts to PQC migration.¶
3. The consumer and service provider negotiate the new PQC security context and to establish PQC security connection. There are several ways to negotiate with new PQC security context. For example, If the consumer and service provider have established an IPsec connection through traditional IKE [RFC7296], the multiple key exchanges of IKEv2 as defined in RFC 9370 [RFC9370] can be used to re-negotiate a new quantum-safe security key after receiving the escape message.¶
The consumer and service provider preconfigure the escape message. During the migration point (for example, service provider detected the quantum attack in Q-day, or as instructions of the system administrator). The service provider can send the escape message with above flows to consumer. Then, the consumer will response escape message to start the PQC migration. Finally, the consumer and the service provider shall start to negotiate new security context of including ML-KEM, ML-DSA or hybrid key exchanges, etc.¶
/*TODO¶
/*TODO¶
This document has no IANA considerations.¶
Escape messages are a compromise approach for dynamic PQC migration, usually it is expected after an attack has been discovered. It is still recommended that quantum migration should be performed in advance. Escape can be a plan B.¶
During the escape message procedure, Although basic steps can be implemented easily, it is worth to say that the key being used in non-PQC TLS or IPsec may already be leaked during the key exchange phase because of Q-day attacks. For example, assume that an attacker has captured the key during the establishement of non-PQC TLS or IPsec connection, and uses a quantum attack (e.g., Harvest Now, Decrypt Later" (HNDL) attack attack). In this case, the attacker can obtain the information and data in the connection, including subsequent escape messages and PQC security context negotiation content, which potential brings security risks.¶
/*TODO: Consideration of security enhancement when potential non quantum-safe keys already be leaked before triggering escape.¶
TODO¶