draft-ietf-uta-rfc7525bis-01.txt   draft-ietf-uta-rfc7525bis-02.txt 
UTA Working Group Y. Sheffer UTA Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Obsoletes: 7525 (if approved) R. Holz Obsoletes: 7525 (if approved) R. Holz
Updates: 5288, 6066 (if approved) University of Twente Updates: 5288, 6066 (if approved) University of Twente
Intended status: Best Current Practice P. Saint-Andre Intended status: Best Current Practice P. Saint-Andre
Expires: 8 January 2022 Mozilla Expires: 1 March 2022 Mozilla
T. Fossati T. Fossati
arm arm
7 July 2021 28 August 2021
Recommendations for Secure Use of Transport Layer Security (TLS) and Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) Datagram Transport Layer Security (DTLS)
draft-ietf-uta-rfc7525bis-01 draft-ietf-uta-rfc7525bis-02
Abstract Abstract
Transport Layer Security (TLS) and Datagram Transport Layer Security Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are widely used to protect data exchanged over application (DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
last few years, several serious attacks on TLS have emerged, last few years, several serious attacks on TLS have emerged,
including attacks on its most commonly used cipher suites and their including attacks on its most commonly used cipher suites and their
modes of operation. This document provides recommendations for modes of operation. This document provides recommendations for
improving the security of deployed services that use TLS and DTLS. improving the security of deployed services that use TLS and DTLS.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 January 2022. This Internet-Draft will expire on 1 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 50 skipping to change at page 2, line 50
4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14 4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14
4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15
4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15 4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15
4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16 4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16
5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17
5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18 6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18
6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19 6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19
6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20
6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21 6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21
6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22 6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32
Appendix B. Document History . . . . . . . . . . . . . . . . . . 33 Appendix B. Document History . . . . . . . . . . . . . . . . . . 33
B.1. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33 B.1. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33
B.2. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 33 B.2. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33
B.3. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34 B.3. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34
B.4. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34 B.4. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34
B.5. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Transport Layer Security (TLS) [RFC5246] and Datagram Transport
Security Layer (DTLS) [RFC6347] are widely used to protect data Security Layer (DTLS) [RFC6347] are widely used to protect data
exchanged over application protocols such as HTTP, SMTP, IMAP, POP, exchanged over application protocols such as HTTP, SMTP, IMAP, POP,
SIP, and XMPP. Over the years leading to 2015, several serious SIP, and XMPP. Over the years leading to 2015, several serious
attacks on TLS have emerged, including attacks on its most commonly attacks on TLS have emerged, including attacks on its most commonly
used cipher suites and their modes of operation. For instance, both used cipher suites and their modes of operation. For instance, both
skipping to change at page 3, line 47 skipping to change at page 3, line 48
* A new protocol version was released, TLS 1.3 [RFC8446], which * A new protocol version was released, TLS 1.3 [RFC8446], which
largely mitigates or resolves these attacks. largely mitigates or resolves these attacks.
Those who implement and deploy TLS and DTLS, in particular versions Those who implement and deploy TLS and DTLS, in particular versions
1.2 or earlier of these protocols, need guidance on how TLS can be 1.2 or earlier of these protocols, need guidance on how TLS can be
used securely. This document provides guidance for deployed services used securely. This document provides guidance for deployed services
as well as for software implementations, assuming the implementer as well as for software implementations, assuming the implementer
expects his or her code to be deployed in environments defined in expects his or her code to be deployed in environments defined in
Section 5. Concerning deployment, this document targets a wide Section 5. Concerning deployment, this document targets a wide
audience - namely, all deployers who wish to add authentication (be audience -- namely, all deployers who wish to add authentication (be
it one-way only or mutual), confidentiality, and data integrity it one-way only or mutual), confidentiality, and data integrity
protection to their communications. protection to their communications.
The recommendations herein take into consideration the security of The recommendations herein take into consideration the security of
various mechanisms, their technical maturity and interoperability, various mechanisms, their technical maturity and interoperability,
and their prevalence in implementations at the time of writing. and their prevalence in implementations at the time of writing.
Unless it is explicitly called out that a recommendation applies to Unless it is explicitly called out that a recommendation applies to
TLS alone or to DTLS alone, each recommendation applies to both TLS TLS alone or to DTLS alone, each recommendation applies to both TLS
and DTLS. and DTLS.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
mistaken for a message for use in another protocol, servers should mistaken for a message for use in another protocol, servers should
strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:
"In the event that the server supports no protocols that the client "In the event that the server supports no protocols that the client
advertises, then the server SHALL respond with a fatal advertises, then the server SHALL respond with a fatal
"no_application_protocol" alert." It is also RECOMMENDED that "no_application_protocol" alert." It is also RECOMMENDED that
clients abort the handshake if the server acknowledges the ALPN clients abort the handshake if the server acknowledges the ALPN
extension, but does not select a protocol from the client list. extension, but does not select a protocol from the client list.
Failure to do so can result in attacks such those described in Failure to do so can result in attacks such those described in
[ALPACA]. [ALPACA].
Protocol developers are strongly encouraged to register an ALPN
identifier for their protocols. This applies to new protocols, as
well as well-established protocols such as SMTP.
3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3
The 0-RTT early data feature is new in TLS 1.3. It provides improved The 0-RTT early data feature is new in TLS 1.3. It provides improved
latency when TLS connections are resumed, at the potential cost of latency when TLS connections are resumed, at the potential cost of
security. As a result, it requires special attention from security. As a result, it requires special attention from
implementers on both the server and the client side. Typically this implementers on both the server and the client side. Typically this
extends to both the TLS library as well as protocol layers above it. extends to both the TLS library as well as protocol layers above it.
For use in HTTP-over-TLS, readers are referred to [RFC8470] for For use in HTTP-over-TLS, readers are referred to [RFC8470] for
guidance. guidance.
skipping to change at page 15, line 15 skipping to change at page 15, line 15
4.4. Limits on Key Usage 4.4. Limits on Key Usage
All ciphers have an upper limit on the amount of traffic that can be All ciphers have an upper limit on the amount of traffic that can be
securely encrypted with any given key. In the case of AEAD cipher securely encrypted with any given key. In the case of AEAD cipher
suites, the limit is typically determined by the cipher's integrity suites, the limit is typically determined by the cipher's integrity
guarantees. When the amount of traffic for a particular connection guarantees. When the amount of traffic for a particular connection
has reached the limit, an implementation SHOULD perform a new has reached the limit, an implementation SHOULD perform a new
handshake (or in TLS 1.3, a Key Update) to rotate the session key. handshake (or in TLS 1.3, a Key Update) to rotate the session key.
For all AES-GCM cipher suites recommended for TLS 1.2 in this For all AES-GCM cipher suites recommended for TLS 1.2 in this
document, the limit for one connection is 2^(24.5) full-size records document, the limit for one connection is 2^24.5 full-size records
(about 24 million). This is the same number as for TLS 1.3 with the (about 24 million). This is the same number as for TLS 1.3 with the
equivalent cipher suites. equivalent cipher suites.
// TODO: refer to {{I-D.irtf-cfrg-aead-limits}} once it has added the // TODO: refer to {{I-D.irtf-cfrg-aead-limits}} once it has added the
// derivation for TLS 1.2, which is different from TLS 1.3. // derivation for TLS 1.2, which is different from TLS 1.3.
// Different derivation, same numbers. // Different derivation, same numbers.
For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of
[RFC8446]. [RFC8446].
skipping to change at page 15, line 38 skipping to change at page 15, line 38
When using the cipher suites recommended in this document, two public When using the cipher suites recommended in this document, two public
keys are normally used in the TLS handshake: one for the Diffie- keys are normally used in the TLS handshake: one for the Diffie-
Hellman key agreement and one for server authentication. Where a Hellman key agreement and one for server authentication. Where a
client certificate is used, a third public key is added. client certificate is used, a third public key is added.
With a key exchange based on modular exponential (MODP) Diffie- With a key exchange based on modular exponential (MODP) Diffie-
Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048
bits are REQUIRED. bits are REQUIRED.
Rationale: For various reasons, in practice, DH keys are typically Rationale: For various reasons, in practice, DH keys are typically
generated in lengths that are powers of two (e.g., 2^(10) = 1024 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits,
bits, 2^(11) = 2048 bits, 2^(12) = 4096 bits). Because a DH key of 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits
1228 bits would be roughly equivalent to only an 80-bit symmetric key would be roughly equivalent to only an 80-bit symmetric key
[RFC3766], it is better to use keys longer than that for the "DHE" [RFC3766], it is better to use keys longer than that for the "DHE"
family of cipher suites. A DH key of 1926 bits would be roughly family of cipher suites. A DH key of 1926 bits would be roughly
equivalent to a 100-bit symmetric key [RFC3766]. A DH key of 2048 equivalent to a 100-bit symmetric key [RFC3766]. A DH key of 2048
bits (equivalent to a 112-bit symmetric key) is the minimum allowed bits (equivalent to a 112-bit symmetric key) is the minimum allowed
by the latest revision of [NIST.SP.800-56A], as of this writing (see by the latest revision of [NIST.SP.800-56A], as of this writing (see
in particular Appendix D). in particular Appendix D).
As noted in [RFC3766], correcting for the emergence of a TWIRL As noted in [RFC3766], correcting for the emergence of a TWIRL
machine would imply that 1024-bit DH keys yield about 65 bits of machine would imply that 1024-bit DH keys yield about 65 bits of
equivalent strength and that a 2048-bit DH key would yield about 92 equivalent strength and that a 2048-bit DH key would yield about 92
skipping to change at page 16, line 21 skipping to change at page 16, line 21
With regard to ECDH keys, implementers are referred to the IANA With regard to ECDH keys, implementers are referred to the IANA
"Supported Groups Registry" (former "EC Named Curve Registry"), "Supported Groups Registry" (former "EC Named Curve Registry"),
within the "Transport Layer Security (TLS) Parameters" registry within the "Transport Layer Security (TLS) Parameters" registry
[IANA_TLS], and in particular to the "recommended" groups. Curves of [IANA_TLS], and in particular to the "recommended" groups. Curves of
less than 224 bits MUST NOT be used. This recommendation is in-line less than 224 bits MUST NOT be used. This recommendation is in-line
with the latest revision of [NIST.SP.800-56A]. with the latest revision of [NIST.SP.800-56A].
When using RSA, servers SHOULD authenticate using certificates with When using RSA, servers SHOULD authenticate using certificates with
at least a 2048-bit modulus for the public key. In addition, the use at least a 2048-bit modulus for the public key. In addition, the use
of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for of the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST
more details). Clients SHOULD indicate to servers that they request NOT be used (see [CAB-Baseline] for more details). Clients MUST
SHA-256, by using the "Signature Algorithms" extension defined in TLS indicate to servers that they request SHA-256, by using the
1.2. "Signature Algorithms" extension defined in TLS 1.2.
4.6. Truncated HMAC 4.6. Truncated HMAC
Implementations MUST NOT use the Truncated HMAC extension, defined in Implementations MUST NOT use the Truncated HMAC extension, defined in
Section 7 of [RFC6066]. Section 7 of [RFC6066].
Rationale: the extension does not apply to the AEAD cipher suites Rationale: the extension does not apply to the AEAD cipher suites
recommended above. However it does apply to most other TLS cipher recommended above. However it does apply to most other TLS cipher
suites. Its use has been shown to be insecure in [PatersonRS11]. suites. Its use has been shown to be insecure in [PatersonRS11].
skipping to change at page 19, line 36 skipping to change at page 19, line 36
certification path in accordance with [RFC5280] (see also [RFC6125]). certification path in accordance with [RFC5280] (see also [RFC6125]).
6.2. AES-GCM 6.2. AES-GCM
Section 4.2 above recommends the use of the AES-GCM authenticated Section 4.2 above recommends the use of the AES-GCM authenticated
encryption algorithm. Please refer to Section 11 of [RFC5246] for encryption algorithm. Please refer to Section 11 of [RFC5246] for
general security considerations when using TLS 1.2, and to Section 6 general security considerations when using TLS 1.2, and to Section 6
of [RFC5288] for security considerations that apply specifically to of [RFC5288] for security considerations that apply specifically to
AES-GCM when used with TLS. AES-GCM when used with TLS.
6.2.1. Nonce Reuse in TLS 1.2 6.2.1. Nonce Reuse in TLS 1.2
The existence of deployed TLS stacks that mistakenly reuse the AES- The existence of deployed TLS stacks that mistakenly reuse the AES-
GCM nonce is documented in [Boeck2016], showing there is an actual GCM nonce is documented in [Boeck2016], showing there is an actual
risk of AES-GCM getting implemented in an insecure way and thus risk of AES-GCM getting implemented in an insecure way and thus
making TLS sessions that use an AES-GCM cipher suite vulnerable to making TLS sessions that use an AES-GCM cipher suite vulnerable to
attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE- attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-
2016-10213, CVE-2016-10212, CVE-2017-5933.) 2016-10213, CVE-2016-10212, CVE-2017-5933.)
While this problem has been fixed in TLS 1.3, which enforces a While this problem has been fixed in TLS 1.3, which enforces a
deterministic method to generate nonces from record sequence numbers deterministic method to generate nonces from record sequence numbers
skipping to change at page 24, line 8 skipping to change at page 24, line 8
and Orit Levin as the working group chairs and Pete Resnick as the and Orit Levin as the working group chairs and Pete Resnick as the
sponsoring Area Director. sponsoring Area Director.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-httpbis-semantics] [I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-16, 27 May 2021, httpbis-semantics-18, 18 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-httpbis- <https://www.ietf.org/archive/id/draft-ietf-httpbis-
semantics-16.txt>. semantics-18.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://www.ietf.org/archive/id/draft-ietf-tls-
dtls13-43.txt>. dtls13-43.txt>.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
skipping to change at page 27, line 32 skipping to change at page 27, line 32
[Heninger2012] [Heninger2012]
Heninger, N., Durumeric, Z., Wustrow, E., and J.A. Heninger, N., Durumeric, Z., Wustrow, E., and J.A.
Halderman, "Mining Your Ps and Qs: Detection of Widespread Halderman, "Mining Your Ps and Qs: Detection of Widespread
Weak Keys in Network Devices", Usenix Security Weak Keys in Network Devices", Usenix Security
Symposium 2012, 2012. Symposium 2012, 2012.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-11, 14 June 2021, draft-ietf-tls-esni-13, 12 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-esni- <https://www.ietf.org/archive/id/draft-ietf-tls-esni-
11.txt>. 13.txt>.
[I-D.irtf-cfrg-aead-limits] [I-D.irtf-cfrg-aead-limits]
G√ľnther, F., Thomson, M., and C. A. Wood, "Usage Limits on G√ľnther, F., Thomson, M., and C. A. Wood, "Usage Limits on
AEAD Algorithms", Work in Progress, Internet-Draft, draft- AEAD Algorithms", Work in Progress, Internet-Draft, draft-
irtf-cfrg-aead-limits-02, 22 February 2021, irtf-cfrg-aead-limits-03, 12 July 2021,
<https://www.ietf.org/archive/id/draft-irtf-cfrg-aead- <https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-
limits-02.txt>. limits-03.txt>.
[IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters", [IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters",
<http://www.iana.org/assignments/tls-parameters>. <http://www.iana.org/assignments/tls-parameters>.
[Joux2006] Joux, A., "Authentication Failures in NIST version of [Joux2006] Joux, A., "Authentication Failures in NIST version of
GCM", 2006, <https://csrc.nist.gov/csrc/media/projects/ GCM", 2006, <https://csrc.nist.gov/csrc/media/projects/
block-cipher-techniques/documents/bcm/comments/800-38- block-cipher-techniques/documents/bcm/comments/800-38-
series-drafts/gcm/joux_comments.pdf>. series-drafts/gcm/joux_comments.pdf>.
[Kleinjung2010] [Kleinjung2010]
skipping to change at page 33, line 18 skipping to change at page 33, line 18
- SHOULD-level requirement for forward secrecy in TLS 1.3 session - SHOULD-level requirement for forward secrecy in TLS 1.3 session
resumption. resumption.
- Generic SHOULD-level guidance to avoid 0-RTT unless it is - Generic SHOULD-level guidance to avoid 0-RTT unless it is
documented for the particular protocol. documented for the particular protocol.
Appendix B. Document History Appendix B. Document History
// Note to RFC Editor: please remove before publication. // Note to RFC Editor: please remove before publication.
B.1. draft-ietf-uta-rfc7525bis-01 B.1. draft-ietf-uta-rfc7525bis-02
* Adjusted text about ALPN support in application protocols
* Incorporated text from draft-ietf-tls-md5-sha1-deprecate
B.2. draft-ietf-uta-rfc7525bis-01
* Many more changes, including: * Many more changes, including:
- SHOULD-level requirement for forward secrecy in TLS 1.3 session - SHOULD-level requirement for forward secrecy in TLS 1.3 session
resumption. resumption.
- Removed TLS 1.2 capabilities: renegotiation, compression. - Removed TLS 1.2 capabilities: renegotiation, compression.
- Specific guidance for multiplexed protocols. - Specific guidance for multiplexed protocols.
skipping to change at page 33, line 43 skipping to change at page 34, line 5
documented for the particular protocol. documented for the particular protocol.
- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2.
- SHOULD NOT use static DH keys or reuse ephemeral DH keys across - SHOULD NOT use static DH keys or reuse ephemeral DH keys across
multiple connections. multiple connections.
- 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from - 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from
192. 192.
B.2. draft-ietf-uta-rfc7525bis-00 B.3. draft-ietf-uta-rfc7525bis-00
* Renamed: WG document. * Renamed: WG document.
* Started populating list of changes from RFC 7525. * Started populating list of changes from RFC 7525.
* General rewording of abstract and intro for revised version. * General rewording of abstract and intro for revised version.
* Protocol versions, fallback. * Protocol versions, fallback.
* Reference to ECHO. * Reference to ECHO.
B.3. draft-sheffer-uta-rfc7525bis-00 B.4. draft-sheffer-uta-rfc7525bis-00
* Renamed, since the BCP number does not change. * Renamed, since the BCP number does not change.
* Added an empty "Differences from RFC 7525" section. * Added an empty "Differences from RFC 7525" section.
B.4. draft-sheffer-uta-bcp195bis-00 B.5. draft-sheffer-uta-bcp195bis-00
* Initial release, the RFC 7525 text as-is, with some minor * Initial release, the RFC 7525 text as-is, with some minor
editorial changes to the references. editorial changes to the references.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
Email: yaronf.ietf@gmail.com Email: yaronf.ietf@gmail.com
 End of changes. 22 change blocks. 
29 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/