Re: QUIC Version Negotiation Extension

David Schinazi <dschinazi.ietf@gmail.com> Mon, 04 November 2019 23:13 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D21F120A74 for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 15:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_lRYXSxoWRY for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 15:13:29 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFA6120AC2 for <quic@ietf.org>; Mon, 4 Nov 2019 15:13:28 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id y6so13580167lfj.2 for <quic@ietf.org>; Mon, 04 Nov 2019 15:13:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fls9EfnmSmVdtSTNeBYwT2f7KLcnOyxd2gUxO9iqpyk=; b=jp/VkIXdwdgOO/9ye2Ee0goCFvLA9d9G59TQ5xrazHykixGyW7o5vSqsW0LwM3bHg0 E2ZTiL0beRFq3+ZYUMfS4NaknqAti91hc/jOhMSG+uE8mNYlnFSQK4SmuIndJnZv4BUH R3xo+OFgZrjOhUSxqKdW78Mwif1+aAfdgGT48ICXD5NxdsuKS5dRzbekKEgbbQNJT3Db QgNOb+uVClQi44HWUloAyzXmo2muBLf6bSDF2VoLd7UFybajoz12DsBS5wWNTnJVRD2G EPMi8p2e9lD9dsXG/Dqr39PnJWnl6CfmYj3AbzVimWgp9KmuL7CuDnQ8zlVhPvcocw8y ja3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fls9EfnmSmVdtSTNeBYwT2f7KLcnOyxd2gUxO9iqpyk=; b=LV1knZkCmLPFwh32psSbClWEJ3F9jCH/w+fgwCRaNjyhCvYNo+lfFFLpMJspEhLdbc vEInV9tqQ91fs3oEf8Y+O1Xqry/BdIhZT8kONokcnYvDksjn+9BBUQtrZlStMG2CXgOo plG8v5BwlwVse3UrwvlJVSQMQvtsGn7JkeeSPUqbxl0YbNaYrbPPTC6BhHrFxdXSEQ+1 T10l3nrpr/6fWfAGX5LbotI+Sr8FNzQDEJlkxRXOmitBSxp3aaI4FR1DkqkZ8n10Z8JU qrjF4n1XZTEwo1RE7MJ3GZGivZy8hn9fwu8ljKg0SVYY/TJm5/pUXNECD2BjNcIi7BWf 0pPw==
X-Gm-Message-State: APjAAAWW2VakKKqywxp/YCboNufl829/+adKQluyZRGmjrcu1KE7PpLq Ue0ik2u8K89PNYf8WX9/boOdZrrVKuANMjtC2y8=
X-Google-Smtp-Source: APXvYqxD3+A5ZDiDF4mgttfcOSlFHIVj5mFAv9YhqmJTJSyHYScccdfiHF3azlcLAm6/3KMsx4Sg5SF8WUwG77XLdR4=
X-Received: by 2002:ac2:434c:: with SMTP id o12mr18720673lfl.33.1572909206881; Mon, 04 Nov 2019 15:13:26 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com> <CAN1APdcZv-MtwRT77++r6EKdzJUc1NKEJfY4CZeOSaK50nPZYg@mail.gmail.com> <CAPDSy+5obMbiLDKYKXXg1ZthoMqyg60KD+6HR69CQqiEHb6W7g@mail.gmail.com> <CAN1APdence3-Hme+q-B_tasXJJpdxMqFpYFuR0gOgM8tMc-HNQ@mail.gmail.com> <CAPDSy+6y2gQmiCdLhVXXU3d0ER=mt7+R0s5cA=EAH3HfT+k_JA@mail.gmail.com> <CAN1APdczRvpargzKELJXOgYg1Yp+iv-5v_7RbvJZMWNHFDqCrw@mail.gmail.com>
In-Reply-To: <CAN1APdczRvpargzKELJXOgYg1Yp+iv-5v_7RbvJZMWNHFDqCrw@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 4 Nov 2019 15:13:15 -0800
Message-ID: <CAPDSy+4pzQTL_+NCLJ6HA9mLXYXNxFVMuK6o0MPRaSnD5fhr=w@mail.gmail.com>
Subject: Re: QUIC Version Negotiation Extension
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Cc: QUIC <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008a4ac705968d76ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i6Vc7FbAXs4A01ykppXPpn0UN14>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 23:13:35 -0000

On Mon, Nov 4, 2019 at 3:07 PM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
wrote:

> Yes all lists of versions are ordered.
>>
>> I might have missed it, but otherwise I think this should be mentioned
>> explicitly.
>>
> Isn't it mentioned in the definitions of these fields?
>
> Yes, rereading that passage, it does mention order.
>
>
>>> - It is tempting to just hash the received version list, but that
>>> requires agreeing on an algorithm, unless the algorithm is stated to be
>>> specific to that version, which is complicated.
>>>
>>
>> Which list are you referring to? For all the ones in the draft, the peer
>> needs access to all the elements so I don't think a hash would help.
>>
>> I am referring the received list. The client receives the list. The
>> server (modulo redeployment/routing) knows its own list and does not need
>> to read it, it just needs proof that the response matches what it initially
>> sent. This could be done with a hash. (If I understand correctly). But
>> maybe not because the list is filtered by clients input so that would be
>> many hashes to track.
>>
> I don't know what the received list is, there's nothing with that name in
> the draft.
>
>
> Received Negotiation Version Count + following element
>
>
Those are received by the server. And the server needs to access all the
the versions there in case it randomizes the reserved versions or has
different versions on different servers in the fleet.

> The current design of connection IDs does not guarantee consistent routing
> on client-generated server connection IDs, so I don't think we can rely on
> it.
>
> So this is where I’m not 100% on how it works, but VNEG packet does, at
> least in principle, allow for a return destination CID, so the next Initial
> packet can use that destination instead of a random original CID. And
> likewise, if the response is not via VNEG, the servers initial can the same
> (on known versions).
>
Version Negotiation packets MUST use the same CIDs as the client's initial.

> I think QUICv3 should also provide this property, otherwise it'll be
> likely to be unsafe. If a future version doesn't have authenticated
> transport parameters then we'll have to create a separate downgrade
> prevention mechanism. But we can cross that bridge when we get there.
>
> Sure, but perhaps mention in Security Considerations, that the design
> depends on this, if it is not considered blatantly obvious.
>
I'll admit I thought this was obvious, since it relies on transport
parameters. We'll take a PR though.

> It sounds like we could be clearer. Would you be able to send us a PR?
>
> I’ll consider, but I’m stretched a bit thin as it is.
>