Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)

Kazuho Oku <notifications@github.com> Wed, 25 September 2019 13:28 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 27AAE12008C for <quic-issues@ietfa.amsl.com>; Wed, 25 Sep 2019 06:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Level:
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YGev2OVWIWy6 for <quic-issues@ietfa.amsl.com>; Wed, 25 Sep 2019 06:28:06 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E81712004A for <quic-issues@ietf.org>; Wed, 25 Sep 2019 06:28:06 -0700 (PDT)
Received: from github-lowworker-39ac79b.ac4-iad.github.net (github-lowworker-39ac79b.ac4-iad.github.net [10.52.18.15]) by smtp.github.com (Postfix) with ESMTP id 99E678C1EB7 for <quic-issues@ietf.org>; Wed, 25 Sep 2019 06:28:05 -0700 (PDT)
Date: Wed, 25 Sep 2019 06:28:05 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7WXMW6OVARY73NKJ53TCO6LEVBNHHB2TYBKQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3014/535022144@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3014@github.com>
References: <quicwg/base-drafts/issues/3014@github.com>
Subject: Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d8b6b658a891_103a3fe5f5ccd95c15384e"; 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/bKRwoBkHeTgdgyGmZOWwQ4le1fs>
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: Wed, 25 Sep 2019 13:28:08 -0000

> I'd like something more concrete than "this is expensive", but I'm willing to concede that this is a considerable increase in cost for a DoS protection device.

I share the same view. We have discussed this previously, and the conclusion was to not apply AEAD to the Retry packets. I think this issue warrants us the chance to revisit the previous conclusion, but I think it's worth wondering if we can find a solution without enforcing the use of AEAD.

That's why I am suggesting the use of optional GMAC. The straw-man is as follows.

When a client receives a Retry packet, it checks the last 16 bytes of the packet. If the last 16 bytes are equal to the original DCID, the packet is considered to be _not_ protected by the AEAD. The token is the rest of the packet payload. If the last 16 bytes is anything else, the packet is considered to be protected by the AEAD. The requirement to the server would be that it should either AEAD-protect the Retry packet, or use the UDP checksum.

There would no longer be a ODCID field.

I think this straw-man might be somewhat better than the "worst" of the two approach being combined, and that it might be something that we can go with.

-- 
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/3014#issuecomment-535022144