Re: [quicwg/base-drafts] Describe a new version negotiation mechanism which allows for (#1755)

Kazuho Oku <notifications@github.com> Fri, 28 September 2018 04:21 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DC6130DDB for <quic-issues@ietfa.amsl.com>; Thu, 27 Sep 2018 21:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oQPe9CrQbEK for <quic-issues@ietfa.amsl.com>; Thu, 27 Sep 2018 21:21:39 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7B61271FF for <quic-issues@ietf.org>; Thu, 27 Sep 2018 21:21:39 -0700 (PDT)
Date: Thu, 27 Sep 2018 21:21:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538108498; bh=gm0qWaJtS5P91eSNuifnkdyqK0/irMLfsiL6xuCKKqQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2Pk/F3+LVEBB2+/h6OmipWeED9oo6qPajk/bzeSzK7kwCK/yFj27wtLRADkS3Sbsc D8NL3S4LJRw/NZixZPMNeJQb0Ktm6oJhZbHBlZVnybScpvV3ZRSbfx86jnWlk5M9Ha LAdcq6cf84AsSoeuSLioZ21Ln5LbJxtv1CpMx95o=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab23d30999860363b93627b43b00412535f045fa0c92cf0000000117c56e5292a169ce1583704e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1755/c425316849@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1755@github.com>
References: <quicwg/base-drafts/pull/1755@github.com>
Subject: Re: [quicwg/base-drafts] Describe a new version negotiation mechanism which allows for (#1755)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5badac528a482_12623fb2e6ad45c01662c8"; 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/lC92lJsnRIxCGRBKnX4Nek76m0Q>
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 04:21:41 -0000

@ianswett The case I am concerned is like below.

Client and server supports both v1 and vX.

Client prefers using vX, and sends Initial using vX format. Middlebox intercepts that, and injects a Retry  that only allows v1. In response, client sends Initial using v1 format. TP will still include v1 and vX.

Now the server sees that the client supports both v1 and vX, but does not have a clue that the client _preferred_ using vX. Hence the handshake succeeds using v1. At this point, downgrade attack succeeds.

The key observation here is that it is only the client that knows what the initially tried version is. Therefore, we currently require the client to verify if there has been an attempt to downgrade. The proposed change removes that requirement without a replacement.

If we want to let the server select the version, I think that we should require the client to send it's original version number using TP so that the server can determine if there was a downgrade attack.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1755#issuecomment-425316849