| < draft-duke-quic-protected-initial-03.txt | draft-duke-quic-protected-initial-04.txt > | |||
|---|---|---|---|---|
| quic M. Duke | quic M. Duke | |||
| Internet-Draft F5 Networks, Inc. | Internet-Draft D. Schinazi | |||
| Intended status: Standards Track D. Schinazi | Intended status: Standards Track Google LLC | |||
| Expires: 28 April 2022 Google LLC | Expires: 29 October 2022 27 April 2022 | |||
| 25 October 2021 | ||||
| Protected QUIC Initial Packets | Protected QUIC Initial Packets | |||
| draft-duke-quic-protected-initial-03 | draft-duke-quic-protected-initial-04 | |||
| Abstract | Abstract | |||
| QUIC encrypts its Initial Packets using keys derived from well-known | QUIC encrypts its Initial Packets using keys derived from well-known | |||
| constants, meaning that observers can inspect the contents of these | constants, meaning that observers can inspect the contents of these | |||
| packets and successfully spoof them. This document proposes a new | packets and successfully spoof them. This document proposes a new | |||
| version of QUIC that encrypts Initial Packets more securely by | version of QUIC that encrypts Initial Packets more securely by | |||
| leveraging a Public Key distributed via the Domain Name System (DNS) | leveraging a Public Key distributed via the Domain Name System (DNS) | |||
| or other out-of-band system. | or other out-of-band system. | |||
| skipping to change at page 1, line 47 ¶ | skipping to change at page 1, line 46 ¶ | |||
| 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 28 April 2022. | This Internet-Draft will expire on 29 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Relationship to ECH and Version Aliasing . . . . . . . . 4 | 1.1. Relationship to ECH and Version Aliasing . . . . . . . . 4 | |||
| 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Differences with QUIC Version 1 . . . . . . . . . . . . . . . 5 | 3. Differences with QUIC Version 1 . . . . . . . . . . . . . . . 5 | |||
| 3.1. Version Number . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Version Number . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.2. Key Configuration . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Key Configuration . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.3. Key Derivation Labels . . . . . . . . . . . . . . . . . . 5 | 3.3. Key Derivation Labels . . . . . . . . . . . . . . . . . . 5 | |||
| skipping to change at page 2, line 39 ¶ | skipping to change at page 2, line 39 ¶ | |||
| 3.4.1. Encryption Context . . . . . . . . . . . . . . . . . 6 | 3.4.1. Encryption Context . . . . . . . . . . . . . . . . . 6 | |||
| 3.5. Client Packet Protection Procedure . . . . . . . . . . . 7 | 3.5. Client Packet Protection Procedure . . . . . . . . . . . 7 | |||
| 3.6. Server Packet Protection Procedure . . . . . . . . . . . 7 | 3.6. Server Packet Protection Procedure . . . . . . . . . . . 7 | |||
| 3.7. Retry Integrity Tag . . . . . . . . . . . . . . . . . . . 8 | 3.7. Retry Integrity Tag . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.9. The Fallback Packet . . . . . . . . . . . . . . . . . . . 10 | 3.9. The Fallback Packet . . . . . . . . . . . . . . . . . . . 10 | |||
| 3.10. New Transport Parameters . . . . . . . . . . . . . . . . 10 | 3.10. New Transport Parameters . . . . . . . . . . . . . . . . 10 | |||
| 3.10.1. public_key_failed . . . . . . . . . . . . . . . . . 10 | 3.10.1. public_key_failed . . . . . . . . . . . . . . . . . 10 | |||
| 3.10.2. ECHConfig . . . . . . . . . . . . . . . . . . . . . 11 | 3.10.2. ECHConfig . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 3.10.3. initial_encryption_context . . . . . . . . . . . . . 11 | 3.10.3. initial_encryption_context . . . . . . . . . . . . . 11 | |||
| 4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 12 | 4.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 12 | |||
| 4.2. Back-End Server . . . . . . . . . . . . . . . . . . . . . 12 | 4.2. Back-End Server . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 | 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6. Security and Privacy Considerations . . . . . . . . . . . . . 13 | 6. Security and Privacy Considerations . . . . . . . . . . . . . 13 | |||
| 6.1. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 13 | 6.1. Forcing Downgrade . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2. Initial Packet Injection . . . . . . . . . . . . . . . . 14 | 6.2. Initial Packet Injection . . . . . . . . . . . . . . . . 14 | |||
| 6.3. Retry Injection . . . . . . . . . . . . . . . . . . . . . 14 | 6.3. Retry Injection . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 15 | 7.1. QUIC Version Registry . . . . . . . . . . . . . . . . . . 15 | |||
| 7.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 15 | 7.2. QUIC Transport Parameter Registry . . . . . . . . . . . . 16 | |||
| 7.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 16 | 7.3. QUIC Transport Error Codes Registry . . . . . . . . . . . 16 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 16 | 8.2. Informative References . . . . . . . . . . . . . . . . . 17 | |||
| Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 | Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 | |||
| A.1. since draft-duke-quic-protected-initials-01 . . . . . . . 17 | A.1. since draft-duke-quic-protected-initials-01 . . . . . . . 18 | |||
| A.2. since draft-duke-quic-protected-initials-00 . . . . . . . 17 | A.2. since draft-duke-quic-protected-initials-00 . . . . . . . 18 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 1. Introduction | 1. Introduction | |||
| DISCLAIMER: This draft is a preliminary proposal with insufficient | DISCLAIMER: This draft is a preliminary proposal with insufficient | |||
| security analysis. It should not be used in production systems. | security analysis. It should not be used in production systems. | |||
| The QUIC Initial Packet [RFC9000] is encrypted using a key derived | The QUIC Initial Packet [RFC9000] is encrypted using a key derived | |||
| from the Destination Connection ID in the packet cleartext and a | from the Destination Connection ID in the packet cleartext and a | |||
| well-known salt (see Section 5.2 of [RFC9001]). Section 7 of that | well-known salt (see Section 5.2 of [RFC9001]). Section 7 of that | |||
| skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 5 ¶ | |||
| parameter in response to sending a public_key_failed transport | parameter in response to sending a public_key_failed transport | |||
| parameter, it MUST terminate the connection with a | parameter, it MUST terminate the connection with a | |||
| TRANSPORT_PARAMETER_ERROR. | TRANSPORT_PARAMETER_ERROR. | |||
| The client MUST NOT include the original client hello in its TLS | The client MUST NOT include the original client hello in its TLS | |||
| transcript hash for key computation, as the server has no access to | transcript hash for key computation, as the server has no access to | |||
| this message. However, the client hello is an input to the Integrity | this message. However, the client hello is an input to the Integrity | |||
| tag in the public_key_failed transport parameter, which will be in | tag in the public_key_failed transport parameter, which will be in | |||
| the transcript. | the transcript. | |||
| If any part of the client hello changes (e.g the SNI or ALPN), the | ||||
| client MUST NOT include a resumption ticket or send 0-RTT packets. | ||||
| 3.9. The Fallback Packet | 3.9. The Fallback Packet | |||
| The Fallback packet uses the 0x1 packet type code, which it shares | The Fallback packet uses the 0x1 packet type code, which it shares | |||
| with 0-RTT. Since 0-RTT is only sent by clients and Fallback is only | with 0-RTT. Since 0-RTT is only sent by clients and Fallback is only | |||
| sent by servers, these two types are distinguished by the endpoint's | sent by servers, these two types are distinguished by the endpoint's | |||
| role in the handshake. | role in the handshake. | |||
| The Fallback packet has the following format: | The Fallback packet has the following format: | |||
| Fallback Packet { | Fallback Packet { | |||
| skipping to change at page 16, line 24 ¶ | skipping to change at page 16, line 41 ¶ | |||
| Description: Attacker is forcing insecure Initial | Description: Attacker is forcing insecure Initial | |||
| Specification: This document | Specification: This document | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | [ECHO] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | |||
| Encrypted Client Hello", Work in Progress, Internet-Draft, | Encrypted Client Hello", Work in Progress, Internet-Draft, | |||
| draft-ietf-tls-esni-13, 12 August 2021, | draft-ietf-tls-esni-14, 13 February 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | |||
| esni-13>. | esni-14>. | |||
| [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, | [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, | |||
| "Hybrid Public Key Encryption", Work in Progress, | "Hybrid Public Key Encryption", Work in Progress, | |||
| Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, | Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- | <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- | |||
| hpke-12>. | hpke-12>. | |||
| [I-D.ietf-quic-version-negotiation] | [I-D.ietf-quic-version-negotiation] | |||
| Schinazi, D. and E. Rescorla, "Compatible Version | Schinazi, D. and E. Rescorla, "Compatible Version | |||
| Negotiation for QUIC", Work in Progress, Internet-Draft, | Negotiation for QUIC", Work in Progress, Internet-Draft, | |||
| draft-ietf-quic-version-negotiation-04, 26 May 2021, | draft-ietf-quic-version-negotiation-07, 5 April 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| version-negotiation-04>. | version-negotiation-07>. | |||
| [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| Multiplexed and Secure Transport", RFC 9000, | Multiplexed and Secure Transport", RFC 9000, | |||
| DOI 10.17487/RFC9000, May 2021, | DOI 10.17487/RFC9000, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc9000>. | <https://www.rfc-editor.org/rfc/rfc9000>. | |||
| [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | |||
| QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, | QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc9001>. | <https://www.rfc-editor.org/rfc/rfc9001>. | |||
| skipping to change at page 17, line 26 ¶ | skipping to change at page 17, line 44 ¶ | |||
| Agility and Selecting Mandatory-to-Implement Algorithms", | Agility and Selecting Mandatory-to-Implement Algorithms", | |||
| BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, | BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, | |||
| <https://www.rfc-editor.org/rfc/rfc7696>. | <https://www.rfc-editor.org/rfc/rfc7696>. | |||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
| <https://www.rfc-editor.org/rfc/rfc8446>. | <https://www.rfc-editor.org/rfc/rfc8446>. | |||
| [VERSION-ALIASING] | [VERSION-ALIASING] | |||
| Duke, M., "QUIC Version Aliasing", Work in Progress, | Duke, M., "QUIC Version Aliasing", Work in Progress, | |||
| Internet-Draft, draft-duke-quic-version-aliasing-06, 13 | Internet-Draft, draft-duke-quic-version-aliasing-07, 25 | |||
| May 2021, <https://datatracker.ietf.org/doc/html/draft- | October 2021, <https://datatracker.ietf.org/doc/html/ | |||
| duke-quic-version-aliasing-06>. | draft-duke-quic-version-aliasing-07>. | |||
| Appendix A. Change Log | Appendix A. Change Log | |||
| *RFC Editor's Note:* Please remove this section prior to | *RFC Editor's Note:* Please remove this section prior to | |||
| publication of a final version of this document. | publication of a final version of this document. | |||
| A.1. since draft-duke-quic-protected-initials-01 | A.1. since draft-duke-quic-protected-initials-01 | |||
| * Redesigned fallback again without Version Negotiation | * Redesigned fallback again without Version Negotiation | |||
| skipping to change at page 18, line 4 ¶ | skipping to change at page 18, line 22 ¶ | |||
| * Additional text comparing ECH, Version Aliasing | * Additional text comparing ECH, Version Aliasing | |||
| * Adapted to foreground the split-mode use case | * Adapted to foreground the split-mode use case | |||
| * Clarified server initials are encrypted | * Clarified server initials are encrypted | |||
| * Retry keys are no longer generated from the shared secret | * Retry keys are no longer generated from the shared secret | |||
| * Complete Rewrite of Fallback | * Complete Rewrite of Fallback | |||
| * New transport parameters | * New transport parameters | |||
| * Added crypto agility | * Added crypto agility | |||
| Authors' Addresses | Authors' Addresses | |||
| Martin Duke | Martin Duke | |||
| F5 Networks, Inc. | Google LLC | |||
| Email: martin.h.duke@gmail.com | Email: martin.h.duke@gmail.com | |||
| David Schinazi | David Schinazi | |||
| Google LLC | Google LLC | |||
| 1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
| Mountain View, California 94043, | Mountain View, California 94043, | |||
| United States of America | United States of America | |||
| Email: dschinazi.ietf@gmail.com | Email: dschinazi.ietf@gmail.com | |||
| End of changes. 19 change blocks. | ||||
| 26 lines changed or deleted | 27 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||