Re: [quicwg/base-drafts] Retire My Own CID (#2645)

David Schinazi <notifications@github.com> Tue, 11 June 2019 17:43 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 974671201DA for <quic-issues@ietfa.amsl.com>; Tue, 11 Jun 2019 10:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 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_HELO_NONE=0.001, 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 hqh44-Wv8hUf for <quic-issues@ietfa.amsl.com>; Tue, 11 Jun 2019 10:43:09 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FD3120163 for <quic-issues@ietf.org>; Tue, 11 Jun 2019 10:43:09 -0700 (PDT)
Date: Tue, 11 Jun 2019 10:43:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560274988; bh=covAtUPNL4FslYcRiIbnhPT4OuEXzXHmGAFCT83WUeo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=A+q7m3gBkuIqt+JO0YKU7J8T6FFHSGdX+dUH1pANhj0q+xpRsfQt5oTqIgmw3EpJu s6wmNsDHgYSOuDXlbmTZWFS2DBFpLGTbEfYfAdH9I75Pq6103wWSsFQ5F7MgAnh/YK ECR/QzjyLFyPrZiisVmJtexiKwcvsLazsyIjV7yg=
From: David Schinazi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5YXUL6TV6JKAGNMTF3BUNKZEVBNHHBUAUCHA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2645/500949711@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2645@github.com>
References: <quicwg/base-drafts/issues/2645@github.com>
Subject: Re: [quicwg/base-drafts] Retire My Own CID (#2645)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cffe82c183dd_37a73f96c72cd95c5750ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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/0jL9UsTJlRkOdB_CWyu8Rp8RUNI>
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: Tue, 11 Jun 2019 17:43:17 -0000

@ianswett Consider a MITM attacker that can intercept packets (prevent them from arriving now, and save them for replay later). Assume the server says "please retire CID X", the client switches from CID X to CID Y, and the attacker intercepts the last packet the client sent with CID X. Then the attacker waits 4 PTO and sends that packet to the server. If the server used the same reset token for both CID X and CID Y, then the server will send a stateless reset and the client will close the connection upon receiving it. There is no text in the spec today that says the server MUST pick different stateless reset tokens for different CIDs. Therefore, the ability to request to retire CIDs does open an avenue of attack similar to TCP RST.

If we want to have a safe mechanism to request retiring CIDs, then we have two solutions:
(1) we require the peer to retire the CID immediately
(2) we make this a best-effort request with no enforcement of actually retiring the CID

As discussed earlier, (1) is not practical. What does "immediately" mean when it takes time for packets to travel between endpoints? If it means send it on the same packet that carries the ACK, what happens when that packet gets lost? Do I need to send RETIRE_CID on every single packet in this window until one gets ACKed? I think this quickly because a mess full of corner-cases with security vulnerabilities at play, and I'm not confident we can get to the bottom of it rapidly.

Option (2) is similar to STOP_SENDING. It's a way of telling the peer that they should do something because what their sending won't do anything useful.

@nibanks I understand why you'd rather have (1) but I don't think the benefits you'll get from it outweigh the security risks. Even if we pick (2), I think everyone will implement this as retiring the CID either in their next outgoing packet or maybe at worst a couple packets later. And that gets you what you want without adding security risks.

-- 
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/2645#issuecomment-500949711