Re: [quicwg/base-drafts] Spoofed retry token attack on IP authentication (#2394)

Kazuho Oku <notifications@github.com> Fri, 01 February 2019 12:00 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 C332F127B4C for <quic-issues@ietfa.amsl.com>; Fri, 1 Feb 2019 04:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 ZKMGCVJ6-SGV for <quic-issues@ietfa.amsl.com>; Fri, 1 Feb 2019 04:00:11 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0885128CE4 for <quic-issues@ietf.org>; Fri, 1 Feb 2019 04:00:10 -0800 (PST)
Date: Fri, 01 Feb 2019 04:00:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549022409; bh=mbZUa7Lml4crv4RwSX53+jzOAHssYRAc8iTg1Ibh7wg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lr4sBKwCV9pcMf8eTfqgxs71N+YDnFZuvldhw6z211QzBwmYDFfWNDSYkE7GH0s5T /lQLYYleyfIPBCzoa/ccjjuPDiZYc6GiEclryn3e911IJDGvZvSvAqirvQ1TTXP5OV SYr+P3tU852PWoGenw982kZt/orRo6lxW7c2Xz1o=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe77b5b9f36440d529dd6b709a1ee6e0e954c0c1692cf00000001186bf6c992a169ce1823c7c2@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2394/459700403@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2394@github.com>
References: <quicwg/base-drafts/issues/2394@github.com>
Subject: Re: [quicwg/base-drafts] Spoofed retry token attack on IP authentication (#2394)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c5434c9814b4_a043f9b57ed45b8192e5"; 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/k9obwEKV1bNthviJBVsDMXcF6UU>
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, 01 Feb 2019 12:00:13 -0000

This is an interesting attack, and I have several points that I would like to argue.

First, this is not an MOTS attack that we need to consider. Because the attack can be mounted by a malicious client. A client first obtains one token, then uses that token to create multiple connections. That is an attack vector that we need to fix (assuming that we haven't already).

Note also that we are giving up to have protection against on-path attackers injecting Initial packets.

Therefore, the protection method that @marten-seemann is fine. It's true that an MOTS attacker can race a Retry to prevent a legitimate client from establishing a connection. However that's not something we need to fix, considering that an MOTS attacker can simply inject an Initial packet containing a CONNECTION_CLOSE frame to disrupt the handshake.

Lastly, I would like to point out that there is another (possibly simpler) way of addressing the issue. A server can embed the server CID issued in the Retry packet in the Retry Token that it issues, and use the token to confirm that the Initial packet sent in response to the Retry contains the correct DCID.

I think we should recommend servers to implement some kind of protection.

-- 
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/2394#issuecomment-459700403