[quicwg/base-drafts] Timing issues in version downgrade attack prevention (#1810)

Kazuho Oku <notifications@github.com> Fri, 28 September 2018 09:41 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B2C5B130DCE for <quic-issues@ietfa.amsl.com>; Fri, 28 Sep 2018 02:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.456
X-Spam-Status: No, score=-8.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EwModH9W24cR for <quic-issues@ietfa.amsl.com>; Fri, 28 Sep 2018 02:41:47 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF750120072 for <quic-issues@ietf.org>; Fri, 28 Sep 2018 02:41:47 -0700 (PDT)
Date: Fri, 28 Sep 2018 02:41:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538127706; bh=2QX4EQLK+zu6ZyFoAhQdNyADTmPZYX4WHHbyDALU+oQ=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=qZQ7OeW2cxRC1mqJfsGG+ExrX9BVe+rBx7m7QrqGq0BEz5/M8PnjjTY5SKORvo1up wGMP3ai4k0otOTUUfV6TdWrTbgbP5aeh66JijiK6cmgjYMySR8N4vadf3xqxwMGlZa CQjhTHiaA5QQJ7Kfh4rn6f2Nvs7lrU0UYtLS8uWU=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd8f3398588132be2b57add3cae31b9dcc2a1c21992cf0000000117c5b95a92a169ce15bea539@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1810@github.com>
Subject: [quicwg/base-drafts] Timing issues in version downgrade attack prevention (#1810)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5badf75adbdb7_57a43f850dad45b8852329"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/tTICMSSWz7UUkgMe5lmMmYXuO5k>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2018 09:41:50 -0000

Current design requires the contents of the Version Negotiation packet and the value of the `supported_versions` field of the Transport Parameters to be identical.

In practice, this is a requirement hard to meet.

Consider the case of upgrading the server from a version that supports v1 only to a version that supports v1 and v2.

If a client accesses the server running the old version using v2, it would receive a Version Negotiation packet and retry with a v1 Initial. If the server was upgraded before the v1 Initial is received, then the server will include both v1 and v2 in the Transport Parameters, and the client will terminate the handshake considering that a version downgrade attack has been mounted.

Same issue arises when you have a server cluster. The first Initial (that is responded by a Version Negotiation packet) and the second Initial might be delivered to a different node of a server cluster supporting different set of QUIC versions (note: it is rare to upgrade all the nodes behind a server cluster atomically).

IMO, we should either drop version downgrade attack prevention as a whole (as have been proposed in #1755), or move the detection logic to the server-side (e.g., by requiring the client to include in TP all the versions that it preferred to use rather than the version found in the packet header) so that the server could ignore the timing issues during an upgrade.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: