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: September 3, 2021 sn3rd | |||
January 15, 2021 | March 2, 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 September 3, 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 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 42, line 31 ¶ | skipping to change at page 42, line 31 ¶ | |||
The KEY_UPDATE_ERROR error code (0xe) is used to signal errors | The KEY_UPDATE_ERROR error code (0xe) 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 47, line 18 ¶ | skipping to change at page 47, line 18 ¶ | |||
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. 10 change blocks. | ||||
18 lines changed or deleted | 18 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/ |