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/