< 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/