Re: Alternate Version + Salt in Alt-Svc

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 04 November 2019 21:47 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 E996A1209AF for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 13:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, URIBL_BLOCKED=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 Q4RpgQ6OqIiz for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 13:47:08 -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 197EC1209C8 for <quic@ietf.org>; Mon, 4 Nov 2019 13:47:08 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id k14so5527647eds.4 for <quic@ietf.org>; Mon, 04 Nov 2019 13:47:08 -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; bh=mEgQdMwWbVqxFvVfJSPYs5ZW51Q6QNXCspa60T86UK8=; b=JXYiVAYyuE7EDXsoKoK+nTRQHYULy19nT835bW9LBABCU5Ow+ShMkVKu9DM4LDPnAG omGpIIQgeR336owdlIjhohdWNW0uo0EIVhjRHysGdJqTjsGSk2encegBEECr1UVzEMTc AuMRBEoiQj4DSYD+ItV/I8i2YkWlh4xrGJubu13PZlPcT/hyMZCRsul9MFL8BmWEfvoG +wbbvZg1WHqMlhqEZs90/TCYB0lyObnV0bAObZllU4Z6K6VjH9A/Y63POWLYjIk/A1TV DyFIwQzRf/2aLi6ZxVt4ttX36XlVRGXWfQaRhyrIAhDJD8QLwixSjm7sQr+lydeLsBWX 2IhA==
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; bh=mEgQdMwWbVqxFvVfJSPYs5ZW51Q6QNXCspa60T86UK8=; b=FGVgS+oBa+tVucWfCcBpX0oV+alaMWmB5uHzMs/uVefqWSZUHAMKPMFMtsZcxdz4J+ KOikXJkYan3H6KhIekogUg78lqb7Kt1T+PNCPV/DRji779DCInK3soL3LF3bXI4rUWGF Cl2LkZ0mbKZ1RlLsb/MVKUqLzvfj1Ma+ShDt4A04xb1zL9WUySE84oAhTqKOpOUzcRRA /vVClcMOdx3ziJVpyi5d+v+qfGZ6Iir/J4xzBwGG+RjbFO+4qSPrDsycNoJgrbgpTvUT sbb8zjkWYxFGdBRKDdsVLRQEdI2mTjXF/HwzG1NYIrvxLfXvVAtGvJ534DvQPjKEueNz 5YOw==
X-Gm-Message-State: APjAAAXklqYd6JbJNLjOl9pS5VdX6sgkS1qCaypYGt0EhgAElbEpYBS2 RcSsbclalNg2pkJwEJecefr0lAwpIb5h7v9yZKI8CuU7
X-Google-Smtp-Source: APXvYqz22RU5frx+5aJnzYIbExnKKyI6WzCgWlv+B6sgApeul44mzbf13d/l37A4AgSOZmdu4HoznfqnMo7jLyXV9vc=
X-Received: by 2002:a05:6402:488:: with SMTP id k8mr31816429edv.293.1572904026510; Mon, 04 Nov 2019 13:47:06 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Nov 2019 22:47:05 +0100
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <d7dc1be9-2eab-47cb-9fcb-3a0503014d0c@www.fastmail.com>
References: <CAJ_4DfTN-25ZpDmGBFXxmz9RZCT=8JbpFoDX71eyhE1rEtPkMg@mail.gmail.com> <d7dc1be9-2eab-47cb-9fcb-3a0503014d0c@www.fastmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 4 Nov 2019 22:47:05 +0100
Message-ID: <CAN1APdckCy1698hoASZOpzSs8fNzfcwH=rbmP1cS52-Lt6djRQ@mail.gmail.com>
Subject: Re: Alternate Version + Salt in Alt-Svc
To: Martin Thomson <mt@lowentropy.net>, quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c41b6705968c415e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5U6ud7PgiLN9iP4XuZ2UA-wOZxA>
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 21:47:16 -0000

Sorry, my response was on the wrong topic. It was in relation to version
negotation.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 4 November 2019 at 22.43.42, Martin Thomson (mt@lowentropy.net) wrote:

Some random observations reading through the document

- Is the order relevant in the receiver version list?

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

- VERSION_NEGOTIATION_ERROR vs drop - I’m not sure it is a good idea to
close the connection. The initials are public so it is possible to inject
false versions. There are probably many other similar attacks we don’t
bother with, but still …

- Checking that a transport parameter field is the same as the long header
version seems redundant - why have those fields? Is it because the Initial
header fields are not sufficiently protected via TLS magic (or similar)?

- We generally use varint, but why have varints mixed with 32-bit version
lists? I suggest making the list length 32-bit for easier processing.

- Downgrade - I’m a bit worried about state management and server
redeployments. A server could reject a valid packet because an Initial was
routed to a new server. (Reading further, I see this is addressed). This is
probably a pragmatic solution, but it has an assumption about eventual
global coordination. I suspect something could be done here with tokens or
CID routing, but it is not trivial.

- Security Considerations - perhaps it is worth noting the transport
parameters need additional protection beyond the Initial packet protection?
This follows from TLS, but if TLS is not being used, this can version
negotiation even if other parts of the protocol version is not sensitive to
this in that particular version.

- Greasing 0x?a?a?a?a - I’m not really sure about the point of this.
Especially if we get salted versions in separate proposal.

- It is not immediately obvious if version negotiation can go on and on, or
if it settles after at most one roundtrip one way or the other. This might
depend on the client QUIC version, but that is a fuzzy term in this context.

- Improve discussion of Previously Attempted Version. While the
requirements are readable, the purpose of doing this check is less obvious.
Presumably this deals with downgrade attacks, but more explanation would be
appreciated.

Mikkel