Re: QUIC Version Negotiation Extension

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 04 November 2019 23:07 UTC

Return-Path: <mikkelfj@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 0C6751207FB for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 15:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=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 9vENS3MjZtJK for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 15:07:04 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 D93381200FA for <quic@ietf.org>; Mon, 4 Nov 2019 15:07:03 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id w3so12219946edt.2 for <quic@ietf.org>; Mon, 04 Nov 2019 15:07:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Yfkv6Evd2xoLXjCI7c2F2kJ8rWrGEU5cYJK9KrsOVa0=; b=bRRGYdp2Nfh9hPggPG5ubXdpc3yfvMZXPm2nfnRPqQXX51Sw4jZ/IF3wWaVZOs6CUN 1NdDSaDh1QlSqtpVz+wmAR6C2Gc+23lWFe4m0X+5gAcaahBTNtX+lKdt9I9wTgj/kbUG 8Sz6RW/taxh2Bdi8XpuVY7QbBDCwwM4lBZzv5viCN1UgGoxWbdweriIYjhK9CJGD4kBq 9gWW6ouEmSjTD+CGq3buK7KOuGta8Led58XmWz0yFx6L1EYQNyalQ3r5arEsrKDJreNQ vwwF9BVdaYdmbOY8SBpXllGM6nlRIbZy7Hfr+NQ+IDQNVgRrecLIiOCBIyP+d8Tljb+F p0lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Yfkv6Evd2xoLXjCI7c2F2kJ8rWrGEU5cYJK9KrsOVa0=; b=PHa68OulqTzYXyTZ0ScyKo7OrCKBi9sJil1B2f2RIgBjKH+iZSMR4tFcw/UnAu/RtM jmm1GCHg6h462ohZClKUwGX7HvjSGjX8YipIhS+DoJpqZXhbKMqswOAb7t2zf+sAid4L O8UeKzzFE9oc5SBhMae+XsLYMW1P7tRpWxRu0NBxfxTarR9wfyr/6YjezSqUTGxgzv0V Kj7HzwgMzjmxy4RcesTBSsA2IAsbYA9j7KQTcGNcBVuk1LzTdTTz2iRrVH9gQnwbbkWv XehNlmrxf5CErKxwXuaGEbVmdj0yEFDCtX5C6PTlE7dE9zLI4xNs6fGzlp7FGTeSRAnA flvg==
X-Gm-Message-State: APjAAAUT4y+xHCkvSJJo6qxXrBlCWBELvuN80gYnzQ+x2Xc+0/UrAI8E Hha7mitCCkTVaejNTbU0K1eJUpsx1DeI1VMvaaA=
X-Google-Smtp-Source: APXvYqx5GE00XoM9EHbNoey7y6B6LSRqJIf8An2V+uYxnQOkBKcVnlBXzxG16uUC/gM6dc3hD33WuRQ5Qho1N5g93qE=
X-Received: by 2002:a50:9930:: with SMTP id k45mr32196558edb.134.1572908822536; Mon, 04 Nov 2019 15:07:02 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Nov 2019 00:07:01 +0100
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAPDSy+6y2gQmiCdLhVXXU3d0ER=mt7+R0s5cA=EAH3HfT+k_JA@mail.gmail.com>
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>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 05 Nov 2019 00:07:01 +0100
Message-ID: <CAN1APdczRvpargzKELJXOgYg1Yp+iv-5v_7RbvJZMWNHFDqCrw@mail.gmail.com>
Subject: Re: QUIC Version Negotiation Extension
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: QUIC <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a1a76905968d5f1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iPnOeffD2pbh65rylkotaBL-BDU>
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:07:06 -0000

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


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).

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.

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.