Re: Alternate Version + Salt in Alt-Svc
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 04 November 2019 21:36 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 1EB8C120836 for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 13:36:53 -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=unavailable 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 oETa0ufHMMWr for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 13:36:48 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 EE8C212002E for <quic@ietf.org>; Mon, 4 Nov 2019 13:36:47 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id b72so14409233edf.1 for <quic@ietf.org>; Mon, 04 Nov 2019 13:36:47 -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=B4ruVr/fKSzgbI+Fmv5LtJLLsn+hoZH4P5ulS5wUHKo=; b=TVj8PTdYNO9RZhafQE+v2EFDXjAirNa+3q45+IrxK1L0g15ZnhDmx9vLjz8eSM1AD5 voV82Uufc6LEHB/pyJfQLOlzsu/zJBwBRCLO1lvHA8WjGQc6yt96Dt6JKdx1KgHazs1K wWy2DRZDkSID1ZIGHaR1ZXjoZOge87qNzTO6NNz08ZoNz/IB6kCQF3UbKfvDxZBCg5iA cfRctIYqKOzImSGm8v6YYm5krajUrGpAfBIv0jHnDeTZXyyq4ycBFcOGJrgHiNM8O5i1 VvUIlA3RhLPW9suniBaZZohXWGczRX50AS9HpjnQqX/49I8iCWwN+ocydCA76zWW7Bqi kSHg==
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=B4ruVr/fKSzgbI+Fmv5LtJLLsn+hoZH4P5ulS5wUHKo=; b=XFnCF3XlZ1s9zGJ19Nl5mpDohMlZ3jhk4D1jnb56H+Pl/u44hnwat5ZA23nyQPCVp0 uRCn59L5sk9nNd/kLGadM2460TMrhgkT58lohv+pkNIqRistnjZwosRBP8sLJzWK9VZ7 RFEcxaQ9nw1Ea9LS1di6fIs22GWxEdD7P55o4jLv6yn4FdUZgcUKqHWH+d2wfFOVfXgV RAeusG7XEUak4rzEi9I1lwngkTZpff6kL4UEzB8oYcxpEwafAi6WE5BPZ51ucQLp9pVu /4hmctqEIt8M2J3IF6nDq+tjv4gHbRUFAaYkkKZd0FTJnO9Fb73LZBEZonGY7E/uprdr GZLw==
X-Gm-Message-State: APjAAAU//nUAZpt1nXjT5n9mOMBfXnhOEf9l+b/D+TNFoje0wIkX6FaB QheCZAREiRcHGjJAtu7Sr21+MMPzbyqNk14Sz51ikGTH
X-Google-Smtp-Source: APXvYqxlUh7oG6ZPp3dowJSlT922Wqr6KZeMZ1q1l6OdMRpUe0UFWDR3cvnztiljMQJUowYbffYbz91nRjeKOnAiupQ=
X-Received: by 2002:a05:6402:512:: with SMTP id m18mr30667819edv.250.1572903406356; Mon, 04 Nov 2019 13:36:46 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Nov 2019 13:36:45 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <540E0152-57EA-4B96-8E8E-F07143CD8A58@apple.com>
References: <CAJ_4DfTN-25ZpDmGBFXxmz9RZCT=8JbpFoDX71eyhE1rEtPkMg@mail.gmail.com> <540E0152-57EA-4B96-8E8E-F07143CD8A58@apple.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 04 Nov 2019 13:36:45 -0800
Message-ID: <CAN1APdeykg0icmjQ7dx1_AthGxLvPwe9_O6hGFQMEe_zKn9bgg@mail.gmail.com>
Subject: Re: Alternate Version + Salt in Alt-Svc
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cd4e9a05968c1cf4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3q8YQpn-sSOKds3WgdU503X_cWk>
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:36:57 -0000
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 On 4 November 2019 at 21.41.30, Tommy Pauly ( tpauly=40apple.com@dmarc.ietf.org) wrote: I do think that this privacy concern is a valid issue to think about and try to mitigate, or at least reduce in scope. Good to discuss! Clients could of course choose to not use a version received via Alt-Svc when they don't want to be linked (in which case they would also not want to do 0-RTT, etc). So there could be guidance on when to use these versions. That may reduce the amount that the alternate version gets used, though; and even end up causing failures only of some categories of connections. Another way out here is to use the Alt-Svc value that comes from another source, like the proposal in HTTPSSVC. That would be harder to target users with. Best, Tommy On Nov 4, 2019, at 12:34 PM, Ryan Hamilton <rch=40google.com@dmarc.ietf.org> wrote: Howdy Folks, We've discussed the idea of attempting to reduce ossification by allowing the server to deliver an alternative version and initial salt to the client which can be used to speak "QUIC v1". One such mechanism for delivering this version to the client is Alt-Svc. In the context of HTTP/3 this has the wonderful property that even the first connection from a client to the server can use this alternative version. However, it seems that there might be a privacy/linkability issue with this approach that I'm curious to get the groups' take on. If this information were delivered via Alt-Svc, I would imagine that the naïve implementation would be to cache the Alt-Svc info as until it expires (via the ma= attribute) and use the alternative version/salt in each subsequent QUIC connection. Since the version field is 32 bits, that potentially allows each user to use a distinct version. This is great for anti-ossification, but seems problematic for linkability/privacy. I can think of solutions/mitigations for this issue (like restricting the number of bits which can be flipped by the server, or expiring the alternative version in the client on first use, etc) but I'd be curious if this seems like an issue to other folks first. Cheers, Ryan
- Alternate Version + Salt in Alt-Svc Ryan Hamilton
- Re: Alternate Version + Salt in Alt-Svc Tommy Pauly
- Re: Alternate Version + Salt in Alt-Svc Mikkel Fahnøe Jørgensen
- Re: Alternate Version + Salt in Alt-Svc Martin Thomson
- Re: Alternate Version + Salt in Alt-Svc Mikkel Fahnøe Jørgensen