Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

Christian Huitema <notifications@github.com> Fri, 06 March 2020 00:13 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 D30393A0F1A for <quic-issues@ietfa.amsl.com>; Thu, 5 Mar 2020 16:13:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 pejctwcElxjs for <quic-issues@ietfa.amsl.com>; Thu, 5 Mar 2020 16:13:17 -0800 (PST)
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 3829B3A0F1C for <quic-issues@ietf.org>; Thu, 5 Mar 2020 16:13:17 -0800 (PST)
Received: from github-lowworker-0f7e7fd.ash1-iad.github.net (github-lowworker-0f7e7fd.ash1-iad.github.net [10.56.110.17]) by smtp.github.com (Postfix) with ESMTP id 03F2D960994 for <quic-issues@ietf.org>; Thu, 5 Mar 2020 16:13:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583453596; bh=u2ONxYwbIF4i+62uess6wgE6wLx86CVaScFfQb7gJ3o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MhxyvF0Ujhj9G1q9FE8AE60iGVLRSkEUSVwGVrSac9Fe0E1PMHatKaiB/SRiFiHSt KtaVwaUc7H4i6/Bifh902P75PEI5k12cpHBXBns5YOqh4R3xqVPvGxFnxpxMl9m2Iu FW7IEZNq46h/zvASkB2PXiUS52KoO+6irZWrkYoI=
Date: Thu, 05 Mar 2020 16:13:15 -0800
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYI2AZ7326AXUVVW454NV3JXEVBNHHCC4LIRI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3439/595508210@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3439@github.com>
References: <quicwg/base-drafts/issues/3439@github.com>
Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e61959be691e_7dad3fe0f74cd96c2893a7"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/SUxmh8AiyLuA-t-PR12KTiBOvVY>
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, 06 Mar 2020 00:13:19 -0000

@martinthomson it seems that we have agreement on two points a bit of discussion on the third:

1) The spec should describe the "munged retry" attack. It can be used to play games with server farms, either by attackers in the middle, or by attackers as client. It can produce a DOS attack of some sort despite the "retry" protection mechanisms.

2) The spec should describe how servers can protect themselves by tying the "Retry-CID" to the retry token, and in fact recommend that they do that.

3) Adding "retry-CID" as a transport parameter would give assurance to clients that the server is protected against the attack, and allow clients to detect attacks if the server is not protected.

I am not sure that (3) is really needed. I do not really understand the client stake there, except in the general terms of defeating attackers in the middle and encouraging good server implementations. OTOH, if the server does (2), it is not very onerous to also do (3).

But then, what prevents servers that do not care from taking shortcuts, not verify the token, and copy any incoming post-retry DCID in the transport parameter?

-- 
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/3439#issuecomment-595508210