Re: QUIC Version Negotiation Extension
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 6D597120A2F for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 13:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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=no 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 evIiV9AOoyAF for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 13:47:31 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 7DC251209FF for <quic@ietf.org>; Mon, 4 Nov 2019 13:47:31 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id a67so2284637edf.11 for <quic@ietf.org>; Mon, 04 Nov 2019 13:47:31 -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=Yld9NGtn9HnRHRStD/Hm2p0fe2Kphx9gn1Uynq6+Zqo=; b=Da+HEMXUED0BHOmabpJxK0GuevrCiUPRg66QTa4I9Dr37O2wCT/iPc94Z/oPBwmt+g RNhX9X4/v+m/cAZBGgoWYbW/XNfw4g+Ka72JcfYEoQ3e39JXjDE0KTMt+X6NhrHAGjUB 7D5jrAs6BxD8NJtbv3LeBzJ1YG5jm9cNsfDdmJnsuUrQZDIELPvWlrppUEQAiPXXl+Ep H1K6hGssc/O6zkVF/vOy60zBZV1uiPlBgPVuLJ5uek1T2sZMb3iBMuzw1WD8k0v4q1Oh 2RSpyLvZnJTkys7StRNhADTQ3nGt3dtrlmThJx8qS0QMIkcfTsPc/Ob1CufPSm5Hp9dB 0HVg==
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=Yld9NGtn9HnRHRStD/Hm2p0fe2Kphx9gn1Uynq6+Zqo=; b=DjDrfxIeqU0r4PH/NEtrubHQhldFXr2XIYXTpE5REQURfSW4Oqkdxzy7FPWF/4bD0l fed1Q1Ov8RV8J7UT2La2Gon4ypJr+arvL8r2kdccK9EW2qGIg7ybdGgXnDrqj6/OmQBs avhIcT+2hmSaCIaygxNtBvUEXm16iMIig5vO3Mc4QpOzcfqK4Bh2LA1KHjCs2pU4+qJC fIsNBNYY9FJGOVG7lB5ctD0GQlZ3pCUIGz/S0L42nwXtHfTauh/xpXbl4Nn4nURp/9fv YyV5g6FJtQd99oA+cepKT1YRk7sFHNrMG+04AK6yMq2qHSxKAtGT+S9ASb48qLDQL4ye 0VSA==
X-Gm-Message-State: APjAAAXco/mYsWpH2gH3G5mnRwATsv8Y+y6SFXrldUDRx1focsk/zd4D KFOT7USadC/G6cAGYrAgUH/1Zgr0W9nvvBXU8wih3+mL
X-Google-Smtp-Source: APXvYqyOAaF+lsX2WFq3QO3oQQp5wgx+ZROdLpDUCh/OnpVDDHy1AEahN8ZM/5razS/CR89wHscESM/b74Or0zk1Yww=
X-Received: by 2002:a17:906:1b41:: with SMTP id p1mr20680265ejg.65.1572904049654; Mon, 04 Nov 2019 13:47:29 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Nov 2019 22:47:29 +0100
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com>
References: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 04 Nov 2019 22:47:29 +0100
Message-ID: <CAN1APdcZv-MtwRT77++r6EKdzJUc1NKEJfY4CZeOSaK50nPZYg@mail.gmail.com>
Subject: Re: QUIC Version Negotiation Extension
To: QUIC <quic@ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000253f7305968c433b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/dwfeIcp1X7Qq9E8Hc2aNjB7d_RQ>
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:40 -0000
(reposting on proper topic) 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.30.10, David Schinazi (dschinazi.ietf@gmail.com) wrote: Hi everyone, >From the recent discussion on multiple PRs, it appears that there might be a need for downgrade-safe QUIC version negotiation, earlier than we expected. EKR and I updated our extension to hopefully suit these needs: https://tools.ietf.org/html/draft-schinazi-quic-version-negotiation-02 Comments welcome here or on the GitHub (link in draft). Thanks, David
- QUIC Version Negotiation Extension David Schinazi
- Re: QUIC Version Negotiation Extension Mikkel Fahnøe Jørgensen
- Re: QUIC Version Negotiation Extension David Schinazi
- Re: QUIC Version Negotiation Extension Christian Huitema
- Re: QUIC Version Negotiation Extension Mikkel Fahnøe Jørgensen
- Re: QUIC Version Negotiation Extension David Schinazi
- Re: QUIC Version Negotiation Extension David Schinazi
- Re: QUIC Version Negotiation Extension Mikkel Fahnøe Jørgensen
- Re: QUIC Version Negotiation Extension Mikkel Fahnøe Jørgensen
- Re: QUIC Version Negotiation Extension David Schinazi
- Re: QUIC Version Negotiation Extension Martin Thomson
- RE: QUIC Version Negotiation Extension Mike Bishop
- Re: QUIC Version Negotiation Extension David Schinazi