Re: [DNSOP] Validating responses when following unsigned CNAME chains...

Ted Lemon <mellon@fugue.com> Wed, 29 April 2020 23:30 UTC

Return-Path: <mellon@fugue.com>
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 963D03A0A16 for <dnsop@ietfa.amsl.com>; Wed, 29 Apr 2020 16:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 V7OFazwPcmNH for <dnsop@ietfa.amsl.com>; Wed, 29 Apr 2020 16:30:43 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F823A0A14 for <dnsop@ietf.org>; Wed, 29 Apr 2020 16:30:43 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id 23so3983273qkf.0 for <dnsop@ietf.org>; Wed, 29 Apr 2020 16:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0j7hzrmKyMH5SbQmqa7S0kQj4ATcH2t6Cq+Vd+dbbvo=; b=LyZmWhM7/ob0/S2v8Xi6hGiKpppc2A8csdMSopDzRVZ178aNz4d7FaJi5cNvpSgNAC 6Fh+x/mIk5zEx5yQjGPxRBg2MuTu/SRmsWPrNxVUOjUrXVRU+9lLk+9OgfKIQzN9yrVl ObecJLxNWQCOSMmo92J2cV29LIK6753ADPTQJJt/2moz6XFtx6Elp/yTUYRF6IE6PjtA m6Nuv/iDPiX1ugVFV3t4md9QOXR70QbEYAYeqNNakNgmiWa0CS7aQwEEZp4FVsU1ShS2 36KWI768WFhWY9J3pzqQI0MYrtnlz/c+IFlqPEKxrVZ1uX5PotvPrYhkrnsO+29iM2cL K3rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0j7hzrmKyMH5SbQmqa7S0kQj4ATcH2t6Cq+Vd+dbbvo=; b=ahk0CgVF6hwnXS2GHAd75qzM6xSj9H251vv8b/D4EwQSghBTREJEzKvUR+yQ8vMZmc 3fApIbs1LAMahgW6YJJ4kXOfA9EjhAowwafZzlHXNxDIBuT5N211Mg+qac9BCLHGMQY7 lpgG/7j99q92HOPoaEgq7itZALQXc1hZJzlGIUpqVgx2XaurCIEekwIeClYY/Xf12Sbt 7CRPivjDKqdMb/jRLfazSo4ScTI3zkca/UKSyw5RQcrUq6xv2ilfXPv5SS7gOjQXe5cq ofp8CGapt9ktt+eKPwUf7r4k7g5jPJpW2zVGZ+KaDXvi9Qzbu1dihHes9/3qbn3oGKpQ 0Mjg==
X-Gm-Message-State: AGi0PuYn1jwTdS93oFATkyFx3ToOf+7/IChhzbWwCib8Jwl5pnKB+iNi K+jvyG3vKAa5OBIERAh3akhXE1blv2s=
X-Google-Smtp-Source: APiQypLeH2IJUaHSbJsRv3LVqw5cmODClnTP0nGBM/KVJqwymGfWjTNLV76nrOW0m88Kz0szZLvDng==
X-Received: by 2002:a37:30b:: with SMTP id 11mr942936qkd.418.1588203042042; Wed, 29 Apr 2020 16:30:42 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:e518:6559:325d:1a5f? ([2601:18b:300:36ee:e518:6559:325d:1a5f]) by smtp.gmail.com with ESMTPSA id e4sm483876qkn.11.2020.04.29.16.30.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 16:30:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3636.0.1\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <CAHPuVdXWqA8Lu+Xy-rnad9UQvvAfawLk6-+G=GLCmGuMjfoZWA@mail.gmail.com>
Date: Wed, 29 Apr 2020 19:30:39 -0400
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D709E73-83E1-40A8-8E97-CCBDBBDF80E8@fugue.com>
References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com> <CAHPuVdXWqA8Lu+Xy-rnad9UQvvAfawLk6-+G=GLCmGuMjfoZWA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
X-Mailer: Apple Mail (2.3636.0.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9-3ZnZXJayNm49Wi1Vp6FGiR6A0>
Subject: Re: [DNSOP] Validating responses when following unsigned CNAME chains...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2020 23:30:47 -0000

On Apr 29, 2020, at 6:56 PM, Shumon Huque <shuque@gmail.com> wrote:
> I believe a validating resolver always sets the DO-bit in outbound queries. The answer in your example can't be authenticated (i.e. no AD bit can be set) because not all the answers (namely the CNAME) in the response have been authenticated (per RFC 4035, Section 3.2.3).
> 
> But a resolver would still authenticate the RR type at the signed target of the CNAME (assuming the target has an unbroken chain to the trust anchor), and record that RRset as authenticated. Otherwise, if it later received a query directly for the target name/type, it could not return the answer that it incorrectly didn't bother to authenticate.

Maybe the embedded assumption I’m making here wasn’t clear. I’m talking about a stub resolver implementation. I think that all stub resolvers should be able to be asked to do validation, and should do validation if asked. You could argue that they should be required to do it, but I don’t think we’re there yet, and I’m probably a bit in the rough on requiring resolvers to do validation if asked.

The question is, if the stub resolver can validate, and has been asked to validate, in that case what do we do if the CNAME is not in a secure zone?  Your response makes it sound like you know the answer, but I don’t think it’s specified anywhere. So I’m asking (a) if anybody knows that is specified somewhere, and if so where, and (b) if it is not specified, what do we all think the correct answer is.

Your answer actually brings up a second, also interesting, question: if a stub resolver sets the DO bit, and the CNAME is not in a secure zone, but the answer is in a secure zone, do we set the AD bit? It looks like according to RFC4035, section 3.2.3, we do not. So in that case, is the resolver obliged to validate the answer it gets by following the CNAME? It can’t set the AD bit in this case, right?