Re: 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 <[e-mail]>]

PS. Apologies, I failed to put the link to the new I-D at the top of
my mail. Maybe it's obvious, but it's
https://www.ietf.org/id/draft-kazuho-quic-authenticated-handshake-01.txt.

2019年7月5日(金) 17:42 Kazuho Oku <[e-mail]>:
>
> 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: <[e-mail]>
> Date: 2019年7月5日(金) 17:37
> Subject: New Version Notification for
> draft-kazuho-quic-authenticated-handshake-01.txt
> To: Kazuho Oku <[e-mail]>, Christian Huitema <[e-mail]>
>
>
>
> 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



-- 
Kazuho Oku