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

Ted Lemon <mellon@fugue.com> Thu, 30 April 2020 18:46 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 ED2923A0EC0 for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 11:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MoJr_ugnhcgn for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 11:46:37 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 04E893A0D9F for <dnsop@ietf.org>; Thu, 30 Apr 2020 11:46:24 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id o10so5934273qtr.6 for <dnsop@ietf.org>; Thu, 30 Apr 2020 11:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jT6l4WtJVoPZ+bWIimKZ1wv4aXGA4P3BJpu1OsAcj9A=; b=jb8ia5Ap25xLLYBxGbsEBLOSWdasBnmTKaOzcyM5Ay11R3DUPvNJKIKkRaiEHWIuMr OWD5iXDk2esJd1DLQWdbGoadozRcYj5jHXL6rQaCqrq6lFTmrJmqeBvxZ+UKokMNjZLo K7FgvcJPU8mEMhScr1/iUeiabDo/w/kwZgnMiuOM5IyPnRcdTsEi8OFPjvo2q81JzueU cyzmQCvKqOSPqtRRD50AILsB9nMSbUhONVr+Mz0AMg7hONtZwrvyX2KIfU5kH+gkbvIW JLSgHj9ELZOVc2MzgPEGVXZnnN1UGO6uok3xeh3OKDT7L+YcsSBCHvIC0V9mVVWz288C k7RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jT6l4WtJVoPZ+bWIimKZ1wv4aXGA4P3BJpu1OsAcj9A=; b=gBi2Qpu77E/kX1VMnc1oiWrtGaMIzTyAcjTGv18cUSsL/hqbugh2ebGAO4dNjMMuuP M5RtQ4AOirOElYO3T9LSyypOrm0W8ox30BT5G9Fqfi4qUlwL0Oox0FBU5iezIzah1Aac Sin0V1ZA0ssllM2wBrhffik5a6TXCIB45EpWZWHYgrd5R4h6Xc/zL6JVW3+T3cmAkTBl LBaHo+H/ZFQ5U7sMVvfjJa/bB6lugH3R+u2iE/wm5MxyUa+Jqi2Bd8GQelPgjBPJyPSN I/5HLmN1yJ15Y3Q8pAmJzkJhpfrBGpY5+JFjhvr+9dzemDwC7PhtvWI9f2uQoSSnLEdi Pq4A==
X-Gm-Message-State: AGi0PuYKANTGV/C95xyQXCmHOOtHxH3LExBbnLBRcVdcwK5AdYq54lDu CC2+KtRVUqp8YT1Mm2TA67yxP7GUeiA=
X-Google-Smtp-Source: APiQypLdn+6MzkagRwJsQNW8V5UQDPmvL4B0g6mWqWJeiFewOzGIWPpNewjG+OrfLi9gdijseHLUVQ==
X-Received: by 2002:ac8:5645:: with SMTP id 5mr5175506qtt.151.1588272383815; Thu, 30 Apr 2020 11:46:23 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:6c32:ff89:a73c:ef1c? ([2601:18b:300:36ee:6c32:ff89:a73c:ef1c]) by smtp.gmail.com with ESMTPSA id u27sm430889qtc.73.2020.04.30.11.46.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 11:46:23 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <2F9A828C-FC80-498D-B8C2-3DC804D75B0E@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_32B67779-0C59-4432-A77E-B0131E5E765C"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3636.0.1\))
Date: Thu, 30 Apr 2020 14:46:20 -0400
In-Reply-To: <e085e747-21f3-145e-2613-81c2a144ede6@nthpermutation.com>
Cc: dnsop@ietf.org
To: Michael StJohns <msj@nthpermutation.com>
References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com> <129b0546-0123-30e0-cfca-8a66721ab046@nthpermutation.com> <6311BB51-4617-4316-A56D-EEA73A42D4A0@fugue.com> <e085e747-21f3-145e-2613-81c2a144ede6@nthpermutation.com>
X-Mailer: Apple Mail (2.3636.0.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vMmtpHw0pQwf-LKSF6z5RTfCKLo>
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 18:46:47 -0000

On Apr 30, 2020, at 2:31 PM, Michael StJohns <msj@nthpermutation.com> wrote:
> Because an attacker can twiddle with a CNAME.  So while the recipient sees a CNAME pointing at a validatable end item, that may not have been the end name the publisher provided.   I'd probably say unsecure though, as I don't expect the client can detect bogus in this case unless there was a rule saying this was a bogus configuration.
> 
> Mike
> 
> ps - What's the validation level for a secured CNAME that points at an unsecured CNAME that points to a secured A record? 
> 
I think that what we’re really talking about is that we have some chain of items where some items are provably not signed, and some are provably signed and have been validated. Any items that do not match one of these two criteria can be treated as “unknown.”  So:

* If _all_ the items are provably signed and have been validated, the answer sets the AD bit.
* If _some_ of the items have been validated, and others are provably not signed, then the answer doesn’t set the AD bit, but an answer is sent.
* If we have a partial answer because we didn’t get some answers, is that any different than the case where we got bogus answers?