Re: [quicwg/base-drafts] Is path validation a SHOULD or a MUST -- pick one! (#2580)

erickinnear <notifications@github.com> Wed, 17 April 2019 19: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 92825120308 for <quic-issues@ietfa.amsl.com>; Wed, 17 Apr 2019 12:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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, 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 rk_-WEDOfEB1 for <quic-issues@ietfa.amsl.com>; Wed, 17 Apr 2019 12:52:44 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BB1120392 for <quic-issues@ietf.org>; Wed, 17 Apr 2019 12:52:41 -0700 (PDT)
Date: Wed, 17 Apr 2019 12:52:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555530760; bh=HotxlPrUL21n/ONZL3eR25ze255aNCRRlyOhRcz7fg8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gO7501lixYTviU8Zw1YIbTKESFga+tiGvtA1sDgGg/gh6E8R96Pjh550Xofe2y6vm x9Vue8VKQRzNuCBI2ogteNLrXP1g9fr8TzzktA/sIUjgRHozwAn/Dem0BzzogCdkGS p8ei5duFuLRNQiitwMzcHqMTRdbiK0mWPowxXAnc=
From: erickinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab66620bfa3d0c7f8cde946218d8077408c4a7324992cebac4b68892a169ce197dbe90@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2580/484236423@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2580@github.com>
References: <quicwg/base-drafts/issues/2580@github.com>
Subject: Re: [quicwg/base-drafts] Is path validation a SHOULD or a MUST -- pick one! (#2580)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb784082dcec_36a03ff50cecd95c7969a"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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/lSMvGOpbwX0aVovdTc-HfXSCtbA>
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, 17 Apr 2019 19:52:47 -0000

I think elsewhere we had a "MUST, unless" for some of this, so sticking with that would be great (to second Igor and Ian's comments).

Re: SHOULD, agreed that it would potentially broaden the attack surface, since some of the mitigations (the reason for the MUST in 9.2) rely on validation being performed.

The attacker can cause you to generate validation packets by injection, but I think the discussion in #2582 should attempt to consider the implications of what happens when you end up validating on every incoming packet (the worst possible case here, and definitely a good thing to think about).

My intent here is to put the non-editorial changes in a small PR to get the normative language right and then potentially follow with a larger PR that's (hopefully) purely editorial that rearranges these to get rid of some of the confusion around having requirements split across the sections.

-- 
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/2580#issuecomment-484236423