Re: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)

Christian Huitema <notifications@github.com> Sat, 14 March 2020 14:52 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 5D8E33A0884 for <quic-issues@ietfa.amsl.com>; Sat, 14 Mar 2020 07:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level:
X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, 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 BDH_ieUvHnlk for <quic-issues@ietfa.amsl.com>; Sat, 14 Mar 2020 07:52:09 -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 714B03A0811 for <quic-issues@ietf.org>; Sat, 14 Mar 2020 07:52:04 -0700 (PDT)
Date: Sat, 14 Mar 2020 07:52:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584197523; bh=cV2G7TIHpjKUikRKQJwJgA6h9H0+MmBFXOzMnOyzfJw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DjcD9LxzKVIoFFzsDBKxsPMBgs4lXUNgZXvYvAKtBIM2CCb8lKhV70yQf0BVVjd83 O6jIBy4IDtMNMPI6NB/ZRkq+5XJiOuJ3HGeDm+K8BJ5beXNbbxNPAw5vHlKlOFWAhU 77/LwEnSQQ5FJUnMrqsZIxnEpBosFKP8UmrlGgtU=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5IQOZDF6O5MP5D3754PDIJHEVBNHHCFIPTEI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3523/599073854@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3523@github.com>
References: <quicwg/base-drafts/issues/3523@github.com>
Subject: Re: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e6cef931aa78_23be3fb1d74cd95c2400a6"; 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/TzGcQ6swK7pGmO7X0zGfv5gXmNo>
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: Sat, 14 Mar 2020 14:52:20 -0000

@mikkelfj Yes, servers should have ways to ban token reuse. There is already a recommendation that "A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts." I think we should add text saying that "A server that detects NEW_TOKEN reuse MAY immediately close (Section 10.3) the connection with an INVALID_TOKEN error."

It would be even better if the NEW_TOKEN frame carried an expected DCID parameter. This would make handling of new tokens by server very similar to handling of retry token: refuse or drop if the incoming DCID does not match the value tied to the token. It would also make reuse detection very easy, because connections attempts from the same address and to the same DCID could be routed to the same connection context. Only one connection would be accepted for the duration of the draining delay, which would greatly limit the possibility of abuse.

-- 
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/3523#issuecomment-599073854