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/