Channel Bindings for TLS
updated by
- rfc-9266 — Channel Bindings for TLS 1.3
Extracted elements (22)
The original 'tls-unique' definition (always the client's Finished from the first handshake) was replaced to match actual deployed implementations. The new definition uses the first Finished of the most recent handshake, reflecting what implementors actually built and deployed.
The renegotiation constraint is a MUST NOT for servers but only a SHOULD NOT for clients because TLS APIs generally expose server-side renegotiation control, while many client TLS stacks do not provide fine-grained control over when renegotiation occurs.
'tls-server-end-point' uses a hash of the server certificate rather than the certificate itself because some implementations need to track channel binding in kernel-mode memory, which is often at a premium. The hash produces manageably small channel binding data.
The new 'tls-unique' definition is backwards-incompatible with the original except when: (a) only one handshake has taken place before authentication, and (b) that handshake was a full (not abbreviated) handshake. Original and new implementations only interoperate under both conditions.
The 'tls-unique' channel binding data may change over time due to renegotiation, creating a synchronization problem if the data changes between client authentication initiation and server processing of the first authentication message, causing spurious authentication failures.
'tls-server-end-point' is only available when cipher suites use the Certificate handshake message (PKIX-based), and is unavailable for anonymous, PSK (non-RSA), Kerberos, SRP (non-DSS/RSA), and OpenPGP cipher suites. 'tls-unique' is applicable to more contexts.
'tls-server-end-point' may be used with existing TLS server-side proxies (concentrators) without modification, whereas 'tls-unique' may require firmware or software updates to proxies. Therefore 'tls-server-end-point' may interoperate in proxy deployments where 'tls-unique' does not.
Application protocol specifications MUST indicate at least one mandatory-to-implement channel binding type, MAY specify a negotiation protocol, MAY allow out-of-band negotiation or configuration, and SHOULD prefer 'tls-unique' over 'tls-server-end-point'.
Application protocols SHOULD be designed so that a server never needs to request TLS renegotiation immediately before or during application-layer authentication, to avoid the synchronization problem with 'tls-unique'.
Applications utilizing 'tls-unique' channel binding with TLS implementations lacking support for secure renegotiation (RFC 5746) MUST ensure that ChangeCipherSpec has been used in all renegotiations prior to application-layer authentication, and MUST discard any knowledge learned from the server prior to completion of authentication.
Client applications SHOULD NOT initiate TLS renegotiation between the start and completion of authentication, to avoid spurious authentication failures due to changing 'tls-unique' channel binding data.
Server applications MUST NOT request TLS renegotiation during phases of the application protocol during which application-layer authentication occurs, to avoid the synchronization problem where 'tls-unique' channel binding data changes between authentication initiation and processing.
TLS implementations supporting renegotiation SHOULD provide APIs that allow applications to control when renegotiation can take place, for example via a callback interface when the server requests renegotiation.
TLS implementations supporting 'tls-unique' and/or 'tls-unique-for-telnet' MUST provide application programming interfaces by which applications (clients and servers) may obtain the channel bindings for a TLS connection.
The 'tls-server-end-point' channel binding type is defined as the hash of the TLS server's certificate as it appears octet-for-octet in the server's Certificate message (the first element of certificate_list). The hash function is selected based on the certificate's signatureAlgorithm.
The 'tls-unique' channel binding type is defined as the first TLS Finished message sent (the Finished struct, not the record layer message) in the most recent TLS handshake of the TLS connection being bound. For full handshakes the client sends first; for abbreviated handshakes (session resumption) the server sends first.
The 'tls-unique-for-telnet' channel binding type uses the client and server TLS Finished messages (both Finished structs) from the first TLS handshake, concatenated in client-then-server order by the client and server-then-client order by the server.
IANA updated three existing channel binding type registrations: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for-telnet'. Ownership of all three was transferred to the IESG, with updated contacts, published specification reference (RFC 5929), and applicability notes.
None of the three channel binding types defined herein produce data that must be kept secret or can be expected to be private. Disclosure of channel bindings data by authentication mechanisms does not weaken TLS security, since the data is visible to eavesdroppers whenever non-confidential cipher suites are used, and active attackers already possess both sides' Finished messages.
The 'tls-server-end-point' channel binding type has a hash algorithm agility concern because it uses a hash beyond TLS's own cryptography. The algorithm is derived from the server certificate's signature algorithm (defaulting to SHA-256 for MD5/SHA-1), making it hash-agile via PKIX and TLS.
TLS Finished messages are cryptographically bound to the TLS connection and known to both endpoints. With secure renegotiation (RFC 5746), each handshake is bound to the preceding one, making TLS Finished messages safe to use as channel bindings when the authentication mechanism conforms to RFC 5056.
For 'tls-server-end-point', the hash function is chosen as: SHA-256 if the certificate signatureAlgorithm uses MD5 or SHA-1; otherwise use the hash function from the signatureAlgorithm. If the signatureAlgorithm uses no hash or multiple hashes, the channel binding type is undefined.