Submission of QUIC-AH draft-01, with support for version number greasing (Fwd: New Version Notification for draft-kazuho-quic-authenticated-handshake-01.txt)

Kazuho Oku <kazuhooku@gmail.com> Fri, 05 July 2019 08:42 UTC

MIME-Version: 1.0
References: <156231582165.22018.291016500099755441.idtracker@ietfa.amsl.com>
In-Reply-To: <156231582165.22018.291016500099755441.idtracker@ietfa.amsl.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 05 Jul 2019 17:42:07 +0900
Message-ID: <CANatvzym7Da28HXdOtmv8GdGpPYaOyX943gv_Y=dXweFJHpwqg@mail.gmail.com>
Subject: Submission of QUIC-AH draft-01, with support for version number greasing (Fwd: New Version Notification for draft-kazuho-quic-authenticated-handshake-01.txt)
To: IETF QUIC WG <quic@ietf.org>
Cc: Christian Huitema <huitema@huitema.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vlnPLsWgxtqafOv2eUbvdOj2Tyg>
Precedence: list

Hi all,

Christian and I have submitted -01 of
draft-ietf-quic-authenticated-handshake (QUIC-AH), that descriibes a
variant of QUIC v1 that uses ESNI [1] to protect Initial packets (and
therefore the entire lifetime of a QUIC connection) from MITM attacks.

Since -00 [2], we have fixed a design flaw (pointed out by EKR), added
Considerations, and introduced the capability to advertise alternative
QUIC version numbers to be used on the wire, as we have discussed in
London [3].

Version number greasing, the new feature in -01, works as follows:

1. Alternative versions to be used on the wire is published using DNS,
through an extension of the ESNI Resource Record. ESNI requires the
Resource Record be known to the server.
2. Client that supports QUIC-AH picks one of the wire-versions found
in the ESNI RR. The obfuscation key of the Initial packet is derived
the same way as QUICv1 (i.e. from DCID).
3. The server, with the knowledge of the mapping between the versions
on the wire and the actual versions, decodes and processes the Initial
packet.

I think that this design is simple, and that it would be trivial to
implement on top of QUIC-AH (or on top of QUIC v1/TLS+ESNI, if the WG
prefers just using the version number greasing but not the
“authenticated handshake” part of the I-D).

That said, I think the broader question is how we should protect not
only the version number field but also other non-encrypted fields of
QUIC packets (e.g., payload format of Initial packet = ClientHello)
from getting ossified. I think there are three options:

a) Merely obfuscate the version number field. That's what is currently
being achieved by the draft.

b) In addition to the version numbers, advertise alternative salt
values to be used on the wire using the ESNI Resource Record. Doing so
does not prevent a middlebox from observing the content of ClientHello
(even though it cannot see the plaintext SNI), however it would
require the middlebox more work, as it needs to fetch the ESNI
Resource Record to obtain the salt. IIRC, this is analogous to what
was proposed in #2573 [4].

c) Encrypt the Initial payload [5]. ESNI provides a semi-static public
key known to the server. In case of ESNI, that key is used to encrypt
only the server name, but in case of QUIC, because the format of the
Initial packet is not yet encrypted, we have the freedom to change the
design as we would like. That would be the ultimate method to prevent
the payload of v1 CRYPTO frame from getting ossified. Though in turn,
the way the client encodes it's public key in the AH Initial packet
(most likely a particular encoding of HPKE [6]) could become an
ossification vector.

What do you think? I would appreciate it if you could give us
feedback, either on QUIC-AH in general, or on the version number
greasing design.


[1] https://tools.ietf.org/html/draft-ietf-tls-esni-03
[2] https://mailarchive.ietf.org/arch/msg/quic/DdT-gIgzxUDnSajyoMwDm1A_URQ
[3] https://github.com/quicwg/base-drafts/issues/2496
[4] https://github.com/quicwg/base-drafts/pull/2573
[5] https://github.com/kazuho/draft-kazuho-quic-authenticated-handshake/issues/9
[6] https://tools.ietf.org/html/draft-barnes-cfrg-hpke-01



---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: 2019年7月5日(金) 17:37
Subject: New Version Notification for
draft-kazuho-quic-authenticated-handshake-01.txt
To: Kazuho Oku <kazuhooku@gmail.com>, Christian Huitema <huitema@huitema.net>



A new version of I-D, draft-kazuho-quic-authenticated-handshake-01.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-quic-authenticated-handshake
Revision:       01
Title:          Authenticated Handshake for QUIC
Document date:  2019-07-05
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-quic-authenticated-handshake-01.txt
Status:
https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/
Htmlized:
https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-quic-authenticated-handshake
Diff:
https://www.ietf.org/rfcdiff?url2=draft-kazuho-quic-authenticated-handshake-01

Abstract:
   This document explains a variant of QUIC protocol version 1 that uses
   the ESNI Keys to authenticate the Initial packets thereby making the
   entire handshake tamper-proof.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



-- 
Kazuho Oku

Submission of QUIC-AH draft-01, with support for … Kazuho Oku
Re: Submission of QUIC-AH draft-01, with support … Kazuho Oku