< draft-kazuho-quic-authenticated-handshake-00.txt   draft-kazuho-quic-authenticated-handshake-01.txt >
QUIC K. Oku QUIC K. Oku
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Experimental C. Huitema Intended status: Experimental C. Huitema
Expires: June 17, 2019 Private Octopus Inc. Expires: January 6, 2020 Private Octopus Inc.
December 14, 2018 July 05, 2019
Authenticated Handshake for QUIC Authenticated Handshake for QUIC
draft-kazuho-quic-authenticated-handshake-00 draft-kazuho-quic-authenticated-handshake-01
Abstract Abstract
This document explains a variant of QUIC protocol version 1 that uses This document explains a variant of QUIC protocol version 1 that uses
the ESNI Keys to authenticate the Initial packets thereby making the the ESNI Keys to authenticate the Initial packets thereby making the
entire handshake tamper-proof. entire handshake tamper-proof.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 June 17, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Differences from QUIC version 1 . . . . . . . . . . . . . . . 3 2. Differences from QUIC version 1 . . . . . . . . . . . . . . . 3
2.1. Protocol Version Number . . . . . . . . . . . . . . . . . 3 2.1. Protocol Version Number . . . . . . . . . . . . . . . . . 3
2.2. The "QUIC-ESNI" TLS Extension . . . . . . . . . . . . . . 3 2.2. The "QUIC-AH" TLS Extension . . . . . . . . . . . . . . . 3
2.3. Initial Packet Protection . . . . . . . . . . . . . . . . 3 2.3. Initial Packet . . . . . . . . . . . . . . . . . . . . . 4
2.4. Version Negotiation Packet . . . . . . . . . . . . . . . 4 2.3.1. Mapping to Connections . . . . . . . . . . . . . . . 4
2.5. Connection Close Packet . . . . . . . . . . . . . . . . . 4 2.3.2. Protection . . . . . . . . . . . . . . . . . . . . . 4
2.6. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 5 2.3.3. Destination Connection ID . . . . . . . . . . . . . . 4
3. Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Version Negotiation Packet . . . . . . . . . . . . . . . 5
3.1. Using GCM to Authenticate Initial Packets . . . . . . . . 5 2.5. Connection Close Packet . . . . . . . . . . . . . . . . . 5
3.2. Use of Different QUIC Version Number . . . . . . . . . . 6 2.6. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Trial Decryption . . . . . . . . . . . . . . . . . . 6 3. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Rekeying at the Server's First Flight . . . . . . . . 6 3.1. Using GCM to Authenticate Initial Packets . . . . . . . . 6
3.3. No Support for Split Mode . . . . . . . . . . . . . . . . 7 3.2. Split Mode . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. Resisting the duplicate context attack . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Resisting Address Substitution Attacks . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10
B.1. Since draft-kazuho-quic-authenticated-handshake-00 . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
As defined in Secure Using TLS to Secure QUIC [QUIC-TLS], QUIC As defined in Secure Using TLS to Secure QUIC [QUIC-TLS], QUIC
version 1 [QUIC-TRANSPORT] protects the payload of every QUIC packet version 1 [QUIC-TRANSPORT] protects the payload of every QUIC packet
using AEAD making the protocol injection- and tamper-proof, with the using AEAD making the protocol injection- and tamper-proof, with the
exception being the Initial packets. Initial packets are merely exception being the Initial packets. Initial packets are merely
obfuscated because there is no shared secret between the endpoints obfuscated because there is no shared secret between the endpoints
when they start sending the Initial packets against each other. when they start sending the Initial packets against each other.
skipping to change at page 3, line 17 skipping to change at page 3, line 23
The document describes the changes from QUIC version 1. The document describes the changes from QUIC version 1.
Implementations MUST conform to the specifications of QUIC version 1 Implementations MUST conform to the specifications of QUIC version 1
unless a different behavior is defined in this document. unless a different behavior is defined in this document.
2.1. Protocol Version Number 2.1. Protocol Version Number
The long header packets exchanged using this specification carry the The long header packets exchanged using this specification carry the
QUIC version number of 0xXXXXXXXX (TBD). QUIC version number of 0xXXXXXXXX (TBD).
2.2. The "QUIC-ESNI" TLS Extension 2.2. The "QUIC-AH" TLS Extension
The QUIC-ESNI TLS Extension indicates the versions of the QUIC The QUIC-AH TLS Extension indicates the versions of QUIC supported by
protocol that the server supports. The values in the extension the server that have the authenticated handshake flavors, along with
SHOULD be identical to what would be included in the Version the versions being exposed on the wire for each of those versions.
Negotiation packet.
struct { struct {
uint32 supported_versions<4..2^16-4>; uint32 base_version;
} QUIC_ESNI; uint32 wire_versions<4..2^16-4>;
} SupportedVersion;
A server willing to accept QUIC connections using this specification struct {
MUST publish ESNI Resource Records that contain the QUIC_ESNI SupportedVersion supported_versions<8..2^16-4>;
extension including the QUIC version number 0xXXXXXXXX. } QUIC_AH;
This specification defines a variant of QUIC version 1. Therefore, a
ESNI Resource Records being published for a server providing support
for this specification MUST include a QUIC_AH extension that contains
a SupportedVersion structure with the "base_version" set to 1.
A client MUST NOT initiate a connection establishment attempt A client MUST NOT initiate a connection establishment attempt
specified in this document unless it sees a compatible version number specified in this document unless it sees a compatible base version
in the QUIC_ESNI extension of the ESNI Resource Record advertised by number in the QUIC_AH extension of the ESNI Resource Record
the server. advertised by the server.
2.3. Initial Packet Protection The "wire_versions" field indicates the version numbers to be
contained in the long header packets, for each of the base versions
that the server supports. The wire versions SHOULD be chosen at
random, as the exposure of arbitrary version numbers prevents network
devices from incorrectly assuming that the version numbers are
stable.
For each connection establishment attempt, a client SHOULD randomly
choose one wire version, and the endpoints MUST use long header
packets containing the chosen wire version throughout that connection
establishment attempt.
2.3. Initial Packet
2.3.1. Mapping to Connections
A server associates an Initial packet to an existing connection using
the Destination Connection ID, QUIC version, and the five tuple. If
all of the values match to that of an existing connection, the packet
is processed accordingly. Otherwise, a server MUST handle the packet
as potentially creating a new connection.
2.3.2. Protection
Initial packets are encrypted and authenticated differently from QUIC Initial packets are encrypted and authenticated differently from QUIC
version 1. version 1.
AES [AES] in counter (CTR) mode is used for encrypting the payload. AES [AES] in counter (CTR) mode is used for encrypting the payload.
The key and iv being used are identical to that of QUIC version 1. The key and iv being used are identical to that of QUIC version 1.
HMAC [RFC2104] is used for authenticating the header. The message HMAC [RFC2104] is used for authenticating the header. The message
being authenticated is the concatenation of the packet header without being authenticated is the concatenation of the packet header without
Header Protection and the payload in cleartext. The underlying hash Header Protection and the payload in cleartext. The underlying hash
function being used is the one selected for encrypting the Encrypted function being used is the one selected for encrypting the Encrypted
SNI extension. The HMAC key is calculated using the following SNI extension. The HMAC key is calculated using the following
formula: formula, where Zx is the extracted DH shared secret of Encrypted SNI:
hmac_key = HKDF-Expand-Label(Zx, "quic initial auth", Hash(ESNIContents), hmac_key = HKDF-Expand-Label(Zx, "quic initial auth", Hash(ESNIContents),
digest_size) digest_size)
The first sixteen (16) octets of the HMAC output replaces the The first sixteen (16) octets of the HMAC output replaces the
authentication tag of QUIC version 1. authentication tag of QUIC version 1.
Other types of packets are protected using the Packet Protection Other types of packets are protected using the Packet Protection
method defined in QUIC version 1. method defined in QUIC version 1.
2.3.3. Destination Connection ID
When establishing a connection, a client MUST initially set the
Destination Connection ID to the hashed value of the first payload of
the CRYPTO stream (i.e., the ClientHello message) truncated to first
sixteen (16) bytes. The hash function being used is the one selected
by Encrypted SNI.
When processing the first payload carried by a CRYPTO stream, a
server MUST, in addition to verifying the authentication tag, verify
that the truncated hash value of the payload is identical to the
Destination Connection ID or to the original Connection ID recovered
from the the Retry Token. A server MUST NOT create or modify
connection state if either or both the verification fails.
2.4. Version Negotiation Packet 2.4. Version Negotiation Packet
A client MUST ignore Version Negotiation packets. When the client A client MUST ignore Version Negotiation packets. When the client
gives up of establishing a connection, it MAY report the failure gives up of establishing a connection, it MAY report the failure
differently based on the receipt of (or lack of) Version Negotiation differently based on the receipt of (or lack of) Version Negotiation
packets. packets.
2.5. Connection Close Packet 2.5. Connection Close Packet
A Connection Close packet shares a long packet header with a type A Connection Close packet shares a long packet header with a type
skipping to change at page 5, line 11 skipping to change at page 6, line 14
A client that receives a Connection Close packet before an Initial A client that receives a Connection Close packet before an Initial
packet SHOULD retain the error code, and continue the connection packet SHOULD retain the error code, and continue the connection
establishment attempt as if it did not see the packet. When the establishment attempt as if it did not see the packet. When the
attempt times out, it MAY assume that the error code was a legitimate attempt times out, it MAY assume that the error code was a legitimate
value sent by the server. A client MAY ignore Connection Close value sent by the server. A client MAY ignore Connection Close
packets. packets.
2.6. Retry Packet 2.6. Retry Packet
A client SHOULD send an Initial packet in response to each Retry A client SHOULD send one Initial packet in response to each Retry
packet it receives. Payload of the CRYPTO frame contained in the packet it receives. The Destination Connection ID of the Initial
resent Initial packets MUST be identical to that of the Initial packet MUST be set to the value specified by the Retry packet,
packet that triggered the retry. When the client does not receive a however the keys for encrypting and authenticating the packet MUST
valid Initial packet after a handshake timeout, it SHOULD send at continue to be the original ones. A server sending a Retry packet is
least one Initial packet containing one of the tokens that it has expected to include the original Connection ID in the Retry Token it
received. Unless the packet gets lost, the retransmission would emits, and to use the value contained in the token attached to the
trigger the server to send either a valid Initial packet or a Retry Initial packet for unprotecting the payload.
packet.
To a server, the behavior of a client under attack would look like it Payload of the CRYPTO frame contained in the resent Initial packets
is aggressively retransmitting Initial packets, some of them MUST be identical to that of the Initial packet that triggered the
containing invalid tokens. retry.
Therefore, a server MUST NOT terminate the connection when it When the client does not receive a valid Initial packet after a
receives an Initial packet that contains an invalid token. Instead, handshake timeout, it SHOULD send an Initial packet with the
it SHOULD either process the packet as if it did not contain a token, Destination Connection ID and the token set to the original value.
or send a Retry.
A client MUST ignore Retry packets received anterior to an Initial A client MUST ignore Retry packets received anterior to an Initial
packet that successfully authenticates. packet that successfully authenticates.
3. Considerations 3. Considerations
3.1. Using GCM to Authenticate Initial Packets 3.1. Using GCM to Authenticate Initial Packets
An alternative approach to using the combination of AES-CTR and HMAC An alternative approach to using the combination of AES-CTR and HMAC
is to continue using AES-GCM. In such approach, the additional is to continue using AES-GCM. In such approach, the additional
skipping to change at page 6, line 12 skipping to change at page 7, line 12
would be hard-coded to GCM, and that some AEAD APIs might not provide would be hard-coded to GCM, and that some AEAD APIs might not provide
an interface to handle input in this particular way. an interface to handle input in this particular way.
We can also consider adding a small checksum to the Initial packets We can also consider adding a small checksum to the Initial packets
so that the server can determine if the packet is corrupt. The so that the server can determine if the packet is corrupt. The
downside is that the endpoints would be required to calculate the downside is that the endpoints would be required to calculate the
checksum for Initial packets that carry server's messages and ACKs as checksum for Initial packets that carry server's messages and ACKs as
well, even though the correctness of the packet can be verified using well, even though the correctness of the packet can be verified using
the ordinary procedure of AEAD. the ordinary procedure of AEAD.
3.2. Use of Different QUIC Version Number 3.2. Split Mode
For this specification, use of a different QUIC version number is not To support server-side deployments using "Split Mode" ([TLS-ESNI];
expected to have negative impact on user-experience by raising the section 3), the following properties need to be exchanged between the
chance of version negotiation, because version negotiation finishes fronting server and the hidden server, in addition to those generally
before the client sends it's first packet. required by a QUIC version 1 proxy and the Encrypted SNI extension:
Use of Encrypted SNI will stick out more, because it can be o hmac_key
identified by observing a different version number in the long header
packet rather than by decrypting the Initial packet to see if the
Encrypted SNI extension is in use.
The subsections below discuss alternative approaches that do not o ODCID
change the version number of QUIC.
3.2.1. Trial Decryption Both the fronting server and the hidden server need access to the
hmac_key to authenticate the Initial packets. However, because the
key is derived from the shared DH secret of ESNI, it is not
necessarily available to the hidden server.
It is possible to use the proposed Packet Protection method without ODCID is necessary to decrypt an Initial packet sent in response to a
changing the version number. The difference from the recommended Retry. However, the value is typically available only to the server
method is that the server would be required to do "trial decryption." that generates the Retry. The fronting server and the hidden server
need to exchange the ODCID, or provide the secret for extracting the
ODCID from a Retry token.
However, it is not as bad as it sounds, because authentication 4. Security Considerations
failure in AES-GCM decryption is typically reported after the
ciphertext is decrypted.
When accepting a new connection, a QUIC server can at first decrypt The authenticated handshake is designed to enable successful
the Initial packet using AES-GCM. The packet is a ordinary QUIC connections even if clients and servers are attacked by a powerful
version 1 packet if it is successfully authenticated. Otherwise, the "man on the side", which cannot delete packets but can inject packets
server will feed the decrypted payload (which would be available and will always win the race against original packets.i We want to
anyways) assuming that it contains a ClientHello message, and if the enable the following pattern: ```
TLS stack successfully processes the message returning the handshake
keys and the ESNI shared key, verify the HMAC to see if the packet
authenticates. If it does, the server creates a new connection
context and responds with an Initial packet.
3.2.2. Rekeying at the Server's First Flight Client Attacker Server
Another approach is to use the Packet Protection method of QUIC CInitial -> CInitial' -> CInitial -> <- SInitial <- SInitial' <-
version 1 for client's first flight, while using the proposed method SInitial
for all other Initial packets.
The benefit of this approach is that trial decryption can be avoided. CHandshake -> CHandshake -> ``` The goal is a successful handshake
despite injection by the attacker of fake Client Initial packet
(CInitial') or Server Initial packet (SInitial').
The downside is that a man-on-the-side attacker can stitch the The main defense against forgeries is the HMAC authentication of the
Encrypted SNI extension that the client has sent with anything it Initial packets using an ESNI derived key that is not accessible to
wants to construct a spoofed packet, then race it to the server. the attacker. This prevents all classes of attacks using forged
Initial packets. There are however two methods that are still
available to the attackers:
The server would be required to consider Initial packets containing 1) Forge an Initial packet that will claim the same context as the
non-identical ClientHello messages as belonging to different client request,
connection establishment attempts.
The design will also have negative performance impact on connections 2) Send duplicates of the client request from a fake source address.
with high latency. This is because QUIC expects clients to
retransmit the Initial packets when the latency is above 250
milliseconds. However, the requirement that the server rekeys the
Initial secret when receiving the first Initial packet means that the
retransmitted Initial packets would become undecryptable and
therefore be deemed lost by the client, reducing the client's
congestion window size.
3.3. No Support for Split Mode These two attacks and their mitigation are discussed in the next
sections.
Under the design discussed in this document, it is impossible to use 4.1. Resisting the duplicate context attack
an unmodified QUIC server as a backend server in "Split Mode"
([TLS-ESNI]; section 3) due to the following two reasons:
o Access to initial_auth_secret is required for generating and The attacker mounts a duplicate context attack by observing the
validating Initial packets. However, the backend server, not original Client Initial packet, and then creating its own Client
knowing the ESNI private key, cannot calculate the secret. Initial packet in which source and destination CID are the same as in
the original packet. The ESNI secret will be different, because the
packet is composed by the server. The goal of the attacker is to let
the server create a context associated with the CID, so that when the
original Client Initial later arrives it gets discarded.
o The client-facing server cannot continue forwarding packets to the This attack is mitigated by verifying that the Destination CID of the
correct destination when there is a change in Connection ID mid- Client Initial matches the hash of the first CRYPTO stream payload.
connection.
To address the issues, we might consider specifying a protocol that If the server uses address verification, there may be a Retry
will be used between the client-facing server and the backend server scenario: ``` Client Attacker Server
for communicating the initial_auth_secret and the spare Connection
IDs. Note that such protocol can be lightweight, assuming the
communication between the two servers will be over a virtual private
network. Such assumption can be made because the backend server
cannot operate QUIC without access to the source address-port tuple
of the packets that the client has sent.
4. Security Considerations CInitial -> <- Retry (with Token) CInitial2 (including Token) -> <-
Sinitial
TBD CHandshake -> ``` The Destination CID of the second Client Initial
packet is selected by the server, or by a device acting on behalf of
the server. This destination CID will not match the hash of the
CRYPTO stream payload. However, in the retry scenario, the server is
already rquired to know the Destination CID from the original Client
Initial packet (ODCID), because it has to echo it in the transport
parameters extension. The server can then verify that the hash of
the CRYPTO stream payload matches the ODCID.
5. IANA Considerations 4.2. Resisting Address Substitution Attacks
TBD The DCID of the original Initial packet is defined as the hash of the
first payload of the CRYPTO stream. This prevents attackers from
sending "fake" Initial packets that would be processed in the same
server connection context as the authentic packet. However, it does
not prevent address substitution attacks such as: ``` Client Attacker
Server
CInitial(from A) -> CInitial(from A') -> CInitial(from A) -> ``` In
this attack, the attacker races a copy of the Initial packet,
substituting a faked value for the client's source address. The goal
of the attack is to cause the server to associate the fake address
with the connection context, causing the connection to fail.
6. Acknowledgements The server cannot prevent this attack by just verifying the HMAC,
because the address field is not covered by the checksum
authentication. To actually mitigate the attack, the server needs to
create different connection contexts for each pair of Initial DCID
and source Address. The resulting exchange will be: ``` Client
Attacker Server
CInitial(from A) -> CInitial(A') -> <- SInitial-X(to A') CInitial(A)
-> <- SInitial-Y(to A) CHandshake-Y -> ```
The server behavior is required even if the server uses address
verification procedures, because the attacker could mount a complex
attack in which it obtains a Retry Token for its own address, then
forwards it to the client: ``` Client Attacker Server
CInitial(from A) -> CInitial(from A') -> <- Retry(to A', T(A')) <-
Retry(to A, T(A')) CInitial2(from A, T(A')) -> CInitial(from A',
T(A')) ->
CInitial(from A) ->
<- Retry(T(A)) CInitial3(from A, T(A)) -> ``` At the end of this exchange, the server will have received two valid client Initial packets that both path address verification and the ESNI based HMAC, and both have the same CRYPTO stream initial payload and the same ODCID. If it kept only one of them, the attacker would have succeeded in distrupting the connection attempt.
5. IANA Considerations
TBD TBD
7. Normative References 6. Normative References
[AES] "Advanced encryption standard (AES)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001. DOI 10.6028/nist.fips.197, November 2001.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- QUIC", draft-ietf-quic-tls-20 (work in progress), April
tls-16 (work in progress), October 2018. 2019.
[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-16 (work in progress), October 2018. transport-20 (work in progress), April 2019.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc- DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
editor.org/info/rfc2104>. editor.org/info/rfc2104>.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[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/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[TLS-ESNI] [TLS-ESNI]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft- "Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-02 (work in progress), October 2018. ietf-tls-esni-03 (work in progress), March 2019.
Appendix A. Acknowledgements
TBD
Appendix B. Change Log
B.1. Since draft-kazuho-quic-authenticated-handshake-00
o Change DCID to Hash(ClientHello) (#8)
o Describe attacks (#12)
o Describe how Initial packets are mapped to connections (#10)
o Clarify the requirements to support split mode (#11)
o Version number greasing (#13)
Authors' Addresses Authors' Addresses
Kazuho Oku Kazuho Oku
Fastly Fastly
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Email: huitema@huitema.net Email: huitema@huitema.net
 End of changes. 48 change blocks. 
128 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/