Transport Layer Security (TLS) Parameters

Created

2005-08-23

Last Updated

2026-09-18

Related Registry Group(s)

[Transport Layer Security (TLS) Extensions]

Available Formats

XML
HTML
TXT

Registries Included Below

• TLS ClientCertificateType Identifiers
• TLS Cipher Suites
• TLS ContentType
• TLS Alerts
• TLS HandshakeType
• TLS Supported Groups
• TLS EC Point Formats
• TLS EC Curve Types
• TLS Supplemental Data Formats (SupplementalDataType)
• TLS UserMappingType Values
• TLS SignatureAlgorithm
• TLS HashAlgorithm
• TLS Exporter Labels
• TLS Authorization Data Formats
• TLS Heartbeat Message Types
• TLS Heartbeat Modes
• TLS SignatureScheme
• TLS PskKeyExchangeMode
• TLS KDF Identifiers
• TLS SSLKEYLOGFILE Labels
• TLS RRC Message Types

TLS ClientCertificateType Identifiers

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 5246][RFC 8447][RFC 9851][RFC 9847]

Note

If the "Specification Required" [RFC 8126] procedure applies, 
registration requests can be sent to iana@iana.org or submitted via 
IANA's [application form], per [RFC 9847]. IANA 
will forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

The role of the designated expert is described in [RFC 8447].
The designated expert [RFC 8126] ensures that the specification is
publicly available.  It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the identifier.
    

Note

As specified in [RFC 8126], assignments made in the Private Use
space are not generally useful for broad interoperability.  It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
    

Note

The values in this registry are only applicable to (D)TLS
protocol versions prior to 1.3.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Available Formats

CSV

TLS Cipher Suites

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 9846][RFC 8447][RFC 9147][RFC 9851][RFC 9847]

Note

If the "Specification Required" [RFC 8126] procedure applies, 
registration requests can be sent to iana@iana.org or submitted via 
IANA's [application form], per [RFC 9847]. IANA 
will forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

WARNING

Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing cipher suites listed here 
is not advised.  Implementers and users need to check that the 
cryptographic algorithms listed continue to provide the expected 
level of security.
    

Note

Although TLS 1.3 uses the same cipher suite space as previous
versions of TLS, TLS 1.3 cipher suites are defined differently,
only specifying the symmetric ciphers and hash function, and
cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher
suite values cannot be used with TLS 1.3.
    

Note

CCM_8 cipher suites are not marked as "Recommended".  These
cipher suites have a significantly truncated authentication tag
that represents a security trade-off that may not be appropriate
for general environments.
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Note

The role of the designated expert is described in [RFC 8447].
The designated expert [RFC 8126] ensures that the specification is
publicly available.  It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the cipher suite.
    

Note

As specified in [RFC 8126], assignments made in the Private Use
space are not generally useful for broad interoperability.  It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
    

Note

Any TLS cipher suite that is specified for use with DTLS MUST 
define limits on the use of the associated AEAD function that 
preserves margins for both confidentiality and integrity, 
as specified in Section 4.5.3 of [RFC 9147].
    

Note

When this registry is modified, the YANG module 
"iana-tls-cipher-suite-algs" [iana-tls-cipher-suite-algs] must be 
updated as defined in [RFC 9645].
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS ContentType

Registration Procedure(s)

Standards Action

Reference

[RFC 9846][RFC 9443][RFC 9851][RFC 9847]

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Note

The return_routability_check content type is only applicable to DTLS 1.2 and 1.3.
    

Available Formats

CSV

TLS Alerts

Registration Procedure(s)

Standards Action

Reference

[RFC 9846][RFC 9851]

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS HandshakeType

Registration Procedure(s)

Standards Action

Reference

[RFC 9846][RFC 9851]

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS Supported Groups

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 8422][RFC 7919][RFC 9846][RFC 8447][RFC 9851][RFC 9847][RFC 9954]

Note

If the "Specification Required" [RFC 8126] procedure applies, 
registration requests can be sent to iana@iana.org or submitted via 
IANA's [application form], per [RFC 9847]. IANA 
will forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

Renamed from "EC Named Curve Registry"
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Note

The role of the designated expert is described in [RFC 8447].
The designated expert [RFC 8126] ensures that the specification is
publicly available.  It is sufficient to have an Internet-Draft
(that is posted and never published as an RFC) or a document from
another standards body, industry consortium, university site, etc.
The expert may provide more in-depth reviews, but their approval
should not be taken as an endorsement of the supported group.
    

WARNING

Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing supported groups 
listed here is not advised.  Implementers and users need to check 
that the cryptographic algorithms listed continue to provide the 
expected level of security.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS EC Point Formats

Registration Procedure(s)

Specification Required

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 8422][RFC 9851][RFC 9847]

Note

Registration requests should be sent to iana@iana.org or submitted 
via IANA's [application form], per [RFC 9847]. 
IANA will forward the request to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS EC Curve Types

Registration Procedure(s)

Specification Required

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 8422][RFC 9851][RFC 9847]

Note

Registration requests should be sent to iana@iana.org or submitted 
via IANA's [application form], per [RFC 9847]. 
IANA will forward the request to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS Supplemental Data Formats (SupplementalDataType)

Reference

[RFC 4680][RFC 8447][RFC 9851][RFC 9847]

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS UserMappingType Values

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 4681][RFC 9851][RFC 9847]

Note

Requests for registration in the "Specification Required" [RFC 8126] 
range should be sent to iana@iana.org or submitted via IANA's 
[application form], per [RFC 9847]. IANA will 
forward the request to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS SignatureAlgorithm

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 5246][RFC 8447][RFC 9155][RFC 9851][RFC 9847]

Note

If the "Specification Required" [RFC 8126] procedure applies, 
registration requests can be sent to iana@iana.org or submitted via 
IANA's [application form], per [RFC 9847]. IANA 
will forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

The values in this registry are only applicable to (D)TLS
protocol versions prior to 1.3.  (D)TLS 1.3 and later versions'
values are registered in the TLS SignatureScheme registry.
    

WARNING

Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing the cryptographic 
algorithms listed here is not advised.  Implementers and users need 
to check that the cryptographic algorithms listed continue to 
provide the expected level of security.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Available Formats

CSV

TLS HashAlgorithm

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 5246][RFC 8447][RFC 9155][RFC 9851][RFC 9847]

Note

If the "Specification Required" [RFC 8126] procedure applies, 
registration requests can be sent to iana@iana.org or submitted via 
IANA's [application form], per [RFC 9847]. IANA 
will forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

The values in this registry are only applicable to (D)TLS
protocol versions prior to 1.3.  (D)TLS 1.3 and later versions'
values are registered in the TLS SignatureScheme registry.
    

WARNING

Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing the cryptographic 
algorithms listed here is not advised.  Implementers and users need 
to check that the cryptographic algorithms listed continue to 
provide the expected level of security.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Available Formats

CSV

TLS Exporter Labels

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 5705][RFC 8447][RFC 9847]

Note

If the "Expert Review" [RFC 8126] procedure applies, registration 
requests can be sent to iana@iana.org or submitted via IANA's 
[application form], per [RFC 9847]. IANA will 
forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

(1) These entries are reserved and MUST NOT be used for the 
purpose described in [RFC 5705], in order to avoid confusion 
with similar, but distinct use in [RFC 5246].
    

Note

[RFC 5705] defines keying material exporters for TLS in terms
of the TLS PRF.  [RFC 9846] replaced the PRF with HKDF,
thus requiring a new construction.  The exporter interface remains
the same; however, the value is computed differently.
    

Note

The role of the designated expert is described in 
[RFC 8447, Section 17]. Even though this registry does not require a 
specification, the designated expert [RFC 8126] will strongly 
encourage registrants to provide a link to a publicly available 
specification. An Internet-Draft (that is posted and never published 
as an RFC) or a document from another standards body, industry 
consortium, university site, etc. are suitable for these purposes. 
The expert may provide more in-depth reviews, but their approval 
should not be taken as an endorsement of the exporter label. The 
expert also verifies that the label is a string consisting of 
printable ASCII characters beginning with "EXPORTER". IANA MUST also 
verify that one label is not a prefix of any other label. For 
example, labels "key" or "master secretary" are forbidden.
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Available Formats

CSV

TLS Authorization Data Formats

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 5878][RFC 8447][RFC 9851][RFC 9847]

Note

Requests for registration in the "Specification Required" [RFC 8126] 
range should be sent to iana@iana.org or submitted via IANA's 
[application form], per [RFC 9847]. IANA will 
forward the request to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS Heartbeat Message Types

Registration Procedure(s)

Expert Review

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 6520][RFC 8447][RFC 9851][RFC 9847]

Note

Registration requests should be sent to iana@iana.org or submitted 
via IANA's [application form], per [RFC 9847]. 
IANA will forward the request to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. 
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS Heartbeat Modes

Registration Procedure(s)

Expert Review

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 6520][RFC 8447][RFC 9851][RFC 9847]

Note

Registration requests should be sent to iana@iana.org or submitted 
via IANA's [application form], per [RFC 9847]. 
IANA will forward the request to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Available Formats

CSV

TLS SignatureScheme

Expert(s)

Yoav Nir, Rich Salz, Nick Sullivan

Reference

[RFC 9846][RFC 9851][RFC 9847]

Note

If the "Specification Required" [RFC 8126] procedure applies, 
registration requests can be sent to iana@iana.org or submitted via 
IANA's [application form], per [RFC 9847]. IANA 
will forward the submission to the expert mailing list described in 
[RFC 8447, Section 17] and track its progress. See the registration 
procedure table below for more information.
    

WARNING

Cryptographic algorithms and parameters will be broken or
weakened over time.  Blindly implementing signature schemes 
listed here is not advised.  Implementers and users need to check 
that the cryptographic algorithms listed continue to provide the 
expected level of security.
    

Note

As specified in [RFC 8126], assignments made in the Private Use
space are not generally useful for broad interoperability.  It is
the responsibility of those making use of the Private Use range to
ensure that no conflicts occur (within the intended scope of use).
For widespread experiments, temporary reservations are available.
    

Note

Any TLS entry added after the IESG approves publication of [RFC 9851] 
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like "For 
TLS 1.3 or later" in that entry, such as the "Comment" column.
    

Note

If the "Recommended" column is set to "N", it does not necessarily 
mean that it is flawed; rather, it indicates that the item either 
has not been through the IETF consensus process, has limited 
applicability, or is intended only for specific use cases. If the 
"Recommended" column is set to "D," the item is discouraged and 
SHOULD NOT or MUST NOT be used, depending upon the situation; 
consult the item's references for clarity.
    

Available Formats

CSV