draft-ietf-quic-tls-34.txt | draft-ietf-quic-tls-latest.txt | |||
---|---|---|---|---|
QUIC Working Group M. Thomson, Ed. | QUIC Working Group M. Thomson, Ed. | |||
Internet-Draft Mozilla | Internet-Draft Mozilla | |||
Intended status: Standards Track S. Turner, Ed. | Intended status: Standards Track S. Turner, Ed. | |||
Expires: July 19, 2021 sn3rd | Expires: October 15, 2021 sn3rd | |||
January 15, 2021 | April 13, 2021 | |||
Using TLS to Secure QUIC | Using TLS to Secure QUIC | |||
draft-ietf-quic-tls-34 | draft-ietf-quic-tls-latest | |||
Abstract | Abstract | |||
This document describes how Transport Layer Security (TLS) is used to | This document describes how Transport Layer Security (TLS) is used to | |||
secure QUIC. | secure QUIC. | |||
Note to Readers | Note to Readers | |||
Discussion of this draft takes place on the QUIC working group | Discussion of this draft takes place on the QUIC working group | |||
mailing list (quic@ietf.org), which is archived at | mailing list (quic@ietf.org), which is archived at | |||
skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
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 July 19, 2021. | This Internet-Draft will expire on October 15, 2021. | |||
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 | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 16, line 29 ¶ | skipping to change at page 16, line 29 ¶ | |||
configured TLS implementation could negotiate TLS 1.2 or another | configured TLS implementation could negotiate TLS 1.2 or another | |||
older version of TLS. An endpoint MUST terminate the connection if a | older version of TLS. An endpoint MUST terminate the connection if a | |||
version of TLS older than 1.3 is negotiated. | version of TLS older than 1.3 is negotiated. | |||
4.3. ClientHello Size | 4.3. ClientHello Size | |||
The first Initial packet from a client contains the start or all of | The first Initial packet from a client contains the start or all of | |||
its first cryptographic handshake message, which for TLS is the | its first cryptographic handshake message, which for TLS is the | |||
ClientHello. Servers might need to parse the entire ClientHello | ClientHello. Servers might need to parse the entire ClientHello | |||
(e.g., to access extensions such as Server Name Identification (SNI) | (e.g., to access extensions such as Server Name Identification (SNI) | |||
or Application Layer Protocol Negotiation (ALPN)) in order to decide | or Application-Layer Protocol Negotiation (ALPN)) in order to decide | |||
whether to accept the new incoming QUIC connection. If the | whether to accept the new incoming QUIC connection. If the | |||
ClientHello spans multiple Initial packets, such servers would need | ClientHello spans multiple Initial packets, such servers would need | |||
to buffer the first received fragments, which could consume excessive | to buffer the first received fragments, which could consume excessive | |||
resources if the client's address has not yet been validated. To | resources if the client's address has not yet been validated. To | |||
avoid this, servers MAY use the Retry feature (see Section 8.1 of | avoid this, servers MAY use the Retry feature (see Section 8.1 of | |||
[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from | [QUIC-TRANSPORT]) to only buffer partial ClientHello messages from | |||
clients with a validated address. | clients with a validated address. | |||
QUIC packet and framing add at least 36 bytes of overhead to the | QUIC packet and framing add at least 36 bytes of overhead to the | |||
ClientHello message. That overhead increases if the client chooses a | ClientHello message. That overhead increases if the client chooses a | |||
skipping to change at page 17, line 12 ¶ | skipping to change at page 17, line 12 ¶ | |||
parameters, and other negotiable parameters and extensions could | parameters, and other negotiable parameters and extensions could | |||
cause this message to grow. | cause this message to grow. | |||
For servers, in addition to connection IDs and tokens, the size of | For servers, in addition to connection IDs and tokens, the size of | |||
TLS session tickets can have an effect on a client's ability to | TLS session tickets can have an effect on a client's ability to | |||
connect efficiently. Minimizing the size of these values increases | connect efficiently. Minimizing the size of these values increases | |||
the probability that clients can use them and still fit their entire | the probability that clients can use them and still fit their entire | |||
ClientHello message in their first Initial packet. | ClientHello message in their first Initial packet. | |||
The TLS implementation does not need to ensure that the ClientHello | The TLS implementation does not need to ensure that the ClientHello | |||
is large enough to meet the requirements for QUIC packets. QUIC | is large enough to meet QUIC's requirements for datagrams that carry | |||
PADDING frames are added to increase the size of the packet as | Initial packets; see Section 14.1 of [QUIC-TRANSPORT]. QUIC | |||
necessary; see Section 14.1 of [QUIC-TRANSPORT]. | implementations use PADDING frames or packet coalescing to ensure | |||
that datagrams are large enough. | ||||
4.4. Peer Authentication | 4.4. Peer Authentication | |||
The requirements for authentication depend on the application | The requirements for authentication depend on the application | |||
protocol that is in use. TLS provides server authentication and | protocol that is in use. TLS provides server authentication and | |||
permits the server to request client authentication. | permits the server to request client authentication. | |||
A client MUST authenticate the identity of the server. This | A client MUST authenticate the identity of the server. This | |||
typically involves verification that the identity of the server is | typically involves verification that the identity of the server is | |||
included in a certificate and that the certificate is issued by a | included in a certificate and that the certificate is issued by a | |||
skipping to change at page 21, line 6 ¶ | skipping to change at page 21, line 6 ¶ | |||
packets. Although it is in principle possible to use this feature | packets. Although it is in principle possible to use this feature | |||
for address verification, QUIC implementations SHOULD instead use the | for address verification, QUIC implementations SHOULD instead use the | |||
Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. | Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. | |||
4.8. TLS Errors | 4.8. TLS Errors | |||
If TLS experiences an error, it generates an appropriate alert as | If TLS experiences an error, it generates an appropriate alert as | |||
defined in Section 6 of [TLS13]. | defined in Section 6 of [TLS13]. | |||
A TLS alert is converted into a QUIC connection error. The | A TLS alert is converted into a QUIC connection error. The | |||
AlertDescription value is added to 0x100 to produce a QUIC error code | AlertDescription value is added to 0x0100 to produce a QUIC error | |||
from the range reserved for CRYPTO_ERROR. The resulting value is | code from the range reserved for CRYPTO_ERROR. The resulting value | |||
sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. | is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. | |||
QUIC is only able to convey an alert level of "fatal". In TLS 1.3, | QUIC is only able to convey an alert level of "fatal". In TLS 1.3, | |||
the only existing uses for the "warning" level are to signal | the only existing uses for the "warning" level are to signal | |||
connection close; see Section 6.1 of [TLS13]. As QUIC provides | connection close; see Section 6.1 of [TLS13]. As QUIC provides | |||
alternative mechanisms for connection termination and the TLS | alternative mechanisms for connection termination and the TLS | |||
connection is only closed if an error is encountered, a QUIC endpoint | connection is only closed if an error is encountered, a QUIC endpoint | |||
MUST treat any alert from TLS as if it were at the "fatal" level. | MUST treat any alert from TLS as if it were at the "fatal" level. | |||
QUIC permits the use of a generic code in place of a specific error | QUIC permits the use of a generic code in place of a specific error | |||
code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this | code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this | |||
includes replacing any alert with a generic alert, such as | includes replacing any alert with a generic alert, such as | |||
handshake_failure (0x128 in QUIC). Endpoints MAY use a generic error | handshake_failure (0x0128 in QUIC). Endpoints MAY use a generic | |||
code to avoid possibly exposing confidential information. | error code to avoid possibly exposing confidential information. | |||
4.9. Discarding Unused Keys | 4.9. Discarding Unused Keys | |||
After QUIC has completed a move to a new encryption level, packet | After QUIC has completed a move to a new encryption level, packet | |||
protection keys for previous encryption levels can be discarded. | protection keys for previous encryption levels can be discarded. | |||
This occurs several times during the handshake, as well as when keys | This occurs several times during the handshake, as well as when keys | |||
are updated; see Section 6. | are updated; see Section 6. | |||
Packet protection keys are not discarded immediately when new keys | Packet protection keys are not discarded immediately when new keys | |||
are available. If packets from a lower encryption level contain | are available. If packets from a lower encryption level contain | |||
skipping to change at page 36, line 19 ¶ | skipping to change at page 36, line 19 ¶ | |||
the change. An endpoint that notices a changed Key Phase bit updates | the change. An endpoint that notices a changed Key Phase bit updates | |||
keys and decrypts the packet that contains the changed value. | keys and decrypts the packet that contains the changed value. | |||
Initiating a key update results in both endpoints updating keys. | Initiating a key update results in both endpoints updating keys. | |||
This differs from TLS where endpoints can update keys independently. | This differs from TLS where endpoints can update keys independently. | |||
This mechanism replaces the key update mechanism of TLS, which relies | This mechanism replaces the key update mechanism of TLS, which relies | |||
on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints | on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints | |||
MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the | MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the | |||
receipt of a TLS KeyUpdate message as a connection error of type | receipt of a TLS KeyUpdate message as a connection error of type | |||
0x10a, equivalent to a fatal TLS alert of unexpected_message; see | 0x010a, equivalent to a fatal TLS alert of unexpected_message; see | |||
Section 4.8. | Section 4.8. | |||
Figure 9 shows a key update process, where the initial set of keys | Figure 9 shows a key update process, where the initial set of keys | |||
used (identified with @M) are replaced by updated keys (identified | used (identified with @M) are replaced by updated keys (identified | |||
with @N). The value of the Key Phase bit is indicated in brackets | with @N). The value of the Key Phase bit is indicated in brackets | |||
[]. | []. | |||
Initiating Peer Responding Peer | Initiating Peer Responding Peer | |||
@M [0] QUIC Packets | @M [0] QUIC Packets | |||
skipping to change at page 42, line 22 ¶ | skipping to change at page 42, line 22 ¶ | |||
limits on the use of the associated AEAD function that preserves | limits on the use of the associated AEAD function that preserves | |||
margins for confidentiality and integrity. That is, limits MUST be | margins for confidentiality and integrity. That is, limits MUST be | |||
specified for the number of packets that can be authenticated and for | specified for the number of packets that can be authenticated and for | |||
the number of packets that can fail authentication. Providing a | the number of packets that can fail authentication. Providing a | |||
reference to any analysis upon which values are based - and any | reference to any analysis upon which values are based - and any | |||
assumptions used in that analysis - allows limits to be adapted to | assumptions used in that analysis - allows limits to be adapted to | |||
varying usage conditions. | varying usage conditions. | |||
6.7. Key Update Error Code | 6.7. Key Update Error Code | |||
The KEY_UPDATE_ERROR error code (0xe) is used to signal errors | The KEY_UPDATE_ERROR error code (0x0e) is used to signal errors | |||
related to key updates. | related to key updates. | |||
7. Security of Initial Messages | 7. Security of Initial Messages | |||
Initial packets are not protected with a secret key, so they are | Initial packets are not protected with a secret key, so they are | |||
subject to potential tampering by an attacker. QUIC provides | subject to potential tampering by an attacker. QUIC provides | |||
protection against attackers that cannot read packets, but does not | protection against attackers that cannot read packets, but does not | |||
attempt to provide additional protection against attacks where the | attempt to provide additional protection against attacks where the | |||
attacker can observe and inject packets. Some forms of tampering - | attacker can observe and inject packets. Some forms of tampering -- | |||
such as modifying the TLS messages themselves - are detectable, but | such as modifying the TLS messages themselves -- are detectable, but | |||
some - such as modifying ACKs - are not. | some -- such as modifying ACKs -- are not. | |||
For example, an attacker could inject a packet containing an ACK | For example, an attacker could inject a packet containing an ACK | |||
frame that makes it appear that a packet had not been received or to | frame that makes it appear that a packet had not been received or to | |||
create a false impression of the state of the connection (e.g., by | create a false impression of the state of the connection (e.g., by | |||
modifying the ACK Delay). Note that such a packet could cause a | modifying the ACK Delay). Note that such a packet could cause a | |||
legitimate packet to be dropped as a duplicate. Implementations | legitimate packet to be dropped as a duplicate. Implementations | |||
SHOULD use caution in relying on any data that is contained in | SHOULD use caution in relying on any data that is contained in | |||
Initial packets that is not otherwise authenticated. | Initial packets that is not otherwise authenticated. | |||
It is also possible for the attacker to tamper with data that is | It is also possible for the attacker to tamper with data that is | |||
skipping to change at page 43, line 19 ¶ | skipping to change at page 43, line 19 ¶ | |||
8.1. Protocol Negotiation | 8.1. Protocol Negotiation | |||
QUIC requires that the cryptographic handshake provide authenticated | QUIC requires that the cryptographic handshake provide authenticated | |||
protocol negotiation. TLS uses Application Layer Protocol | protocol negotiation. TLS uses Application Layer Protocol | |||
Negotiation ([ALPN]) to select an application protocol. Unless | Negotiation ([ALPN]) to select an application protocol. Unless | |||
another mechanism is used for agreeing on an application protocol, | another mechanism is used for agreeing on an application protocol, | |||
endpoints MUST use ALPN for this purpose. | endpoints MUST use ALPN for this purpose. | |||
When using ALPN, endpoints MUST immediately close a connection (see | When using ALPN, endpoints MUST immediately close a connection (see | |||
Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS | Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS | |||
alert (QUIC error code 0x178; see Section 4.8) if an application | alert (QUIC error code 0x0178; see Section 4.8) if an application | |||
protocol is not negotiated. While [ALPN] only specifies that servers | protocol is not negotiated. While [ALPN] only specifies that servers | |||
use this alert, QUIC clients MUST use error 0x178 to terminate a | use this alert, QUIC clients MUST use error 0x0178 to terminate a | |||
connection when ALPN negotiation fails. | connection when ALPN negotiation fails. | |||
An application protocol MAY restrict the QUIC versions that it can | An application protocol MAY restrict the QUIC versions that it can | |||
operate over. Servers MUST select an application protocol compatible | operate over. Servers MUST select an application protocol compatible | |||
with the QUIC version that the client has selected. The server MUST | with the QUIC version that the client has selected. The server MUST | |||
treat the inability to select a compatible application protocol as a | treat the inability to select a compatible application protocol as a | |||
connection error of type 0x178 (no_application_protocol). Similarly, | connection error of type 0x0178 (no_application_protocol). | |||
a client MUST treat the selection of an incompatible application | Similarly, a client MUST treat the selection of an incompatible | |||
protocol by a server as a connection error of type 0x178. | application protocol by a server as a connection error of type | |||
0x0178. | ||||
8.2. QUIC Transport Parameters Extension | 8.2. QUIC Transport Parameters Extension | |||
QUIC transport parameters are carried in a TLS extension. Different | QUIC transport parameters are carried in a TLS extension. Different | |||
versions of QUIC might define a different method for negotiating | versions of QUIC might define a different method for negotiating | |||
transport configuration. | transport configuration. | |||
Including transport parameters in the TLS handshake provides | Including transport parameters in the TLS handshake provides | |||
integrity protection for these values. | integrity protection for these values. | |||
skipping to change at page 44, line 5 ¶ | skipping to change at page 44, line 6 ¶ | |||
The extension_data field of the quic_transport_parameters extension | The extension_data field of the quic_transport_parameters extension | |||
contains a value that is defined by the version of QUIC that is in | contains a value that is defined by the version of QUIC that is in | |||
use. | use. | |||
The quic_transport_parameters extension is carried in the ClientHello | The quic_transport_parameters extension is carried in the ClientHello | |||
and the EncryptedExtensions messages during the handshake. Endpoints | and the EncryptedExtensions messages during the handshake. Endpoints | |||
MUST send the quic_transport_parameters extension; endpoints that | MUST send the quic_transport_parameters extension; endpoints that | |||
receive ClientHello or EncryptedExtensions messages without the | receive ClientHello or EncryptedExtensions messages without the | |||
quic_transport_parameters extension MUST close the connection with an | quic_transport_parameters extension MUST close the connection with an | |||
error of type 0x16d (equivalent to a fatal TLS missing_extension | error of type 0x016d (equivalent to a fatal TLS missing_extension | |||
alert, see Section 4.8). | alert, see Section 4.8). | |||
Transport parameters become available prior to the completion of the | Transport parameters become available prior to the completion of the | |||
handshake. A server might use these values earlier than handshake | handshake. A server might use these values earlier than handshake | |||
completion. However, the value of transport parameters is not | completion. However, the value of transport parameters is not | |||
authenticated until the handshake completes, so any use of these | authenticated until the handshake completes, so any use of these | |||
parameters cannot depend on their authenticity. Any tampering with | parameters cannot depend on their authenticity. Any tampering with | |||
transport parameters will cause the handshake to fail. | transport parameters will cause the handshake to fail. | |||
Endpoints MUST NOT send this extension in a TLS connection that does | Endpoints MUST NOT send this extension in a TLS connection that does | |||
skipping to change at page 46, line 48 ¶ | skipping to change at page 47, line 4 ¶ | |||
[NAN] analyzes authenticated encryption algorithms that provide nonce | [NAN] analyzes authenticated encryption algorithms that provide nonce | |||
privacy, referred to as "Hide Nonce" (HN) transforms. The general | privacy, referred to as "Hide Nonce" (HN) transforms. The general | |||
header protection construction in this document is one of those | header protection construction in this document is one of those | |||
algorithms (HN1). Header protection is applied after the packet | algorithms (HN1). Header protection is applied after the packet | |||
protection AEAD, sampling a set of bytes ("sample") from the AEAD | protection AEAD, sampling a set of bytes ("sample") from the AEAD | |||
output and encrypting the header field using a pseudorandom function | output and encrypting the header field using a pseudorandom function | |||
(PRF) as follows: | (PRF) as follows: | |||
protected_field = field XOR PRF(hp_key, sample) | protected_field = field XOR PRF(hp_key, sample) | |||
The header protection variants in this document use a pseudorandom | The header protection variants in this document use a pseudorandom | |||
permutation (PRP) in place of a generic PRF. However, since all PRPs | permutation (PRP) in place of a generic PRF. However, since all PRPs | |||
are also PRFs [IMC], these variants do not deviate from the HN1 | are also PRFs [IMC], these variants do not deviate from the HN1 | |||
construction. | construction. | |||
As "hp_key" is distinct from the packet protection key, it follows | As "hp_key" is distinct from the packet protection key, it follows | |||
that header protection achieves AE2 security as defined in [NAN] and | that header protection achieves AE2 security as defined in [NAN] and | |||
therefore guarantees privacy of "field", the protected packet header. | therefore guarantees privacy of "field", the protected packet header. | |||
Future header protection variants based on this construction MUST use | Future header protection variants based on this construction MUST use | |||
a PRF to ensure equivalent security guarantees. | a PRF to ensure equivalent security guarantees. | |||
Use of the same key and ciphertext sample more than once risks | Use of the same key and ciphertext sample more than once risks | |||
compromising header protection. Protecting two different headers | compromising header protection. Protecting two different headers | |||
with the same key and ciphertext sample reveals the exclusive OR of | with the same key and ciphertext sample reveals the exclusive OR of | |||
the protected fields. Assuming that the AEAD acts as a PRF, if L | the protected fields. Assuming that the AEAD acts as a PRF, if L | |||
bits are sampled, the odds of two ciphertext samples being identical | bits are sampled, the odds of two ciphertext samples being identical | |||
approach 2^(-L/2), that is, the birthday bound. For the algorithms | approach 2^-L/2, that is, the birthday bound. For the algorithms | |||
described in this document, that probability is one in 2^64. | described in this document, that probability is one in 2^64. | |||
To prevent an attacker from modifying packet headers, the header is | To prevent an attacker from modifying packet headers, the header is | |||
transitively authenticated using packet protection; the entire packet | transitively authenticated using packet protection; the entire packet | |||
header is part of the authenticated additional data. Protected | header is part of the authenticated additional data. Protected | |||
fields that are falsified or modified can only be detected once the | fields that are falsified or modified can only be detected once the | |||
packet protection is removed. | packet protection is removed. | |||
9.5. Header Protection Timing Side-Channels | 9.5. Header Protection Timing Side-Channels | |||
skipping to change at page 49, line 36 ¶ | skipping to change at page 49, line 36 ¶ | |||
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, | Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, | |||
<https://www.rfc-editor.org/info/rfc8439>. | <https://www.rfc-editor.org/info/rfc8439>. | |||
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | |||
Key Derivation Function (HKDF)", RFC 5869, | Key Derivation Function (HKDF)", RFC 5869, | |||
DOI 10.17487/RFC5869, May 2010, | DOI 10.17487/RFC5869, May 2010, | |||
<https://www.rfc-editor.org/info/rfc5869>. | <https://www.rfc-editor.org/info/rfc5869>. | |||
[QUIC-RECOVERY] | [QUIC-RECOVERY] | |||
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection | Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection | |||
and Congestion Control", draft-ietf-quic-recovery-34 (work | and Congestion Control", draft-ietf-quic-recovery-latest | |||
in progress), January 2021. | (work in progress). | |||
[QUIC-TRANSPORT] | [QUIC-TRANSPORT] | |||
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
Multiplexed and Secure Transport", draft-ietf-quic- | Multiplexed and Secure Transport", draft-ietf-quic- | |||
transport-34 (work in progress), January 2021. | transport-latest (work in progress). | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||
"Randomness Requirements for Security", BCP 106, RFC 4086, | "Randomness Requirements for Security", BCP 106, RFC 4086, | |||
DOI 10.17487/RFC4086, June 2005, | DOI 10.17487/RFC4086, June 2005, | |||
<https://www.rfc-editor.org/info/rfc4086>. | <https://www.rfc-editor.org/info/rfc4086>. | |||
skipping to change at page 51, line 20 ¶ | skipping to change at page 51, line 20 ¶ | |||
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern | [IMC] Katz, J. and Y. Lindell, "Introduction to Modern | |||
Cryptography, Second Edition", ISBN 978-1466570269, | Cryptography, Second Edition", ISBN 978-1466570269, | |||
November 2014. | November 2014. | |||
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: | [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: | |||
AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp. | AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp. | |||
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019. | 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019. | |||
[QUIC-HTTP] | [QUIC-HTTP] | |||
Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 | Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 | |||
(HTTP/3)", draft-ietf-quic-http-33 (work in progress), | (HTTP/3)", draft-ietf-quic-http-latest (work in progress). | |||
January 2021. | ||||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
DOI 10.17487/RFC2818, May 2000, | DOI 10.17487/RFC2818, May 2000, | |||
<https://www.rfc-editor.org/info/rfc2818>. | <https://www.rfc-editor.org/info/rfc2818>. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
<https://www.rfc-editor.org/info/rfc5280>. | <https://www.rfc-editor.org/info/rfc5280>. | |||
skipping to change at page 57, line 51 ¶ | skipping to change at page 57, line 51 ¶ | |||
using the smaller packet size. | using the smaller packet size. | |||
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is | For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is | |||
the length of the associated data in blocks plus the length of the | the length of the associated data in blocks plus the length of the | |||
plaintext in blocks. | plaintext in blocks. | |||
For AEAD_AES_128_CCM, the total number of block cipher operations is | For AEAD_AES_128_CCM, the total number of block cipher operations is | |||
the sum of: the length of the associated data in blocks, the length | the sum of: the length of the associated data in blocks, the length | |||
of the ciphertext in blocks, the length of the plaintext in blocks, | of the ciphertext in blocks, the length of the plaintext in blocks, | |||
plus 1. In this analysis, this is simplified to a value of twice the | plus 1. In this analysis, this is simplified to a value of twice the | |||
length of the packet in blocks (that is, "2l = 2^8" for packets that | length of the packet in blocks (that is, 2l = 2^8 for packets that | |||
are limited to 2^11 bytes, or "2l = 2^13" otherwise). This | are limited to 2^11 bytes, or 2l = 2^13 otherwise). This | |||
simplification is based on the packet containing all of the | simplification is based on the packet containing all of the | |||
associated data and ciphertext. This results in a 1 to 3 block | associated data and ciphertext. This results in a 1 to 3 block | |||
overestimation of the number of operations per packet. | overestimation of the number of operations per packet. | |||
B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits | B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits | |||
[GCM-MU] specify concrete bounds for AEAD_AES_128_GCM and | [GCM-MU] specify concrete bounds for AEAD_AES_128_GCM and | |||
AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents | AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents | |||
this analysis using several simplifying assumptions: | this analysis using several simplifying assumptions: | |||
End of changes. 20 change blocks. | ||||
33 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |