Re: [quicwg/base-drafts] Looping with multiple Retry packets (#1451)

Kazuho Oku <notifications@github.com> Fri, 22 June 2018 04:32 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 E1EEA130DE3 for <quic-issues@ietfa.amsl.com>; Thu, 21 Jun 2018 21:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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, T_DKIMWL_WL_HIGH=-0.01] 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 VlbhHrqU569j for <quic-issues@ietfa.amsl.com>; Thu, 21 Jun 2018 21:32:16 -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 76268130DDE for <quic-issues@ietf.org>; Thu, 21 Jun 2018 21:32:16 -0700 (PDT)
Date: Thu, 21 Jun 2018 21:32:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529641935; bh=S/5NXu5eX9S9DtV6rjgSGijtzXy5IqW6RnBHSqwTlD8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=urjZpdBRgfoKyOvjFdRzU8PhmBRk8Ojs7fru2KO387oneZICDTblqr1SWCLAlRpKM lNaB1zUF4dB4+FlMZU9VxoGtww8Iup+fe6NLoBlid0l0gOzYpClSfhJhyeNbJwyb81 oYkartOOW+aTplY8ioI+vugoN8F6k6nA5VB5iVk4=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba6f66af7e216fbcbdac76543a07f75a65e9c2a2292cf0000000117443dcf92a169ce13d69366@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1451/399317602@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1451@github.com>
References: <quicwg/base-drafts/issues/1451@github.com>
Subject: Re: [quicwg/base-drafts] Looping with multiple Retry packets (#1451)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b2c7bcf9d0d3_553c2b1592e32f6046527"; 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/UrpdCgz1LVpORv6Vcs9k24bBVG4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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, 22 Jun 2018 04:32:19 -0000

@nibanks @MikeBishop It's good to know that we have interest in such deployments. Thank you.

> I agree we should look at the security properties and enumerate all the threats/attacks this design could expose. Then it's a matter of weighting the impact of those threats vs the cost/complexity if we decided to fix them. Personally, I haven't seen an attack that would really benefit a middle box any more than any other handshake disruption tactic.

The issue about simply allowing the existence of an uncoordinated middlebox is that it becomes impossible for _any_ server to detect somebody on-path altering the handshake traffic.

For example, a middlebox can alter the server CID by sending a Retry, and the server will not notice the alternation if the middlebox also drops the token field of the 2nd Initial packet sent from the client that traverses through the middlebox to the server.

While I understand that you cannot care about the issue in the deployments that you are interested in, I think that others would be worried about the possible impact on security as well as the ossification concern including the one that I have described in https://github.com/quicwg/base-drafts/issues/1451#issuecomment-398982420.

Fortunately, there are ways to define a signal for detecting tampering that _can_ be implemented by server operators who will not have uncoordinated DOS detection devices.

One way is to add an "Original_DCID" field to Transport Parameters, and state that "a server SHOULD check that the value of the Original_DCID field matches that of the packet that it saw in the first packet that belonged to the connection". Servers running behind an uncoordinated middlebox will turn this check off.

Note that having a configuration knob is mandatory for servers running behind such a middlebox, even if we do not introduce the "Original_DCID" field. This is because Retry is version-specific (which means that uncoordinated DOS mitigation devices might need to send a Version Negotiation packet). To support that, the servers need to have a knob that changes how the downgrade protection logic works (FWIW, end-to-end version downgrade protection is currently a MUST; we need to change it as well to allow the existence of uncoordinated DOS mitigation devices).

-- 
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/issues/1451#issuecomment-399317602