I-D list for Transport Layer Security RSS FeedDocument changesurn:uuid:061bd0f1-43b5-5826-acee-9ffbe86b62402024-03-28T13:46:32-0700Deprecating Obsolete Key Exchange Methods in TLS 1.29830902024-03-24T00:05:00-07002024-03-24T00:05:00-0700(System)Document has expiredexpired_documentietftlsexpiredidexistswg-lcML-KEM Post-Quantum Key Agreement for TLS 1.39828912024-03-21T17:57:02-07002024-03-21T17:57:02-0700Deirdre ConnollyNew version available: <b>draft-connolly-tls-mlkem-key-agreement-01.txt</b>new_revisionnoneactiveidexists This memo defines ML-KEM-768 and ML-KEM-1024 as a standalone
NamedGroup for use in TLS 1.3 to achieve post-quantum key agreement.
01ML-KEM Post-Quantum Key Agreement for TLS 1.39828902024-03-21T17:57:02-07002024-03-21T17:57:02-0700Deirdre ConnollyNew version approvednew_submissionnoneactiveidexistsML-KEM Post-Quantum Key Agreement for TLS 1.39828892024-03-21T17:53:10-07002024-03-21T17:53:10-0700(System)Request for posting confirmation emailed to previous authors: Deirdre Connolly <durumcrustulum@gmail.com>new_submissionnoneactiveidexistsML-KEM Post-Quantum Key Agreement for TLS 1.39828882024-03-21T17:53:09-07002024-03-21T17:53:09-0700Deirdre ConnollyUploaded new revisionnew_submissionnoneactiveidexistsNegotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)9826462024-03-21T00:07:38-07002024-03-21T00:07:38-0700(System)Received changes through RFC Editor sync (added Verified Errata tag)sync_from_rfc_editorietftlsStephen FarrellpublishedTransport Layer Security (TLS) Application-Layer Protocol Negotiation Extension9826452024-03-21T00:07:25-07002024-03-21T00:07:25-0700(System)Received changes through RFC Editor sync (removed Errata tag (all errata rejected))sync_from_rfc_editorietftlsStephen FarrellpublishedUsing Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)9816752024-03-19T11:28:18-07002024-03-19T11:28:18-0700Thomas FossatiNew version available: <b>draft-fossati-tls-attestation-06.txt</b>new_revisionnoneactiveidexists The TLS handshake protocol allows authentication of one or both peers
using static, long-term credentials. In some cases, it is also
desirable to ensure that the peer runtime environment is in a secure
state. Such an assurance can be achieved using attestation which is
a process by which an entity produces evidence about itself that
another party can use to appraise whether that entity is found in a
secure state. This document describes a series of protocol
extensions to the TLS 1.3 handshake that enables the binding of the
TLS authentication key to a remote attestation session. This enables
an entity capable of producing attestation evidence, such as a
confidential workload running in a Trusted Execution Environment
(TEE), or an IoT device that is trying to authenticate itself to a
network access point, to present a more comprehensive set of security
metrics to its peer. These extensions have been designed to allow
the peers to use any attestation technology, in any remote
attestation topology, and mutually.
06Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)9816742024-03-19T11:28:18-07002024-03-19T11:28:18-0700Yogesh DeshpandeNew version approvednew_submissionnoneactiveidexistsUsing Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)9816592024-03-19T10:06:03-07002024-03-19T10:06:03-0700(System)Request for posting confirmation emailed to previous authors: Arto Niemi <arto.niemi@huawei.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Ionut Mihalcea <ionut.mihalcea@arm.com>, Paul Howard <paul.howard@arm.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Yogesh Deshpande <yogesh.deshpande@arm.com>new_submissionnoneactiveidexistsUsing Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)9816582024-03-19T10:06:03-07002024-03-19T10:06:03-0700Thomas FossatiUploaded new revisionnew_submissionnoneactiveidexistsProhibiting Secure Sockets Layer (SSL) Version 2.09814732024-03-19T00:06:58-07002024-03-19T00:06:58-0700(System)Received changes through RFC Editor sync (added Verified Errata tag)sync_from_rfc_editorietftlsAlexey MelnikovpublishedHybrid key exchange in TLS 1.39805532024-03-18T00:05:09-07002024-03-18T00:05:09-0700(System)Document has expiredexpired_documentietftlsChristopher A. Woodexpiredidexistswg-docTLS Key Share Prediction9804062024-03-17T21:26:01-07002024-03-17T21:26:01-0700David BenjaminNew version available: <b>draft-davidben-tls-key-share-prediction-01.txt</b>new_revisionnoneactiveidexists This document defines a mechanism for servers to communicate key
share preferences in DNS. Clients may use this information to reduce
TLS handshake round-trips.
01TLS Key Share Prediction9804052024-03-17T21:26:00-07002024-03-17T21:26:00-0700David BenjaminNew version approvednew_submissionnoneactiveidexistsTLS Key Share Prediction9803862024-03-17T21:16:28-07002024-03-17T21:16:28-0700(System)Request for posting confirmation emailed to previous authors: David Benjamin <davidben@google.com>new_submissionnoneactiveidexistsTLS Key Share Prediction9803852024-03-17T21:16:23-07002024-03-17T21:16:23-0700David BenjaminUploaded new revisionnew_submissionnoneactiveidexistsA Flags Extension for TLS 1.39795172024-03-16T14:01:24-07002024-03-16T14:01:24-0700Yoav NirNew version available: <b>draft-ietf-tls-tlsflags-13.txt</b>new_revisionietftlsSean Turneractiveidexistswaiting-for-implementation A number of extensions are proposed in the TLS working group that
carry no interesting information except the 1-bit indication that a
certain optional feature is supported. Such extensions take 4 octets
each. This document defines a flags extension that can provide such
indications at an average marginal cost of 1 bit each. More
precisely, it provides as many flag extensions as needed at 4 + the
order of the last set bit divided by 8.
13A Flags Extension for TLS 1.39795162024-03-16T14:01:24-07002024-03-16T14:01:24-0700Yoav NirNew version accepted (logged-in submitter: Yoav Nir)new_submissionietftlsSean Turneractiveidexistswaiting-for-implementationA Flags Extension for TLS 1.39795152024-03-16T14:01:24-07002024-03-16T14:01:24-0700Yoav NirUploaded new revisionnew_submissionietftlsSean Turneractiveidexistswaiting-for-implementationAbridged Compression for WebPKI Certificates9794332024-03-16T07:09:25-07002024-03-16T07:09:25-0700Dennis JacksonNew version available: <b>draft-ietf-tls-cert-abridge-01.txt</b>new_revisionietftlsactiveidexistswg-doc This draft defines a new TLS Certificate Compression scheme which
uses a shared dictionary of root and intermediate WebPKI
certificates. The scheme smooths the transition to post-quantum
certificates by eliminating the root and intermediate certificates
from the TLS certificate chain without impacting trust negotiation.
It also delivers better compression than alternative proposals whilst
ensuring fair treatment for both CAs and website operators. It may
also be useful in other applications which store certificate chains,
e.g. Certificate Transparency logs.
01Abridged Compression for WebPKI Certificates9794322024-03-16T07:09:25-07002024-03-16T07:09:25-0700Dennis JacksonNew version approvednew_submissionietftlsactiveidexistswg-docAbridged Compression for WebPKI Certificates9794282024-03-16T07:07:47-07002024-03-16T07:07:47-0700(System)Request for posting confirmation emailed to previous authors: Dennis Jackson <ietf@dennis-jackson.uk>new_submissionietftlsactiveidexistswg-docAbridged Compression for WebPKI Certificates9794272024-03-16T07:07:47-07002024-03-16T07:07:47-0700Dennis JacksonUploaded new revisionnew_submissionietftlsactiveidexistswg-doc