[TLS] Last Call: (A TLS ClientHello padding extension) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'A TLS ClientHello padding extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-08-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'A TLS ClientHello padding extension' to Proposed Standard (draft-ietf-tls-padding-04.txt)
The IESG has approved the following document: - 'A TLS ClientHello padding extension' (draft-ietf-tls-padding-04.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ Technical Summary This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. Working Group Summary This extension was originally introduced to work around a particular vendor's issue. Its deployment was successful. Since then it has been found that this extension can serve to alleviate issues with issues in several vendor's products. There was good consensus to move forward with this document as it may find further applicability in the future. Document Quality There are multiple interoperable implementations (web browsers and web servers) of this extension deployed today. It works well to solve the problem. Personnel Document shepherd is Joseph Salowey The irresponsible area director is Stephen Farrell ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Transport Layer Security (TLS) Cached Information Extension) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Cached Information Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ballot/ No IPR declarations have been submitted directly on this I-D. RFC 4634 has been obsoleted by RFC 6234. We'll fix the reference later. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Importing External PSKs for TLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Importing External PSKs for TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-10-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Exported Authenticators in TLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Exported Authenticators in TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-10-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Deprecating MD5 and SHA-1 signature hashes in TLS 1.2) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating MD5 and SHA-1 signature hashes in TLS 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures. However, this document does not deprecate SHA-1 in HMAC for record protection. This document updates RFC 5246 and RFC 7525. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating TLSv1.0 and TLSv1.1' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document, if approved, formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents (will be moved|have been moved) to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347), but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLSv1.0 or TLSv1.1 as described herein. This document also updates the best practices for TLS usage in RFC 7525 and hence is part of BCP195. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent Submission Editor stream) rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent Submission Editor stream) rfc5023: The Atom Publishing Protocol (Proposed Standard - IETF stream) rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (Proposed Standard - IETF stream) rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (Proposed Standard - IETF stream) rfc5018: Connection Establishment in the Binary Floor Control Protocol (BFCP) (Proposed Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the Internet Registry Information Service (Proposed Standard - IETF stream) rfc4992: XML Pipelining with Chunks for the Internet Registry Information Service (Proposed Standard - IETF stream) rfc4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular (Informational - IETF stream) rfc4964: The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular (Informational - IETF stream) rfc4851: The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) (Informational - IETF stream) rfc4851: The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) (Informational - IETF stream) rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet (Informational - IETF stream) rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet (Informational - IETF stream) rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - IETF stream) rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - IETF stream) rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard - IETF stream) rfc4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard - IETF stream) rfc4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Historic - IETF stream) rfc4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Historic - IETF stream) rfc4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (Historic - IETF stream) rfc4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (Historic - IETF stream) rfc4732: Internet Denial-of-Service Considerations (Inf
[TLS] Last Call: (TLS Ticket Requests) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS Ticket Requests' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-12-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract TLS session tickets enable stateless connection resumption for clients without server-side, per-client, state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while simultaneously priming clients for future connection attempts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Deprecating TLSv1.0 and TLSv1.1' to Best Current Practice (draft-ietf-tls-oldversions-deprecate-12.txt)
The IESG has approved the following document: - 'Deprecating TLSv1.0 and TLSv1.1' (draft-ietf-tls-oldversions-deprecate-12.txt) as Best Current Practice This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ Technical Summary This document formally deprecates Transport Layer Security (TLS) versions 1.0 [RFC2246], TLS 1.1 [RFC4346], and DTLS 1.0 [RFC4347]. It moves these documents to the historic state. The draft is intended for BCP because it updates 7525 and hence should be part of BCP195. Working Group Summary When this draft was first presented at IETF 102, there was discussion about waiting to request publication until the TLSv1.0 and TLSv1.1 use rates to drop to an “acceptable” level. There were others that felt that there was no need to wait and that the IETF should do what it thinks is right with its protocols. The WG, obviously, settled on progressing this draft. Note this draft was further discussed at IETF 103 and 104 to resolve comments received. There was also some discomfort from enterprise users who were concerned about the time and expense needed to transition to newer versions. It should be noted that library support typically continues for years beyond the publication date of the RFC, e.g., OpenSSL released in Fall 2018 will support TLSv1.0 and TLSv1.1 for roughly another 4 years. The WGLC [0] did produce some fireworks. One participant very strongly believes that “Disabling TLSv1.0 will only result in lots of interop failures and pain, but no improvement in security”. The assertion was that the use of (RSA,MD) and (RSA,SHA-1) is allowed in TLS 1.2. This comment resulted in draft-lvelvindron-tls-md5-sha1-deprecate, which deprecates the use of MD5 and SHA1 in TLS1.2. The chairs determined that this draft could proceed without the MD5/SHA1 deprecation text as it is contained in another draft [1]. IETF LC also added two RFCs to the updates list and more importantly a section was added to address operational considerations. [0] Link to WGLC thread: https://mailarchive.ietf.org/arch/msg/tls/cupb-OgiSK1ulpRANAbihPHc7zI [1] Link to chair msg: https://mailarchive.ietf.org/arch/msg/tls/xyMXqKQUZeztD5WupvI0uBp4OLA Document Quality The document got a great deal of review from many people. The list of documents updated was produced mechanically with a script and is believed to be accurate and complete. Implementations have started picking up the guidance to greater and lesser extent, but the only interoperability considerations are expected to be those listed in the operational considerations section of the document, since the change is just to remove support (whether entirely or by default) for the older protocol versions. Personnel The document shepherd is Sean Turner. The Area Director is Benjamin Kaduk. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'TLS Ticket Requests' to Proposed Standard (draft-ietf-tls-ticketrequests-07.txt)
The IESG has approved the following document: - 'TLS Ticket Requests' (draft-ietf-tls-ticketrequests-07.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ Technical Summary This document defines a TLS extension that clients can use to inform servers about the desired number of tickets to generate, in order to reduce ticket waste while simultaneously letting clients prepare for future connection attempts. Working Group Summary The draft had a fairly quiet existence until the -02 version, which was also the version where the authors requested the chairs request WGLC. The WGLC and two issue-specific consensus calls that followed were all fairly contentious. The WGLC and the two issue-specific consensus calls resulted in changes to the draft: the count field was renamed new_session_count, a new counter called resumption_count was added, and text was added to address racing pre-conditions. The addition of the second counter acknowledged that resumption is different and can tolerate the complexity of the additional counter. What was not added was text to address ticket reuse use cases; RFC 8446 indicates "clients SHOULD NOT reuse a ticket for multiple connections". One of the issue-specific consensus calls about this was about this point and there was no consensus to add text to address this use case. The consensus should probably be characterized as rough. This is because it seems that that the same people that supported adopting the draft support publishing the mechanism, but there are differences in how far participants believe the mechanism should go in supporting ticket reuse. Document Quality Due to the controversial nature of the discussion of ticket reuse, essentially all the text in this document received careful review from many WG participants. It should be of high quality, though to my knowledge implementors wanted to wait until the controversy was settled (i.e., by publication) before implementing. Personnel Sean Turner is the Shepherd. Ben Kaduk is the Area Director. RFC Editor Note Please ensure that the current (RFC 8174) form of BCP 14 boilerplate is used. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (The Datagram Transport Layer Security (DTLS) Protocol Version 1.3) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The Datagram Transport Layer Security (DTLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-02-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8439: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF Stream) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Connection Identifiers for DTLS 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'The Datagram Transport Layer Security (DTLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-dtls13-43.txt)
The IESG has approved the following document: - 'The Datagram Transport Layer Security (DTLS) Protocol Version 1.3' (draft-ietf-tls-dtls13-43.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ Technical Summary This document defines the DTLS 1.3 protocol, which is intentionally based on the Transport Layer Security (TLS) 1.3 protocol. DTLS 1.3 provides equivalent as with TLS 1.3 security guarantees with the exception of order protection/non-replayability. Working Group Summary This draft has been discussed at length on the mailing list and at numerous IETF meetings. As DTLS is based on TLS, much of the discussion already occurred before work began in earnest. The DTLS-specific issues, e.g., adding the ACK content type, KeyUpdate mechanism, and DTLS key separation, were discussed both on the mailing list and the at IETF meetings. There is broad consensus to publish this document. Document Quality This document has seen extensive review in the WG and is believed to be high quality. The major TLS implementations are expected to implement it if they have not done so already. Personnel Sean Turner is the Document Shepherd. Ben Kaduk is the AD. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Connection Identifiers for DTLS 1.2' to Proposed Standard (draft-ietf-tls-dtls-connection-id-13.txt)
The IESG has approved the following document: - 'Connection Identifiers for DTLS 1.2' (draft-ietf-tls-dtls-connection-id-13.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ Technical Summary This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. An explicit CID allows for the DTLS association to persist across such address/port changes. Working Group Summary The document is of interest to a subset of the working group participants. The participants are active and there is general working group consensus behind the document. Document Quality The document has been reviewed by people implementing the protocol. There are multiple implementations of this an earlier version of extension, and the current version has also been implemented. Personnel The Document Shepherd is Joseph Salowey and the responsible AD is Ben Kaduk ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2' to Proposed Standard (draft-ietf-tls-md5-sha1-deprecate-09.txt)
The IESG has approved the following document: - 'Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2' (draft-ietf-tls-md5-sha1-deprecate-09.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ Technical Summary The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures. However, this document does not deprecate SHA-1 in HMAC for record protection. This document updates RFC 5246. Working Group Summary * There is strong support in the working group for this document. Primary items during WGLC was around the consistency of the normative language. * Discussion from AD Review and IETC LC saw the streamlining of the update guidance to RFC5246 and dropping an formal update to RFC7525 (as it is being revised). Document Quality * There was review from the WG, comments from the IETF LC and Directorates (in particular IoTDIR) were addressed. Personnel Document Shepherd = Sean Turner Responsible AD = Roman Danyliw ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Guidance for External PSK Usage in TLS) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Guidance for External PSK Usage in TLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-11-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks. This document discusses PSK use cases and provisioning processes. This document provides advice for applications to help meet these assumptions. This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'Guidance for External PSK Usage in TLS' to Informational RFC (draft-ietf-tls-external-psk-guidance-05.txt)
The IESG has approved the following document: - 'Guidance for External PSK Usage in TLS' (draft-ietf-tls-external-psk-guidance-05.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/ Technical Summary This document was born from a DT (Design Team) formed after discussions at IETF 106 about draft-ietf-tls-external-psk-importer made it clear that some guidance was needed with respect to PSK (Pre-Shared Key) usage. It summarizes known use cases and risks, and offers guidance on using PSKs securely in TLS. Working Group Summary The DT was comprised of the following participants: Benjamin Beurdouche, Bjoern Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, and Russ Housley. In addition to this powerhouse DT providing input on the original version of the document, the document was also reviewed by the following people: Scott Hollenbeck, Jim Schaad, Carrick Bartle, Watson Ladd, John Mattsson, Ben Smyth, and Jonathan Hammell. The Shepherd has no concerns whatsoever about the breadth and depth of reviews. The DT’s output was presented at a virtual interim meeting. The remainder of the discussion occurred on the list. Document Quality The document does not specify a protocol per se, but it has been well reviewed and implementations either implement the guidance or allow library consumers to do so directly. Personnel Sean Turner is the document Shepherd. Ben Kaduk is the responsible Area Director. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Delegated Credentials for (D)TLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Delegated Credentials for (D)TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-04-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The organizational separation between the operator of a (D)TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism to to overcome some of these limitations by enabling operators to delegate their own credentials for use in (D)TLS without breaking compatibility with peers that do not support this specification. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Importing External PSKs for TLS' to Proposed Standard (draft-ietf-tls-external-psk-importer-08.txt)
The IESG has approved the following document: - 'Importing External PSKs for TLS' (draft-ietf-tls-external-psk-importer-08.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ Technical Summary This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. Working Group Summary Since this document addresses some potential security issues in TLS 1.3 there was a fair amount of discussion in the working group. At this point there is good consensus for the document within the working group. Document Quality There are implementations of the protocol and a number of implementers have shown interest. The document has had review in the context of the "selfie" attack which it helps to address. Personnel Document Shepherd is Joe Salowey. Responsible Area Director is Roman Danyliw. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Exported Authenticators in TLS' to Proposed Standard (draft-ietf-tls-exported-authenticator-15.txt)
The IESG has approved the following document: - 'Exported Authenticators in TLS' (draft-ietf-tls-exported-authenticator-15.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ Technical Summary This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. Working Group Summary As further background, Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternativ e to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. The document author presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 Document Quality EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. See [2] for formal security reviews. Personnel Sean Turner is the document shepherd Roman Danyliw is the responsible AD. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Delegated Credentials for (D)TLS' to Proposed Standard (draft-ietf-tls-subcerts-15.txt)
The IESG has approved the following document: - 'Delegated Credentials for (D)TLS' (draft-ietf-tls-subcerts-15.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ Technical Summary The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification. Working Group Summary There is good consensus for this document with the working group. There was some delay in getting issues addressed from the previous WGLC and a delay in publishing a revised draft with the required changes. There is interest in the working group to see this document move forward. Document Quality Several vendors have indicated they will support the draft and more than one implementation exists. There are test vectors available for the draft, but the authors and chairs decided to wait until they are verified before including them in the draft. Personnel Joe Salowey is the document Shepherd. Paul Wouters is the Responsible Area Director. The IANA Expert(s) for the registries in this document are Yoav Nir, Rich Salz, Nick Sullivan. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (A DANE Record and DNSSEC Authentication Chain Extension for TLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'A DANE Record and DNSSEC Authentication Chain Extension for TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-02-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'IANA Registry Updates for TLS and DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs (see updates header). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5878: Transport Layer Security (TLS) Authorization Extensions (Experimental - IETF stream) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2900/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2900/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) rfc6962: Certificate Transparency (Experimental - IETF stream) rfc6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (informational - Independent Stream) rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF stream) rfc7748: Elliptic Curves for Security (Informational - IRTF stream) rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) (Informational - IRTF stream) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] EXTENDED Last Call: (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)
The IESG has approved the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' (draft-ietf-tls-tls13-28.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ Technical Summary This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. Working Group Summary The document is the work product of the members of the TLS WG. There is strong consensus in the working group for this document. The area that was most controversial was around the inclusion of a 0-RTT mode that has different security properties than the rest of TLS. s1.3 lists the major differences from TLS1.2, as agreed by the contributors; we do not think that the RFC needs to list the changes that occurred between each draft. The draft has had 3 WGLCs to address various issues and the chairs assessment was fair in each of these discussions. At this point there are no known outstanding issue. While I personally do not agree with inclusion of 0-RTT because there are bound to be successful attacks against the mitigations in the future, I do agree with the chair's assessment of the WG consensus and am pleased with the additional text on mitigating the associated risks with 0-RTT. Document Quality There are over 10 interoperable implementations of the protocol from different sources written in different languages. The major web browser vendors and TLS libraries vendors have draft implementations or have indicated they will support the protocol in the future. In addition to having extensive review in the TLS working group, the protocol has received unprecedented security review by the academic community. Several TRON (TLS Ready or Not) conferences were held with academic community to give them a chance to present their findings for TLS. This has resulted in improvements to the protocol. There was also much consideration and discussion around any contentious points, resolved through polls and working group last calls. Please note that ID-nits complains about the obsoleted/ updated RFCs not being listed in the abstract. This is intentional because the abstract is now a concise and comprehensive overview and is free form citations, as per RFC7322. Personnel The Document Shepherd is Sean Turner. The responsible AD is Kathleen Moriarty. The IANA Expert(s) for the registries in this document are Yoav Nir , Rich Salz , and Nick Sullivan . IANA Note This document requests the creation of the TLS SignatureScheme Registry with values assigned via Specification Required [RFC8126]. This document requests the reference for several registries be updated to point to this document. The registries include: - TLS Cipher Suite Registry, updated via via Specification Required [RFC8126] - TLS ContentType Registry, future values allocated via Standards Action [RFC8126] - TLS Alert Registry, future values allocated via Standards Action [RFC8126] - TLS HandshakeType Registry, future values allocated via Standards Action [RFC8126] - TLS ExtensionType Registry, the policy is changed in ietf-tls-iana-registry-updates and this will be reflected in version 25 of the draft RFC Editor Note Please ensure a reference is added prior to final publication for the text added in section E.6. PSK Identity Exposure of draft-ietf-tls-tls13 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'A DANE Record and DNSSEC Authentication Chain Extension for TLS' to Proposed Standard (draft-ietf-tls-dnssec-chain-extension-07.txt)
The IESG has approved the following document: - 'A DANE Record and DNSSEC Authentication Chain Extension for TLS' (draft-ietf-tls-dnssec-chain-extension-07.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ Technical Summary This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. Working Group Summary There was good support and no controversy on list or in meetings. Document Quality The draft has had a fair amount of review. I am not aware of implementations as it wasn't reported by the document shepherd. Personnel The document shepherd is Joseph Salowey and the responsible AD is Kathleen Moriarty. IANA Note A new value in the TLS ExtensionsType registry RFC Editor Note Please ensure a normative reference is added for NSEC3 in the final publication. Please ensure Richard Barnes affiliation is corrected from Mozilla to Cisco. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)
The IESG has approved the following document: - 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ Technical Summary This document is not very technical, it's about IANA registries: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Working Group Summary This draft has been discussed at multiple IETFs most recently at IETF100: https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-iana-registry-updates/ There's not been a lot of review because most people consider this administrivia that others should do; most just want the rules relaxed. A couple of notable reviews have been provided as noted below. The most important change - to loosen registrations while at the same time adding a "recommended" column to key registries requiring standards action for a "yes" value, had clear WG consensus. Various other WG documents depend on these changes being made and more will in the near future. Document Quality This document is essentially administrative, so the important considerations are to ensure consistency amongst it, the TLS 1.3 spec, and the existing registry contents, as well as internal consistency about the handling for various attributes, such as the "Recommended" column, warning notes to be added to registries, and review policies. Martin Thomson and Eric Rescorla have reviewed previous versions of the document. Personnel Stephen Farrell is the Document Shepherd. Benjamin Kaduk is the Responsible Area Director. The IANA Expert(s) for the registries in this document are: Yoav Nir , Rich Salz , and Nick Sullivan . The named experts have been approved previously on the March 8, 2018 Formal telechat. RFC Editor Note Section 15 mentions "values with the first byte in the range" (twice), but there is only a single byte, so these should just be "values in the range". Please also note that the traditional "IANA shall do/has done" constructions to be resolved to the past tense appear throughout the document, not just in an IANA considerations section. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Record Size Limit Extension for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-record-limit-03.txt)
The IESG has approved the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' (draft-ietf-tls-record-limit-03.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ Technical Summary This draft defines a TLS extension to negotiate the maximum size of protected records that each peers sends. This mechanism replaces the maximum fragment length extension defined in RFC 6066. It’s standards track because it updates RFC 6066, which is a Proposed Standard. Working Group Summary The draft was very well received by the WG, resulting in minimal, minor comments. Unlike other TLS-related topics, this WG settled on a solution quickly and consensus was very easily found. Document Quality This document received careful review from several participants, including pointing out some subtle edge cases and differences between TLS 1.2 and TLS 1.3 that got resolved in the document. Personnel Sean Turner is the document shepherd. Benjamin Kaduk is the responsible Area Director. RFC Editor Note Two late-breaking changes, both in Section 1: OLD Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS (DTLS) [DTLS] constrained devices can be challenging. However, NEW Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS (DTLS) [DTLS] for constrained devices can be challenging. However, OLD authenticated data until the entire record is present. Incremental processing of records could expose endpoints to the risk of forged data. NEW authenticated data until the entire record is present. Incremental processing of records exposes endpoints to the risk of forged data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Example Handshake Traces for TLS 1.3) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Example Handshake Traces for TLS 1.3' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-07-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and IVs are shown so that implementations might be checked incrementally against these values. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'Example Handshake Traces for TLS 1.3' to Informational RFC (draft-ietf-tls-tls13-vectors-07.txt)
The IESG has approved the following document: - 'Example Handshake Traces for TLS 1.3' (draft-ietf-tls-tls13-vectors-07.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ Technical Summary This document provides examples TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced with are shown. As the examples are illustrative the draft is intended to be Informational. Earlier versions of the document were widely verified against multiple implementations, and the latest version has been at least partially verified by two implementations. Working Group Summary There's always interest in having examples and this draft fills that gap for TLS, which some would say have been sorely need for a very long time. While there wasn't a lot of list traffic on this draft, you could argue that there's lots of review because the vectors are automatically generated using the NSS test suite. NSS is used to do interop with a number of implementations. Document Quality There are at least six interoperable implementations of TLS 1.3, though as mentioned above these specific test vectors have only been explicitly confirmed on a couple of them. That said, the vectors are automatically generated, and since the TLS 1.3 implementations continue to interoperate, it is expected that the accuracy of the test vectors herein are reflected in that as well. No specific role reviews were needed for this document Personnel Sean Turner is the Document Shepherd. Benjamin Kaduk is the responsible Area Director. RFC Editor Note In Section 4, please insert after the first paragraph: Note: The PSK binder uses the same construction as Finished and so is labeled as finished here. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Exported Authenticators in TLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Exported Authenticators in TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the peer. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Applying GREASE to TLS Extensibility) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Applying GREASE to TLS Extensibility' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-08-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Issues and Requirements for SNI Encryption in TLS) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Issues and Requirements for SNI Encryption in TLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-09-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a Hidden Service behind a fronting service, only disclosing the SNI of the fronting service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'Applying GREASE to TLS Extensibility' to Informational RFC (draft-ietf-tls-grease-04.txt)
The IESG has approved the following document: - 'Applying GREASE to TLS Extensibility' (draft-ietf-tls-grease-04.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ Technical Summary The GREASE (Generate Random Extensions And Sustain Extensibility) mechanism is intended to prevent extensibility failures in the TLS ecosystem. This document reserves some currently unused values for TLS implementations to advertise at random. Correctly implemented peers will ignore these values and interoperate. Peers that do not tolerate unknown values will fail to interoperate, revealing the mistake before it is widespread. Working Group Summary The concept is well understood and was reviewed and adopted by the WG. But, there's not much to the draft so there was no controversy (thankfully). Document Quality This draft has successfully been implemented in Google Chrome, and is expected to be adopted by other actors with large deployment base and interest in sustaining the maintainability of the ecosystem. Personnel Sean Turner is the Document Shepherd. Benjamin Kaduk is the Responsible AD. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'Issues and Requirements for SNI Encryption in TLS' to Informational RFC (draft-ietf-tls-sni-encryption-09.txt)
The IESG has approved the following document: - 'Issues and Requirements for SNI Encryption in TLS' (draft-ietf-tls-sni-encryption-09.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ Technical Summary This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. Working Group Summary Some working group members are not in favor of encrypting the SNI. However, the working group has consensus for continued work on the general topic of SNI encryption. Document Quality This document describes the problem and does not define a protocol. The document has been reviewed by the TLS working group. Personnel Document Shepherd: Joseph Salowey Responsible AD: Ben Kaduk ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key) to Experimental RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (TLS Certificate Compression) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS Certificate Compression' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2019-12-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7932: Brotli Compressed Data Format (Informational - IETF stream) draft-kucherawy-rfc8478bis: Zstandard Compression and the application/zstd Media Type (None - IETF stream) rfc1950: ZLIB Compressed Data Format Specification version 3.3 (Informational - Legacy stream) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key' to Experimental RFC (draft-ietf-tls-tls13-cert-with-extern-psk-07.txt)
The IESG has approved the following document: - 'TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key' (draft-ietf-tls-tls13-cert-with-extern-psk-07.txt) as Experimental RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ Technical Summary This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). Working Group Summary The document has strong support from a small number of participants in the working group. Concerns have been raised about the lack of implementation plans, but there was enough support to move this experimental draft forward. Document Quality Implementation plans are unknown, but the core of the proposal involves using a "joint in the protocol" in a usage that was envisioned in the original design; the main work is to record the specific semantics and signaling involved, to ensure interoperability. Personnel Joe Salowey is the document shepherd. Benjamin Kaduk is the responsible AD. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'TLS Certificate Compression' to Proposed Standard (draft-ietf-tls-certificate-compression-09.txt)
The IESG has approved the following document: - 'TLS Certificate Compression' (draft-ietf-tls-certificate-compression-09.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ Technical Summary This draft defines a TLS extension to compress certificate chains to reduce the amount of data transmitted and avoid some round trips. The compression algorithms defined, zlib, brotli, and zstd, are all documented in RFCs. Working Group Summary The WG process was unremarkable; the document has been around and stable for a couple years, and the idea around before that. Document Quality Google, Cloudflare, Apple, and FaceBook have implemented this extension. Firefox has also indicated they intend to prototype it. It should also be noted that others. eg., the EMU WG, are interested in this feature. Personnel Sean Turner is the document shepherd. Ben Kaduk is the responsible Area Director. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WG Review: Transport Layer Security (tls)
The Transport Layer Security (tls) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2020-03-16. Transport Layer Security (tls) --- Current status: Active WG Chairs: Christopher Wood Joseph Salowey Sean Turner Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: tls@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: https://mailarchive.ietf.org/arch/browse/tls/ Group page: https://datatracker.ietf.org/group/tls/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tls/ The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as extensions to the protocols and ciphersuites. The working group aims to achieve three goals. First, improve the applicability and suitability of the TLS family of protocols for use in emerging protocols and use cases. This includes extensions or changes that help protocols better use TLS as an authenticated key exchange protocol, or extensions that help protocols better leverage TLS security properties, such as Exported Authenticators. Extensions that focus specifically on protocol extensibility are also in scope. This goal also includes protocol changes that reduce TLS resource consumption without affecting security. Extensions that help reduce TLS handshake size meet this criterion. The second working group goal is to improve security, privacy, and deployability. This includes, for example, Delegated Credentials, Encrypted SNI, and GREASE (RFC 8701). Security and privacy goals will place emphasis on the following: - Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Application-Layer Protocol Negotiation). - Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. The third goal is to maintain current and previous version of the (D)TLS protocol as well as to specify general best practices for use of (D)TLS, extensions to (D)TLS, and cipher suites. This includes recommendations as to when a particular version should be deprecated. Changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. The working group will also place a priority in minimizing gratuitous changes to (D)TLS. Milestones: TBD ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WG Action: Rechartered Transport Layer Security (tls)
The Transport Layer Security (tls) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Transport Layer Security (tls) --- Current status: Active WG Chairs: Christopher Wood Joseph Salowey Sean Turner Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: tls@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: https://mailarchive.ietf.org/arch/browse/tls/ Group page: https://datatracker.ietf.org/group/tls/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tls/ The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as extensions to the protocols and ciphersuites. The working group aims to achieve three goals. First, improve the applicability and suitability of the TLS family of protocols for use in emerging protocols and use cases. This includes extensions or changes that help protocols better use TLS as an authenticated key exchange protocol, or extensions that help protocols better leverage TLS security properties, such as Exported Authenticators. Extensions that focus specifically on protocol extensibility are also in scope. This goal also includes protocol changes that reduce TLS resource consumption without affecting security. Extensions that help reduce TLS handshake size meet this criterion. The second working group goal is to improve security, privacy, and deployability. This includes, for example, Delegated Credentials and Encrypted SNI. Security and privacy goals will place emphasis on the following: - Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Application-Layer Protocol Negotiation). - Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. The third goal is to maintain current and previous version of the (D)TLS protocol as well as to specify general best practices for use of (D)TLS, extensions to (D)TLS, and cipher suites. This includes recommendations as to when a particular version should be deprecated. Changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. The working group will also place a priority in minimizing gratuitous changes to (D)TLS. Milestones: Jul 2020 - Submit "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" to the IESG Sep 2020 - Submit "Delegated Credentials for TLS" to the IESG Nov 2020 - Submit "TLS Ticket Requests" to the IESG Nov 2020 - Submit "A Flags Extension for TLS 1.3" to the IESG Jan 2021 - Submit "Importing External PSKs for TLS" to the IESG Mar 2021 - Submit "Encrypted Server Name Indication for TLS 1.3" to the IESG Mar 2021 - Submit "Batch Signing for TLS" to the IESG Jul 2021 - Submit "Semi-Static Diffie-Hellman Key Establishment for TLS 1.3" to the IESG Jul 2021 - Submit "Compact TLS 1.3" to the IESG Nov 2021 - Submit "Hybrid key exchange in TLS 1.3" to the IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-04-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ballot/ No IPR declarations have been submitted directly on this I-D. I-D nits notes that the abstract doesn't mention the two RFCs being updated. That is a useful practice (in case someone only sees the abstract) so we'll fix it after IETF LC. This draft normatively references RFCs 4492, 5489 and 7539 which are algorithm definitions. If needed we will put those in the DownRef registry after this last call concludes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Transport Layer Security (TLS) False Start) to Experimental RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) False Start' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-04-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an optional behavior of TLS client implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ballot/ No IPR declarations have been submitted directly on this I-D. The reference to RFC2616 should probably be updated to 7230. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-chacha20-poly1305-04.txt)
The IESG has approved the following document: - 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)' (draft-ietf-tls-chacha20-poly1305-04.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ 1. Summary This draft specifies seven (7) chacha20-poly1305 ciphers that can be used with TLS and DTLS. This is the âhow to do chacha20-poly1305 with TLSâ draft, where chacha20-poly1305 is defined in RFC 7539. These cipher suites are intended to be a back up to the AES-based suites in case of compromise. As far as where you should point your fingers: - Sean Turner is the document shepherd, and; - Stephen Farrell is the responsible Area Director. 2. Review and Consensus Thereâs probably on the order of 100 messages about this draft, and that shouldnât come as a surprise because this draft is really just specifying IANA code points. The real fireworks were on the CFRG list, and we thank them for taking that bullet(s). The cipher suites proposed in the individual draft were modified based on WG input. There were two WGLCs for this draft; the first didnât generate the expected amount of review so a second WGLC was issued that did. There was a debate as to whether the PRF digest should be changed to SHA-512 from SHA-256, but there was no consensus to make this change. 3. Intellectual Property All disclosed as confirmed by the authors on 20160310. 4. Other Points: IANA has already assigned the cipher suites and we thank them. These algorithms are expected to be very widely implemented due their high performance in software implementations. Itâs currently in the deployed branches of BoringSSL GnuTLS, OpenSSL, and others. RFC Editor Note 1) Please add the following to the end of the abstract: "This document updates RFCs 5246 and 6347." 2) Please add a normative reference for SHA256 at the end of section 3, thusly... OLD: The pseudorandom function (PRF) for all the cipher suites defined in this document is the TLS PRF with SHA-256 as the hash function. NEW: The pseudorandom function (PRF) for all the cipher suites defined in this document is the TLS PRF with SHA-256 [FIPS 180-4] as the hash function. The reference to add to section 6.1 is: [FIPS 180-4] Federal Information Processing Standards Publication (FIPS PUB) 180-4, Secure Hash Standard (SHS), August 2015. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Transport Layer Security (TLS) Cached Information Extension' to Proposed Standard (draft-ietf-tls-cached-info-23.txt)
The IESG has approved the following document: - 'Transport Layer Security (TLS) Cached Information Extension' (draft-ietf-tls-cached-info-23.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ Technical Summary This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. Working Group Summary This document has gone through a long working group process and many revisions. We believe the document has had sufficient review and is ready for publication. The TLS working group consensus around the document is not strong, as the main body of interest for this work is in the DICE group. Document Quality This document has had extensive review over a long period of time in the TLS working group. The document is a dependency of the DICE working group. Personnel Joseph Salowey is the document shepherd. The responsible AD is Stephen Farrell. IANA Note In section 8.2, please mark the value zero (0) as reserved. (As suggested by Barry Leiba in his IESG review.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Document Action: 'Transport Layer Security (TLS) False Start' to Informational RFC (draft-ietf-tls-falsestart-02.txt)
The IESG has approved the following document: - 'Transport Layer Security (TLS) False Start' (draft-ietf-tls-falsestart-02.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ 1. Summary "False Startâ was an attempt to reduce the latency impact of HTTPS based on the simple premise that the client send application data earlier in the handshake; to be precise clients send application data before they have received and verified the server's "Finishedâ message. Initial measurements showed a 30% reduction in latency [0] I could paraphrase more of s2, but the authors explained the timing and the implications at the end of s2. Note that this âexperimentâ was supported by Chrome, FF, IE, OpenSSL, NSS, and others. Some additional details: - Chrome 20 disable it except for sites that enabled NPN. - Firefox has (or at some point had) an NPN requirement to enable False Start. - Safari as an additional example without the NPN requirement: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslTransport.c - While there were patches to enable False Start with OpenSSL, it's not clear it was ever part of an official release. As far as where you should point your fingers: - Sean Turner is the document shepherd, and; - Stephen Farrell is the responsible Area Director. 2. Review and Consensus There wasnât a whole lot of discussion, primarily because "False Startâ the implementation issues were worked out by the browsers and the WG didnât adopt this draft until long after (Nov-2014). The draft was adopted because it documents existing practices and provides security considerations [0]; the comments in the WG adoption thread were incorporated in the -01 WG version. The WGâs deliberations resulted in a number of changes that more accurately reflect deployments (i.e., dropping server-side False Start) as well as restricting its use to pre-TLS1.3 (see s5.2) and cipher suites (see s5.3). One reviewer wanted all (FF-)DHE cipher suites removed because they believe that the downgrade protections defined in [1] are in adequate. To solve address this issue, the âFalse Startâ draft requires whitelists as well as large groups/curves. [0] https://mailarchive.ietf.org/arch/msg/tls/RLklpxmZ3BQRBIqWgfeUcCLhgx0 [1] https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ RFC Editor Note Please change the intended status in the header to "Informational" I don't believe any other text changes are needed. (The IESG and authors figured that informational was better during IESG eval.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-03-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards Digital Signature Algorithm (EdDSA) as authentication mechanisms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) (Informational - IRTF Stream) rfc7748: Elliptic Curves for Security (Informational - IRTF Stream) These are already be listed in the acceptable Downref Registry. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-05-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier' to Proposed Standard (draft-ietf-tls-rfc4492bis-17.txt)
The IESG has approved the following document: - 'Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier' (draft-ietf-tls-rfc4492bis-17.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ Technical Summary This document adds Elliptic Curve Cryptography (ECC) cipher suites to TLS 1.0-1.2. These cipher suites have some technical advantages over the currently defined RSA and DH/DSS cipher suites in terms of key size and performance. This document does not entail any changes to the TLS base specification. Note that Appendix B lists the changes from RFC 4492. Working Group Summary The WG was able to achieve consensus on advancing this document to Proposed Standard. Moving RFC 4492 to Standards Track was the main reason for the draft. It seemed odd to specify MTI algorithms based on ECC in TLS1.3 and have the TLS1.0-1.2 RFC for the same algorithms be Informational. Note that we needed to consult the CFRG on the "use of contexts". Our thanks to them for contributing to this work. Document Quality This is a bis draft so the majority of the draft has been reviewed by the IETF already. The -00 version of the individual draft allows easy diff to what was published as RFC 4492. Note that more was taken out than put in. Personnel Sean Turner is the Document Shepherd. Kathleen Moriarty is the responsible AD. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-07-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines several new cipher suites for the Transport Layer Security (TLS) protocol version 1.2. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES- CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' to Proposed Standard (draft-ietf-tls-ecdhe-psk-aead-05.txt)
The IESG has approved the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' (draft-ietf-tls-ecdhe-psk-aead-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ Technical Summary This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. Working Group Summary There is general support for this document in the working group. The main issues focused around trimming down the list of cipher suites to the minimum number required. Document Quality The document has been review by the TLS working group. The SecDir review triggered additional useful conversation and draft updates. Personnel Joseph Salowey is the Document Shepherd. Kathleen Moriarty is the responsible AD. IANA Note Code points are requested for existing registries. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (The SSLKEYLOGFILE Format for TLS) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The SSLKEYLOGFILE Format for TLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-04-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS]Document Action: 'The SSLKEYLOGFILE Format for TLS' to Informational RFC (draft-ietf-tls-keylogfile-02.txt)
The IESG has approved the following document: - 'The SSLKEYLOGFILE Format for TLS' (draft-ietf-tls-keylogfile-02.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ Technical Summary A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. Working Group Summary The one thing that worried some people (including your responsible AD) was the fact that this could be used as pervasive monitoring tool if this file is offloaded/shared on production systems. Numerous warnings were added to the document to not do this. As the feature is already readily available (Firefox, Chrome, Wireshark, openssl, libcurl, etc.) those who are building such monitoring devices can already do so anyway. Document Quality This is documenting a widely deployed feature that is used for development and debugging major crypto libraries and browsers (see above) Personnel The Document Shepherd for this document is Sean Turner. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-11-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8439: ChaCha20 and Poly1305 for IETF Protocols (Informational - Internet Research Task Force (IRTF) stream) rfc6962: Certificate Transparency (Experimental - Internet Engineering Task Force (IETF) stream) ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-11-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (TLS 1.2 is in Feature Freeze) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS 1.2 is in Feature Freeze' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-01-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. This document specifies that outside of urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (TLS 1.2 is in Feature Freeze) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS 1.2 is in Feature Freeze' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-02-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. This document specifies that outside of urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-tls-rfc8447bis: IANA Registry Updates for TLS and DTLS (None - Internet Engineering Task Force (IETF) stream) ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (The SSLKEYLOGFILE Format for TLS) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The SSLKEYLOGFILE Format for TLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-04-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (Deprecating Obsolete Key Exchange Methods in TLS 1.2) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating Obsolete Key Exchange Methods in TLS 1.2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-04-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6209: Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) (Informational - Internet Engineering Task Force (IETF) stream) rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - Internet Engineering Task Force (IETF) stream) ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Extended Last Call: (The SSLKEYLOGFILE Format for TLS) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The SSLKEYLOGFILE Format for TLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-05-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'IANA Registry Updates for TLS and DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-04-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comments" column to all active registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-03-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (TLS Encrypted Client Hello) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS Encrypted Client Hello' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-03-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (Return Routability Check for DTLS 1.2 and DTLS 1.3) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Return Routability Check for DTLS 1.2 and DTLS 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-06-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Protocol Action: 'TLS 1.2 is in Feature Freeze' to Proposed Standard (draft-ietf-tls-tls12-frozen-08.txt)
The IESG has approved the following document: - 'TLS 1.2 is in Feature Freeze' (draft-ietf-tls-tls12-frozen-08.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ Technical Summary Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. This document specifies that outside of urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. Working Group Summary No issues and broad consensus Informational Track was originally requested, but after discussions with IANA and the AD it was changed to Standards Track because the I-D updates registration procedures for a number of registries. Document Quality This does not define a protocol. Text is clear on IANA updates. Personnel The Document Shepherd for this document is Sean Turner. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Protocol Action: 'IANA Registry Updates for TLS and DTLS' to Proposed Standard (draft-ietf-tls-rfc8447bis-14.txt)
The IESG has approved the following document: - 'IANA Registry Updates for TLS and DTLS' (draft-ietf-tls-rfc8447bis-14.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ Technical Summary This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comments" column to all active registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. Working Group Summary The document represents consensus of the WG. The I-D was originally was an “obsoletes” I-D, i.e., it was to completely replace RFC 8447, but the WG wanted “bis” I-D instead, i.e., it includes just what needs to change. The WG felt it was easier to explain what needs to change as opposed to what was changed and needs to be changed. If the IESG is adamant that this I-D be an “obsoletes” I-D, then there will be some controversy. Document Quality N/A for an IANA only document Personnel The Document Shepherd for this document is Deirdre Connolly. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Protocol Action: 'Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings' to Proposed Standard (draft-ietf-tls-svcb-ech-08.txt)
The IESG has approved the following document: - 'Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings' (draft-ietf-tls-svcb-ech-08.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ Technical Summary To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. Working Group Summary Please note that the text in this I-D was initially developed in the DNSOP WG, went through IETF LC, and IESG review. The result of the IESG review was to take the text in this I-D out of RFC 9460 (was draft-ietf-dnsop-svcb-http) and run the new I-D through the TLS WG. The text in this I-D is essentially the same text taken from -11 of draft-ietf-dnsop-svcb-http. In some respects, you could claim that this I-D has consensus from multiple WGs. See also: https://mailarchive.ietf.org/arch/msg/tls/Vct8iUc4IgSHENX2r9IGOQFLkyk/ Document Quality This specification is implemented today by Chrome, Firefox, and Safari [1], and is deployed on all Cloudflare free tier domains [2]. [1] https://chromestatus.com/feature/6196703843581952 [2] https://blog.cloudflare.com/announcing-encrypted-client-hello Personnel The Document Shepherd for this document is Sean Turner. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (Hybrid key exchange in TLS 1.3) to Informational RFC
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Hybrid key exchange in TLS 1.3' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-07-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Document Action: 'The SSLKEYLOGFILE Format for TLS' to Informational RFC (draft-ietf-tls-keylogfile-05.txt)
The IESG has approved the following document: - 'The SSLKEYLOGFILE Format for TLS' (draft-ietf-tls-keylogfile-05.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ Technical Summary A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. Working Group Summary The one thing that worried some people (including your responsible AD) was the fact that this could be used as pervasive monitoring tool if this file is offloaded/shared on production systems. Numerous warnings were added to the document to not do this. As the feature is already readily available (Firefox, Chrome, Wireshark, openssl, libcurl, etc.) those who are building such monitoring devices can already do so anyway. An additional WGLC was done to confirm the feeling of the room at IETF 122, and no new voices objecting were heard. The IETF LC was extended by another two weeks to give people more time to raise their concens, but again no new people raised objections. Document Quality This is documenting a widely deployed feature that is used for development and debugging major crypto libraries and browsers (see above) Personnel The Document Shepherd for this document is Sean Turner. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Last Call: (TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2025-07-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC (once approved) obsoletes RFC 8773, which was an Experimental RFC. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Protocol Action: 'TLS Encrypted Client Hello' to Proposed Standard (draft-ietf-tls-esni-25.txt)
The IESG has approved the following document: - 'TLS Encrypted Client Hello' (draft-ietf-tls-esni-25.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ Technical Summary This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Working Group Summary The document has broad consensus. While there are some concerns about the ease with with this can (and is) being filtered, extension work to prevent this in the future has started and will not require changes to this document. Document Quality Draft versions of this protocol have been deployed and tested at scale. A number of vendors have implemented this protocol and tested interoperability. Some of the implementers include: Server Side - Google, Cloudflare Client Side, Firefox, Chrome There is code available several libraries including OpenSSL, BoringSSL and rustls Personnel The Document Shepherd for this document is Joseph A. Salowey. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Protocol Action: 'TLS Encrypted Client Hello' to Proposed Standard (draft-ietf-tls-esni-25.txt)
The IESG has approved the following document: - 'TLS Encrypted Client Hello' (draft-ietf-tls-esni-25.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ Technical Summary This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Working Group Summary The document has broad consensus. While there are some concerns about the ease with with this can (and is) being filtered, extension work to prevent this in the future has started and will not require changes to this document. Document Quality Draft versions of this protocol have been deployed and tested at scale. A number of vendors have implemented this protocol and tested interoperability. Some of the implementers include: Server Side - Google, Cloudflare Client Side, Firefox, Chrome There is code available several libraries including OpenSSL, BoringSSL and rustls Personnel The Document Shepherd for this document is Joseph A. Salowey. The Responsible Area Director is Paul Wouters. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
