Re: [quicwg/base-drafts] Amplification attack using retry tokens and spoofed addresses (#2064)

Marten Seemann <notifications@github.com> Fri, 07 December 2018 14:58 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 9A06112D4F0 for <quic-issues@ietfa.amsl.com>; Fri, 7 Dec 2018 06:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 vkXVHKapxxW3 for <quic-issues@ietfa.amsl.com>; Fri, 7 Dec 2018 06:58:51 -0800 (PST)
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 E5D5D1252B7 for <quic-issues@ietf.org>; Fri, 7 Dec 2018 06:58:50 -0800 (PST)
Date: Fri, 07 Dec 2018 06:58:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544194729; bh=eMpUFq2DxWhmMO8TFL7eaIG6J0IRPzKB70qGrSUMrRU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Qde946F7spAH2leSSx34gkkIi7qGPostetEdHyYjomXhj6BBJi96SaCnQAacKD45O T+jXRkCs3ixkDE735YlePuCgy4I8Kynti+N9/qF7EbYlekw9U37zrNSVRA2sjZaMWh Vh5c/Ea3GfPLxTYkqDQ3rNbKQn7eYP84jbNo4dTQ=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abbe568908ba7f59233e757b8cea337ce69691e5b192cf0000000118224ca992a169ce16f92d74@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2064/c445257931@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2064@github.com>
References: <quicwg/base-drafts/pull/2064@github.com>
Subject: Re: [quicwg/base-drafts] Amplification attack using retry tokens and spoofed addresses (#2064)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c0a8aa9b85d1_69133f8ef82d45bc1370a1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/IS3UfEqD8CA6Rwd7Iz0Xi4R5ul0>
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, 07 Dec 2018 14:58:53 -0000

@huitema @janaiyengar As I described in https://github.com/quicwg/base-drafts/pull/2064#issuecomment-443087560, I don't a short token life time works as a protection here. I expect servers to issue tokens (in NEW_TOKEN frames) that have the same life time as TLS session tickets, which, if I remember correctly, is a 7 days.

The property we're really looking for here is not that a token is only used once. To prevent the DoS attacks, it would be sufficient if the server only accepts a token once **within a short time span**, let's say in the order of magnitude of 10 seconds.
If an attacker manages to obtain a copy of a token that was originally sent in a NEW_TOKEN frame, all he can do is make the server send the ServerHello and the certificate to the client every 10 seconds, which might be an annoyance, but not sufficient for a DoS attack.

I believe this is should be straightforward to implement: A server could either keep a short-lived set of tokens that were recently used, or maybe even a bloom filter which is cleared in regular intervals.

-- 
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/2064#issuecomment-445257931