Quantum Relief with TLS and KerberosInternetWide.orgHaarlebrink 5EnschedeOverijssel7544 WPThe Netherlandsrick@openfortress.nlInternetWide.orgImstenrade 24EindhovenNoord-Brabant5655 BNThe Netherlandstom.vrancken@arpa2.orgThis specification describes a mechanism to use Kerberos
authentication within the TLS protocol. This gives users of TLS a
strong alternative to classic PKI-based authentication, and at the same time
introduces a way to insert entropy into TLS' key schedule such that
the resulting protocol becomes resistant against attacks from quantum
computers. We call this Quantum Relief, and specify it as part of a more
general framework to make it easier for other technologies to achieve
similar benefits.TLS protects many application protocols from many security problems. To
enable this, it habitually relies on public-key cryptography. But in the
foreseeable future, quantum computers are expected to destroy these public-key
underpinnings. This endangers TLS, because encrypted data may be captured and stored, ready for decryption as soon as quantum computers hit the playing field.With present-day applications of TLS threatened by quantum computers, some may not be able to live up to user's legal requirements for long-term encryption. There even is a risk of future power imbalances between those who have a quantum computer and those who have not.One solution is to not rely solely on public-key cryptography, but instead mix in secret entropy that a future quantum computing entity cannot decipher. In this light, Kerberos offers an interesting perspective, as it builds a symmetric-key infrastructure including cross-realm connectivity options. Kerberos is considered safe from quantum computers, as long as its public-key extensions are avoided.Herein, we specify a TLS extension called "quantum_relief" [] that facilitates mixing in secret entropy
from another source into the TLS key computations. Additionally, we define a concrete mechanism
that provides (1) a source of secret entropy and (2) an alternative authentication mechanism. This mechanism, which
relies on Kerberos for relief against quantum computing and on
(Elliptic-Curve) Diffie-Hellman for Perfect Forward Secrecy (and to stop the
sphere of influence of the KDC administrator), shall be referred to as Kerberised Diffie-Hellman or KDH []. A definition is included for a KDH-Only Application Profile, to facilitate small and simple implementations.The PSK mechanism in TLS 1.3 and 1.2 allows insertion of key material, which is referenced by name alone, into the key schedule. A naming system is defined, but its interpretation resides under local policy, which is enough for internal use cases, but it is insufficient for general use between any two parties.Cryptographically however, the entropy from the PSK mechanism in TLS 1.3 is
secret to external observers, and mixed with the DHE material using a series of
HKDF-Extract and -Expand operations []. When used on their own, the DHE material can be reversed by quantum computers and any subsequent HKDF computations redone, uncovering the complete key schedule of TLS. The extra source of entropy inserted for a PSK however, will have to be uncovered separately, and this will not be possible in the general case.This specification exploits this entropy insertion possibilities by
defining a generic TLS extension called "quantum_relief". The "quantum_relief" extension
replaces the locally useful PSK scheme with a generally usable mechanism for
the insertion of secret entropy into the TLS 1.3 key schedule at the position
otherwise used by the PSK. While enabling relief against quantum computer attacks,
this mechanism, however, sacrifices support for 0-RTT data in TLS 1.3.
For TLS 1.2, an extension to the computation of the master secret
inserts the extra entropy.In order to provide sufficient Quantum Relief, the added entropy must meet
the following conditions:
The amount of entropy must on its own suffice for the desired security level of the TLS connection.The entropy should only be known to parties that are not expected to operate a quantum computer (for example because they are nearby, contractually bound, or otherwise within batting range).Only quantum-proof mechanisms should be used for the generation of the entropy.In terms of algorithms that are commonplace today, the third requirement is generally believed to be met by secure hashes and symmetric encryption. The problem with these is sharing random information secretely and at the same time controlling who has access to these secrets.Besides the customary client-to-server flow there is also support for a peer-to-peer flow under Quantum Relief. When this is used, the ClientHello sent to a TLS server by an initiating peer holds a peernametype other than "none" followed by a corresponding name for the designated peer.Without documenting it here, the TLS server is assumed to have some method of designating a peer with this information, and will proxies the TLS connection to its peer. The TLS server is not involved in cryptographic computations for the relayed TLS connection; its only task is to relay TLS data from the client to the designated peer and vice versa.This section defines a new TLS extension called "quantum_relief" that
enables relief against quantum computer attacks for TLS as defined in .
The extension is designed such that it can be applied generically. Its purpose is to
Negotiate a concrete Quantum Relief mechanism / methodInitiate / execute the negotiated methodInject the secret entropy, which is produced by the negotiated Quantum Relief method, into the TLS key scheduleA concrete Quantum Relief method that leverages this "quantum_relief" extension is TLS-KDH,
which is defined in . Future mechanisms may be added by extending
the data structures defined for the "quantum_relief" extension.In order to distinguish between different Quantum Relief methods, a
QuantumReliefMethod tag is defined. Every (future) method must be assigned
a unique identifier in order to be able to deterministically negotiate a
Quantum Relief method between client and server.A TLS ClientHello can additionally specify a name for a peer that it
wants to respond, for which various application-independent forms may be anticipated.
This is captured in yet another tag called PeerNameType.The value "none" in both tags is defined as default value and signifies no use of a Quantum Relief method or alternative peer name respectively.
They are used for regular client-to-server TLS connections. Additional values and
their corresponding data structures may be defined by concrete Quantum Relief mechanisms.The "quantum_relief" extension structure is now defined as follows:This structure is used as extension_data corresponding to the
"quantum_relief"(TBD:QREXTTYPE) extension_type,
to occur only during ClientHello and ServerHello.When negotiating a Quantum Relief method and a peer name type, the following rules must
be followed.A TLS client MUST only advertise a Quantum Relief method that it is capable of and willing
to perform. The default Quantum Relief method is none(0) and in that case the "quantum_relief"
extension MUST NOT be sent. In case another Quantum Relief method is set, the client
SHOULD wait with the execution of this method until it receives a method confirmation from
the server in the ServerHello. In case the server sends no confirmation or replies with a different
Quantum Relief method than was advertised, no Quantum Relief method MUST be executed. In that case,
the client MAY decide to either continue or abort the handshake.A TLS server MUST only accept a Quantum Relief method that it is capable of and willing to perform.
In case a server accepts the method that was advertised by the client, it MAY initiate the execution of
this method. When it does, it MUST confirm this method to the client in its ServerHello message.
Furthermore, it MUST NOT make any PSK references.
In case a server does not accept the method that was advertised by the client, it MUST refrain from
sending this extension.A TLS client MUST only set a peer name type and corresponding peer name specification if the client
wishes to address a peer other than the TLS server. How this peer name should be interpreted and processed
is up to the negotiated Quantum Relief method.A TLS server MUST confirm the peer name type to the client in its ServerHello if the server is able to,
and going to process the provided peer name. A server MUST never set a peer name specification itself.When a ClientHello message contains the "quantum_relief" extension, it
MUST NOT include any references to a PSK. It MAY independently negotiate
client and server certificate types and
cipher suites.This section defines a mechanism called TLS-KDH. TLS-KDH is a mode of using TLS that was designed to provide two things:
An alternative to PKIX credentials in TLS Quantum Relief for TLS connectionsThe key derivation mechanisms in Kerberos are helpful in a Quantum Relief mechanism; locally controlled secrets are gradually adapted to more specific uses in a non-reversible manner. The various uses cannot use one token to derive another, whether it is for TLS-KDH or another secure service.To achieve Quantum Relief, (external) secret entropy needs to be generated and inserted into the TLS key schedule.
In the TLS 1.3 key schedule, the "quantum_relief" extension inserts this entropy at the position where normally the PSK is input;
The two extensions (i.e., "quantum_relief" and PSK) are not considered useful when combined.
In TLS 1.2, a similar result is achieved by enhancing the pre-master secret independently of the negotiated cipher suite.In addition to Quantum Relief, TLS-KDH can offer authentication based on
Kerberos tickets. This introduces new facilities into TLS, such as deferred
authentication, anonymous realm users, and centralised facilitation of realm
crossover.The flow of TLS 1.3 works best when encryption is provided early, and
authentication is provided late. These aspects are often combined in Kerberos,
but KDH splits them to resemble TLS patterns more closely,
offering separate Kerberos-based protocol fragments for (1) additional secret entropy for encryption, (2) client authentication through Kerberos Tickets and (3) server authentication through Kerberos Tickets. Only (1) provides Quantum Relief. When (2) is used without (1), Quantum Relief is not achieved.The TLS-KDH mechanism
uses ClientHello and ServerHello for a Kerberos-protected exchange of entropy,
but it completely ignores the client identity during this phase. This allows clients to use an anonymous Ticket in the ClientHello message and consider authenticating with an identifying Ticket in later client Certificate and CertificateVerify messages.Server identity however, is observed in all Tickets, so any use of the Ticket’s contained key by the server suffices as proof of its identity. This renders the server Certificate and CertificateVerify messages redundant if the server accepts the KDH method for authentication, especially in TLS 1.3 because the Finished message follows immediately. But redundancy can be a feature; it is certainly legitimate to also authenticate the server with an explicit Kerberos Ticket, a PKIX certificate or other form.When the server desires proof of client identity, it sends a CertificateRequest. KDH introduces a certificate type for a Kerberos Ticket, relying on a Kerberos Authenticator as CertificateVerify message. The server is also able to use this to prove being able to use a supplied Ticket with its identity.TLS-KDH also supports a peer-to-peer flow. Here, instead of sending a regular Ticket, a client sends a Ticket Granting Ticket (TGT) to the server. The server then acts
as a proxy that relays TLS traffic to the destined peer and back. The initiating peer (i.e., the client) MAY use an anonymous name for itself in the TGT.Through the server, the designated peer returns a ServerHello with a Ticket based on this TGT, obtained through the user-to-user flow of Kerberos . This returned Ticket will reverse the client and server roles for Kerberos compared to TLS, but for peer-to-peer connectivity that is not an issue. The designated peer will authenticate itself to the initiating peer through its use of this returned Ticket and it can decide whether authentication of the initiating client is desired.If the TLS client authenticates through a Kerberos Ticket, it uses the designated peer name as the service name and its own name as the client name, in line with the TLS roles for client and server.Whether a Ticket is supplied in the ClientHello or returned by a designated peer
in the ServerHello, it yields a key only known to the two connecting parties. This key is applied to the concatenated random data from ClientHello and ServerHello to derive a new secret. This means that both parties influence the entropy gathered and can derive a sequence of bytes that is unknown to anyone else. The output from the encryption operation is plugged into the key schedule instead of the PSK input parameter. This input is suited for entropy of arbitrary size.This section describes the data structures and procedures that are
introduced by the TLS-KDH mechanism.TLS-KDH defines a concrete Quantum Relief method for the "quantum_relief" extension that is
defined in . The necessary data type extensions are defined here.The QuantumReliefMethod type is extended with the value "kdh" that is used to identify the TLS-KDH method of Quantum Relief defined
herein.In these two types, the value "none" is used for regular client-to-server TLS connections. The value "krb5princrealm" is used in a ClientHello to indicate a Kerberos PrincipalName and Realm [Section 5.2.2 of ] for the designated peer sought behind the TLS server in peer-to-peer TLS connections.The "quantum_relief" extension with support for the KDH method is now defined as follows:;
}
PeerNameType peernametype;
select (peernametype) {
case none:
/* No peer name type */
Empty;
case krb5princrealm:
/* PrincipalName and Realm, resp. */
struct {
opaque krb5princ<3..1023>;
opaque krb5realm<3..1023>;
} krb5PrincipalRealm;
}
} QuantumRelief;
]]>This section describes the procedure for encryption based on Kerberos primitives. The procedure is referenced in other sections, for proofs and as a source of entropy.The TLS-KDH messages and cryptographic computations require Kerberos through their use of the key concealed in a Ticket. The defined function below produces a binary object that cryptographically binds its input to the key.Not shown in the procedure, there is a need to decrypt the enc-part of the Ticket before the key concealed in it can be extracted. This is where proof of identity comes into play; only the two parties connected by the Ticket should be able to perform this decryption.The name prefix "rfc3961" points to the generic descriptions for Kerberos
key-based procedures that are implemented with various
algorithms. Available algorithms are listed in the IANA Registry of Kerberos
Parameters.The Key Usage values are numbers, for which the following are defined by this specification. Their number ranges are deliberately chosen to not clash with those of Kerberos, but otherwise compliant to the application range [Section 7.5.1 of ]. The Key Usage values are referenced by name elsewhere in this specification.Where this text speaks of a TGT, short for Ticket Granting Ticket, it imposes the following requirements to the PrincipalName [Section 5.2.2 of ] in the sname field of a Ticket:
The name-type is set to NT-SRV-INST or 2The name-string consists of two component stringsThe first name-string component string is the fixed string krbtgtTo be a TGT, all these requirements MUST be met by a Ticket; a Ticket that should be a TGT but does not meet all these conditions is badly formed and the recipient MUST respond to it by reporting error bad_certificate and closing the connection.In order to be able to negotiate Kerberos Tickets as certificate types for
the Certificate messages, a new certifcate type is introduced that can be used
in the "client_certificate_type" and "server_certificate_type" extensions:
Kerberos Ticket (TBD:KRBTKT-CERTTP)Although TLS-KDH does not introduce any new messages for TLS, there are
however a few modifications to the contents or the manner of processing of existing messages. Unless specified otherwise, the modifications apply to TLS 1.3 and 1.2 alike.When this message contains the "quantum_relief" extension, its
"qr_method" MUST be set to "kdh" under this specification. Further
requirements to this extension depend on the pattern of use being
client-to-server [] or peer-to-peer [].To initiate client-to-server traffic, the "peernametype" MUST be set to "none", and the "opt_ticket" MUST be a Ticket with the service name, host or domain name, and Kerberos realm of the addressed service. The client name in the "opt_ticket" MAY be an anonymous identity and the server MUST ignore the client identity in the "opt_ticket". When the "server_name" extension is also sent, there SHOULD be restrictions enforced by the server on its relation with the service name in the "opt_ticket", but this may involve domain-to-hostname mappings, for instance through DNS SRV records under DNSSEC protection.To initiate peer-to-peer traffic that could be proxied through the TLS
server to end at a designated peer, the "peernametype" MUST NOT be set to "none",
and the "opt_ticket" MUST be a TGT for the TLS client, suited for the ticket
granting service of the TLS server’s realm; it is permitted for the client to
use an anonymous identity in this TGT and both the server and the designated peer MUST ignore the client
identity in the "opt_ticket". When the "peernametype" is set to "krb5princrealm", the "krb5princ" and "krb5realm" fields MUST be set to the Kerberos PrincipalName and Realm for the designated peer. Future extensions may introduce alternative forms of designated peer identities and a TLS server SHOULD be open to the general idea of identity.This specification defines a response to ClientHello extensions with "qr_method" set to "kdh",
for which the accepting ServerHello extension MUST also be set to "kdh".When the ClientHello extension had its "peernametype" set to "none", the
ServerHello extension responds to a client-to-server connection request. The
TLS data will be processed on the server and the response extension MUST set the "opt_ticket" field to a zero-length byte string representing an empty ticket field (i.e., no ticket).When the ClientHello extension had its "peernametype" set to another value than "none", then the TLS server SHOULD use this to locate a designated peer, which may have registered through a mechanism not specified herein, and proxy the TLS traffic to this designated peer. The TLS server continues to proxy TLS traffic until the connection closes. When such peer-to-peer connectivity is not supported by a TLS server or when the peer name could not be resolved to a designated peer or when the designated peer is unresponsible, the TLS server MUST send a handshake_failure alert and close the connection.When a designated peer, possibly after out-of-band registration with a TLS server as a
recipient for peer-to-peer TLS connections, receives a ClientHello with a
"quantum_relief" extension with "qr_method" set to "kdh", a
"peernametype" and "peername" that it recognises as its own, and with a TGT in
the "opt_ticket" field, it SHOULD engage in a user-to-user ticket request with
the ticket granting service for its realm. It MUST reject the connection if
this procedure fails. When a Ticket is obtained, it constructs a ServerHello
with a "quantum_relief" extension, sets "qr_method" to "kdh",
"peernametype" to "none", and "opt_ticket" to the just-obtained Ticket. Furthermore, it continues to act as though the client had contacted it directly, while being forgiving to the proxied nature of the connection that carries the TLS traffic. There are no grounds for assuming anything about the client identity.Since client identity is ignored by the server or designated peer during ClientHello and
ServerHello, and may indeed be toned down to an anonymous identity, a
server-side requiring to know its client MAY send a CertificateRequest in order
to verify the client's identity.When using KDH without server certificate, the server MUST send a CertificateRequest with
which it requests a Kerberos Ticket from the client in order to mutually authenticate each other.
If the client does not provide such a ticket, authentication can not take place and the handshake
MUST be aborted. Note that the client is still allowed to provide an anonymous ticket. This may,
however, result in authentication being rejected by the server.When using KDH with server certificate, the server SHOULD send a CertificateRequest to
request for a ticket with which the (regular) server authentication (e.g., X.509) can be enhanced.
The client MAY decline this offer and it is up to the server whether to accept this or not.In order to be able to request a Kerberos Ticket during the handshake, the Kerberos Ticket (TBD:KRBTKT-CERTTP) certificate
type must be negotiated via the client_certificate_type extension . If a client_certificate_type was
negotiated then CertificateRequest MUST be sent. When permitted by the TLS 1.3 client with the post_handshake_auth extension,
this MAY also be sent at any later time. Under TLS 1.2, TLS renegotiation permits a similar facility.The Certificate and CertificateVerify messages are not always required,
because (1) the "quantum_relief" extension captures the server identity, and (2) proof thereof is deferred to Finished, which under TLS 1.3 is available to the client before it sends the client Certificate. Even in cases when it is not strictly required, a server MAY opt for sending server Certificate and CertificateVerify.The "server_certificate_type" extension may be used to negotiate any
supported type for these messages, including the Kerberos Ticket certificate
type defined herein. When not negotiated, the default type is a PKIX certificate . Note
that a server cannot initiate a Kerberos exchange, so a Kerberos type cannot be
used when the client did not send (or the server rejected) a "quantum_relief" extension or when the
extension did not provide a Ticket or TGT such as it does when the "qr_method" is "kdh".Under TLS 1.3, the server can request client authentication by sending a
CertificateRequest message. It is possible for servers to do this at any time (provided that the client has sent the "post_handshake_auth" extension), and possibly multiple times; TLS 1.3 even defines how to handle overlapping requests for client authentication.Clients MAY choose to respond to a CertificateRequest by sending a
Certificate and CertificateVerify, and the server MAY choose to close the
connection if the client chooses otherwise. When the server does not supply a
server certificate, a client Certificate message is mandatory in order for both parties
to authenticate. If the client does not provide a ticket via a Certificate message
then the server MUST abort the handshake.Note that under TLS-KDH a CertificateVerify message consists of a Kerberos Authenticator
[Section 5.5.1 of ].
The Authenticator serves as the Kerberos equivalent of a digital signature.The "client_certificate_type" extension may be used to negotiate any
supported type for
these messages, including the Kerberos Ticket certificate type defined before.
When not negotiated, the default type is X.509. Note that a client can produce
a Kerberos Ticket even when no "quantum_relief" extension was negotiated
during ClientHello and/or ServerHello, or even when another "qr_method" than
"kdh" was agreed. However, a client MUST NOT send Certifcate and
CertificateVerify messages if it did not receive a CertificateRequest from the
server.Under TLS 1.3, the Finished message is as long as the transcript hash.
Under TLS 1.2, this is negotiable. For TLS-KDH under TLS 1.2 the client MUST
request the "verify_data" length within the Finished message to be as long as
the output length of the
hash being used to compute it, and the server MUST accept this.Under TLS 1.3, all current cipher suites incorporate (Elliptic-Curve)
Diffie-Hellman. Under TLS 1.2 this is optional. For TLS-KDH the
client MUST offer cipher suites that include these forms (i.e. ECDHE) of key agreement and the server MUST NOT select a cipher suite without any of these forms of key agreement.Tickets in Kerberos represent a key-based connection between two peers. The
key material in a Ticket is time-limited in the understanding that a client can always request a new Ticket if so desired. Expiration of a Ticket SHOULD be matched with a teardown of the service. In terms of TLS-KDH, that means that the connection SHOULD NOT exist beyond the life time of a Ticket. Each side can independently close down the TLS connection with an certificate_expired alert.To avoid this, it is possible to request a new client Certificate and
CertificateVerify through a new CertificateRequest, best sent sometime before expiry. The client then acquires a fresh or prolonged Ticket and once exchanged, the connection may continue up to the timeout of the new Ticket.The timeout is updated by every new Ticket supplied in the "opt_ticket"
field of a "quantum_relief" extension with "qr_method" set to "kdh", or by a Certificate of type Kerberos Ticket, provided that it is followed by a valid CertificateVerify.A server MUST NOT send data over a connection with a timed-out Ticket, but SHOULD request a fresh one or disconnect. A client MUST NOT send data over a connection with a timed-out Ticket according to its local clock, but it MAY await the arrival of a fresh Ticket (from its KDC). Data arriving over a connection with a timed-out Ticket is considered a failure to refresh a ticket. It is a good precaution to request a fresh Ticket a few minutes before the active one expires, to compensate for clock skew between TLS endpoints.Kerberos supports Tickets with future validity times, intended for such things as nightly batch jobs that require authentication. By default, a TLS stack should reject such Tickets until they start being valid. Specific applications may however be aware of this enhancement and deliberately override this default behaviour; an example would be an application that schedules such nightly jobs.The introduction of the Quantum Relief extension (in combination with
TLS-KDH) leads to a few cryptographic changes to the TLS protocol. Below, the
three modes introduced are discussed independently. Separate treatment for
TLS 1.3 and 1.2 is only necessary for Quantum Relief encryption. The
aspects of client and server authentication with Kerberos Tickets use the same
data structures and are discussed together.Under client-to-server TLS-KDH, the "opt_ticket" in the "quantum_relief"
extension in the ClientHello is used to supply external (quantum proof) key material. Under peer-to-peer TLS-KDH, the TGT in the "opt_ticket" supplies no shared key material to the client and server (or designated peer), but the ServerHello returns a "quantum_relief" extension with an "opt_ticket" field holding a Ticket that does supply a shared key to use.This key is used to compute
where || signifies concatenation, and
usage is either KEYUSAGE_TLSKDH_CLIENT_QR for a Ticket supplied by the client,
or KEYUSAGE_TLSKDH_SERVER_QR for a Ticket supplied by the server side (or
designated peer). The output of this computation is provided instead of the PSK on
the left of the Key Schedule for TLS 1.3 [page 93 of ]. Note how the ServerHello is involved in this computation, and not just the ClientHello; had PSK facilities been used, then this seeding would have arrived too late to provide the binder_key, client_early_traffic_secret and early_exporter_master_key. But replacing the locally oriented PSK mechanism with TLS-KDH, means that there is no facility for early data or other PSK facilities, so these keys need not be computed.Other "qr_method" values than "kdh" are likely to come up with other computations. There may be some that prefer to influence only the master key by replacing the 0 value for key input as it is shown in the TLS 1.3 key schedule.TLS 1.2 does not offer any form of encryption during the handshake, so Quantum Relief for TLS 1.2 can only be used to strengthen the Master Secret. When
the "quantum_relief" extension with the "kdh" method is accepted by the server, a Ticket is
available while forming the ServerHello; it is in the ClientHello for
client-to-server mode and in the ServerHello for peer-to-peer mode. Call this
Ticket qrt and use it to compute
where || denotes concatenation. The output of this procedure is an octet string which is prepended to what the cipher-suite defines as its pre-master secret. This prepended form is then used instead of the normal pre-master secret during the computation of the master key.Kerberos Tickets(TBD:KRBTKT-CERTTP) can be negotiated independently as client_certificate_type and server_certificate_type ; in TLS-KDH, a client certificate is available when the server accepts the client's "quantum_relief" extension with method "kdh".The contents of the Certificate message when the certificate type is negotiated as this "Kerberos" certificate type is a Kerberos Ticket [Section 5.3 of ] in the customary DER encoding.The contents of the corresponding CertificateVerify message uses this Ticket
k5crt to compute
for a client CertificateVerify message or
for a server CertificateVerify message, where th is the customary transcript hash up to
and including the preceding Certificate message. For TLS 1.3, this hash algorithm equals the transcript hash algorithm; for TLS 1.2, the hash algorithm must match the Certificate signing algorithm, which in case of a Kerberos Ticket means its MAC hashing algorithm without reductions in the size of the hash output.The default use of TLS involves authentication based on X.509 certificates.
In some scenarios such a PKI is not available or not desirable. For this
reason, the remainder of this section defines an alternative, KDH-Only Application Profile as minimally being TLS-KDH compliant.TLS-KDH-compliant applications MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites.TLS-KDH-compliant applications MUST support the Kerberos Ticket certificate
type. They also MUST treat X.509 as the default certificate type, but they MAY refuse any attempt to use it, either by negotiating an explicit alternative or failing to negotiate an alternative.TLS-KDH-compliant applications MUST support key exchanges with secp256r1
(NIST P-256) and SHOULD support key exchanges with X25519 [RFC7748].TLS-KDH-compliant applications MUST support the "quantum_relief" TLS
extension, for which the qr_method value "kdh" MUST be supported, and the peernametype value "none" MUST and "krb5princrealm" SHOULD be supported.Quantum Relief is an alternative to the PSK mechanism, which may have
similar benefits for local setups, but is not subject of discussion here.
The loss of PSK facilities means that no Early Data can be sent, which can
be resolved by sending the same data later. It is a loss of efficiency,
but not of security.To verify that encryption has successfully been established, a
party must validate encrypted data received from the other. This is at
least the case when a proper Finished message arrives, which provides
ample entropy to be certain, incorporating the identities exchanged
throughout the handshake.In TLS 1.3, the parties may send encrypted data which may provide
ample entropy as well. The transcript hash does not include the entropy
derived with the Quantum Relief extension, and so authentication cannot
be used as proof of having established encryption unless it is as a
provider of verifiable entropy that is wrapped in handshake encryption.The late establishment of encryption has an impact on the privacy of
client identity. This identity is unprotected in TLS 1.2, but under TLS 1.3
its privacy is protected with encryption. To ensure that the right
party is communicating remotely, the Finished message SHOULD be processed
before sending the client's Certificate.The identity of the server under generic Quantum Relief needs to
wait for the arrival of the server's Certificate and CertificateVerify
messages. Specifically for TLS-KDH, the ability to decrypt a Ticket
(for the client-to-server flow) or to produce a Ticket from a TGT
(for the peer-to-peer flow) provides the same proof. Clients MAY trust
this to validate server identity, but MUST also validate a
Certificate and CertificateVerify if the server sends them.Under the peer-to-peer flow, the designated peer produces a Ticket
with Kerberos roles reversed relative to TLS roles. The Ticket
produced mentions the designated peer as a Kerberos client to the
service of the TGT-sending party, which is the TLS client. This is
neither a problem to the peer-to-peer flow of TLS-KDH, nor to the
user-to-user mechanism [Section 3.7 of ]
of Kerberos. The TLS client MUST be able to extract the
secret from the Ticket, as an assurance that it is the designated
receiver for this identity claim. The verification of the
CertificateVerify assures this, as well as the binding to the
TLS flow through the transcript hash.The server MUST NOT process any client identity in the Quantum Relief
extension, because that may be either an anonymous identity or a
pseudonym, to avoid public visibility. When client identity is needed
by the server, it MUST ask for it with a CertificateRequest.The client Certificate and CertificateVerify provide the proper
identity for the client, which MAY differ from any identity passed
before.Under TLS-KDH, the client produces a Ticket with identities for
both client and server. The server MUST be able to extract the
secret from the Ticket, as an assurance that it is the designated
receiver for this identity claim. The verification of the
CertificateVerify assures this, as well as the binding to the
TLS flow through the transcript hash.IANA adds the following TLS ExtensionType Value as part of their Transport Layer Security Extensions registry:IANA adds the following TLS Certificate Type as part of their Transport Layer Security Extensions registry:IANA creates a registry for the QuantumReliefMethod in the
TBD: TLS Extensions registry, with the following initial entries
and new entries to be assigned under a Specification Required
policy.IANA creates a registry for the PeerNameType in the
TBD: TLS Extensions registry, with the following initial entries
and new entries to be assigned under a Specification Required
policy.This specification could not have matured without the insights of various
commenters. In order of appearance, we owe thanks to Simo Sorce,
Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos Mavragiannopoulos,
Kenneth Raeburn.
Part of this work was conducted under a grant from the programme "[veilig] door
innovatie" from the government of the Netherlands. It has also
been liberally supported by the NLnet Foundation.