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

Shumon Huque <shuque@gmail.com> Thu, 30 April 2020 11:58 UTC

Return-Path: <shuque@gmail.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 C38F83A0AD9 for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 04:58:13 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dkbg_bOhDKeb for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 04:58:11 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 B764E3A0AD5 for <dnsop@ietf.org>; Thu, 30 Apr 2020 04:58:11 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id p16so4249492edm.10 for <dnsop@ietf.org>; Thu, 30 Apr 2020 04:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BtEt1kDlcS7vRXkMIzYHysWCtk9V+IQBTpvZ6hGmSO8=; b=UvP+eztgKw+u6GxWedIYZmRvhGx2MPLVYzpXz0c5+OHUvDt7SbChnyp/92kx521IbD ls2HeBx20d/WDYZMrjKBzoxyYrp9i743AuJSinnH1+dBjhIBY1N8g6WfBPqwm5P+PXYz 5JLkrAnKBzsrHNrDKQozNuCy3Z4Y6wsHgpzMi7+4Quv002XEg4owvekjNmBkhveSwLWh hVPA60NKrSBFDXYQ6hTTjOqmzmLzQAVldP3q8KGPbH/Qcio15/ZbwAS+mPNsWTefsm7J PQvjMbImxhc1q29lF56lEQSjwXdPPvnmE+Im0vnDinoEfygTBfGqcTxTXf+ckgFbfT5K AefQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BtEt1kDlcS7vRXkMIzYHysWCtk9V+IQBTpvZ6hGmSO8=; b=HXfcornPAhBGfq8KbshddkUO6dIfnwkC4USCv+KYWGE+heiUz28phmbnqR1oGzCU7U wRQadKs2TVNK8yQpv+rRHluBElDkfC0g1g7dBZZl56KjwLjcZzGMWxn1+l5uk3Psmjbv Ii8tYk9FSL81h2m5oiwlVQ4f98jFfPVbjUOYVpnhjxYhudb4wG8SmxmZqz01afGUakz8 k327MRQloyPe7fJygwsl7D1O1y3XmaFtV5kAWqnR2YWeljKT6y3GZbIiaS+t3iWy+WxN Id4TTguY24X6dYz7SdPLFdGwuxsCepbHjQ6cNlC0mLfagBY03vXmltgSGssALwsCGc02 /joA==
X-Gm-Message-State: AGi0PuYCyjnZEL3K3q9d+gba4LIujHJKZ9iYifopW0yUs1hpac3j/l3E 2FlNq193SBE1zOCnGFBM8DbihAIl10sPPjXoqLo=
X-Google-Smtp-Source: APiQypKVXt/Z009XkUfKrOnLg4jz0+C4Yjr5KNskRNHF6pM808RDL0YVUlfLrjQwVkUXDYCBQHIYu3QCK/yn2gy2ooA=
X-Received: by 2002:a50:9547:: with SMTP id v7mr2344333eda.324.1588247890127; Thu, 30 Apr 2020 04:58:10 -0700 (PDT)
MIME-Version: 1.0
References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com> <CAHPuVdXWqA8Lu+Xy-rnad9UQvvAfawLk6-+G=GLCmGuMjfoZWA@mail.gmail.com> <9D709E73-83E1-40A8-8E97-CCBDBBDF80E8@fugue.com> <CAHPuVdVGBsNGZer9=cVjpMU5nDozyky2bVKxKBiTUXWQWvfuNg@mail.gmail.com> <3a1e86a8-353b-feab-cfe7-3316aee8e799@nic.cz>
In-Reply-To: <3a1e86a8-353b-feab-cfe7-3316aee8e799@nic.cz>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 30 Apr 2020 07:57:58 -0400
Message-ID: <CAHPuVdXdYdtt7dwd=xbQbWp4Gj+EGQCypFOgpPzeOJ-Y3Vyx4g@mail.gmail.com>
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Cc: Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e6e9905a480c74f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/boN8UMX3aYZPUzVI3Kqz5-0PEZc>
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: Thu, 30 Apr 2020 11:58:14 -0000

On Thu, Apr 30, 2020 at 5:39 AM Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
wrote:

> On 4/30/20 2:01 AM, Shumon Huque wrote:
> > It definitely can't set the AD bit. So, I suppose your argument is why
> > bother authenticating the target. That's a defensible question. [...]
>
> Certainly not defensible.  The AD bit isn't the only part.  What if the
> CNAME target is spoofed (BOGUS) or something?


Yeah, that's a good point, and I agree. The whole response can be spoofed
anyway because the preceding CNAME is insecure. But as a general
security principle, validators should validate everything they are able, in
order
to reduce the number of points in the system where spoofing can happen
undetected.


> Actually, I believe most
> end-clients don't look at AD, so it's just the SERVFAILs that protect
> them from using spoofed data.
>

In this discussion, I'd read the AD parts as a proxy for the validator's
assessment of the security state of the response (from which the AD
setting is derived). It's true that the majority of clients don't look at
AD,
but there are notable exceptions - quite a few DANE SMTP client
implementations do I believe.

Shumon.