From nobody Mon Jan 17 06:32:52 2022 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8583A0864 for ; Mon, 17 Jan 2022 06:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Q146qEhNy6U3 for ; Mon, 17 Jan 2022 06:32:45 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93643A0869 for ; Mon, 17 Jan 2022 06:32:45 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JcvWZ21G5z4Gd; Mon, 17 Jan 2022 15:32:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1642429962; bh=lnWLZ3+CUvYpED5+z6BLIjGdoMcRYQrCL2mQT6+ootI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mQLAVK2CeGUUjW2ocB1+66Tq2VNxBQeRekO1GdAYialDcubQt3tdfNIV+xlS+MBuL P9+NeNsqyWThs6siEnNXYWiL46cHz9FJMmNz50Cd0ODvWZdLsaF/blNvLRIcufsgUj mDtjnbXtoQqipXYceZZlL1Evu6HBXaRPCmAlFDNw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id b3SsWzeRBWiE; Mon, 17 Jan 2022 15:32:41 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 17 Jan 2022 15:32:41 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6AC7B1F1276; Mon, 17 Jan 2022 09:32:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 67A751F1275; Mon, 17 Jan 2022 09:32:40 -0500 (EST) Date: Mon, 17 Jan 2022 09:32:40 -0500 (EST) From: Paul Wouters To: Joey Deng cc: dnsop@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Why does RFC 4035 allows a security-aware authoritative name server to not send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 14:32:51 -0000 On Thu, 13 Jan 2022, Joey Deng wrote: > In RFC 4035 3.1.1. Including RRSIG RRs in a Response, it says: > >> When responding to a query that has the DO bit set, a security-aware >> authoritative name server SHOULD attempt to send RRSIG RRs that a >> security-aware resolver can use to authenticate the RRsets in the >> response. A name server SHOULD make every attempt to keep the RRset >> and its associated RRSIG(s) together in a response. Inclusion of >> RRSIG RRs in a response is subject to the following rules: > > All the statements above use SHOULD, which means RECOMMENDED, which means that there exists valid reasons in particular circumstances to NOT SEND RRSIG RRs with the RRSet in the response. > However, the paragraph below it uses MUST: > >> o When placing a signed RRset in the Answer section, the name server >> MUST also place its RRSIG RRs in the Answer section. The RRSIG >> RRs have a higher priority for inclusion than any other RRsets >> that may have to be included. If space does not permit inclusion >> of these RRSIG RRs, the name server MUST set the TC bit. > > It would be very helpful if someone could help me understand this SHOULD/MUST behavior difference Likely people were overly caution at the time of writing? > 1. What are the particular circumstances in which a name server is allowed to do that? > > 2. One case I can think of is truncation, is truncation the only situation allowed to not include RRSIG? Truncation should happen on the RRset + RRSIG. Eg either you include the RRset+RRSIG, or you omit it entirely. You shouldn't just omit the signature. Paul