Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

Ben Schwartz <bemasc@google.com> Fri, 07 August 2020 14:42 UTC

Return-Path: <bemasc@google.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 8448D3A0DC5 for <dnsop@ietfa.amsl.com>; Fri, 7 Aug 2020 07:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JaavJ6ZZ0s1J for <dnsop@ietfa.amsl.com>; Fri, 7 Aug 2020 07:42:52 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 E4AC53A0DE1 for <dnsop@ietf.org>; Fri, 7 Aug 2020 07:42:49 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id q76so2073796wme.4 for <dnsop@ietf.org>; Fri, 07 Aug 2020 07:42:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NLMMojf+Omi2ZZCuAYtG9QKzJROor3N4vOAY0WJl4F8=; b=EDz04TxLiayg6oCo37nYGlTHsaP3PMu/Eh7ACo+4XunVxdZN6cJbUfZsGWavz+SsFo jktDl5gpIckB5wu5O8KDCFnL3yHAktN/yIJYyANhOLA10wfVADFQ/GAMmNtJXnIK05+i fcs/bG6tgkC9cTzN1K0CxMdDJRDv9B0V+QpG5G8UtclELCGXRUcnd376q2eB/jAxDMxD dOvNZm2Zy1weyp0MvokSWQSrVpsfZ4xdXx5bRsTP6B6idv3ssXi19C9pvl9fYltthP1N +yfxa6xIgH53XpeOr2YQzrgujSDVxsDV7LP/Gw5Apjvi3MLY9hgHnVDDvWOYsr9Xp3Nn o7sw==
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=NLMMojf+Omi2ZZCuAYtG9QKzJROor3N4vOAY0WJl4F8=; b=UoesT/NoiiNJpdkO/QSsOozTqtE+fUebhyvWURRslduLo6mVPraRjXZlBEpvuEJD5r vjM96dbtajPRSX4S5EW2lrOE2HlZDPSyWwXN0mDNDzVQtMrEXqekuVNYXJMo2NC7jvZW pY/A5zR9xI4sQpo1WdY8nyzBJMyXQyGB54uS4iGqEecc2iauA9ZPQjtisxxKlt81Ekjc UMZ51bjMzMnaXhHicA00VKxQLC63iqXFOPl7Pbzz6DC6eqhQT42W6qOb58QiYZaSNk88 6JVn2TvnrhJE+zEdRryJfBl3oa4wnkInFcLih9zKW7JO01WGJ1llYoGhQpWO/3IH/r9v Lilw==
X-Gm-Message-State: AOAM532/9lisb+Y0qpgRnbvL/s7Ady/V1cWlwQpGDnE3unBrbFz9dVIE DwUI34+qmAtplnah4rOKX+NzJ/g31jWcfwue3rJ2bQ==
X-Google-Smtp-Source: ABdhPJzg5jpLXQiFrVf2GQ/UNV6mZWJSY097zIeFPOdGexKqicKKj+JF0KqSmOzIiJJih2dw40FpZ+NPsHwDvHyBMNs=
X-Received: by 2002:a1c:49c6:: with SMTP id w189mr12355537wma.97.1596811368158; Fri, 07 Aug 2020 07:42:48 -0700 (PDT)
MIME-Version: 1.0
References: <00cfd965-bf69-d1cb-2df3-1a9bb110d7e0@powerdns.com> <CAHbrMsAJ-cbcW3v4T34f8-gzgzgHSkoBO545_Y3N8D6rof7Nmw@mail.gmail.com> <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com> <cd6021e7-4aad-c2fc-e9ef-948fbeab0809@powerdns.com> <8BC20DED-784F-4004-9E56-8BB2F6356FA7@isc.org> <9390cb8a-677f-7309-b466-c45643827b22@powerdns.com> <DCAF1704-B545-4AB8-8133-85E7280ADCD6@isc.org> <CAH1iCioaitgh1JYNLcqawkg06WLG8FqmmDV0LkOrAaqUuNBNcQ@mail.gmail.com> <9F828CCE-81C5-4354-874B-93D7CFC3E730@isc.org> <CAH1iCipP7p8UayYAgzWSO3CTYZryJX_NVqPJka4je982wjsrKQ@mail.gmail.com> <A87E8638-FBAD-448B-AA84-57C86E52169E@isc.org> <CAH1iCiq7gdStPrUcVf7B0jx6n28Y93ex14qWdt1m9zk-K21BsA@mail.gmail.com>
In-Reply-To: <CAH1iCiq7gdStPrUcVf7B0jx6n28Y93ex14qWdt1m9zk-K21BsA@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 7 Aug 2020 10:42:36 -0400
Message-ID: <CAHbrMsBKX0VxuCHjnV1J9FqRxmOW9TpkBWbXL6Ja300e+K__DA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Mark Andrews <marka@isc.org>, Pieter Lexis <pieter.lexis@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000669a4505ac4a9e1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qOQf5De_5VbyXmtmeciO3_UJ7Ic>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
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: Fri, 07 Aug 2020 14:42:55 -0000

On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Thu, Aug 6, 2020 at 9:42 PM Mark Andrews <marka@isc.org> wrote:
>
>>
>> Sorry you just broke DNSSEC if there are more than one AliasForm
>> records.  More than one is permitted with the same name.
>>
>
> Good point.
>

I'm not sure I understand this problem.  The authoritative server could
deliver the whole SVCB RRSet with its signature, along with the chain from
following (just) one of the AliasMode RRs.  This is the behavior that is
required (in the current draft) of recursive resolvers (and clients).


> "More than one is permitted" is the case only because of the current spec.
> I don't see any explanation for why this is (or needs to be) the case.
> What would be wrong with changing the spec to prohibit more than one
> AliasForm record at a given name?
>

The current text says "SVCB RRSets SHOULD only have a single resource
record in AliasMode."  Early drafts say "RRSets MUST only have a single
resource record in this form." (
https://www.ietf.org/archive/id/draft-nygren-httpbis-httpssvc-03.txt).  I
believe this was changed because declaring that RRSets MUST only have one
record, and also declaring what recipients should do if there are more than
one, seemed like a contradiction.  Also, round-robin AliasForm seemed
harmless, and potentially useful for multi-CDN.

Now, suppose only one AliasForm is permitted (just like CNAME), what
> downside would there be?
> The handling of multiple AliasForms at a given name should be handled in
> the same way that having more than one CNAME is handled.
> That seems like it wouldn't be hard.
>
> And as far as I can tell, the ServiceForm is the thing for handling the
> multi-CDN, availability, etc. issues. It's the right tool for the multiple
> RR situation.
>

Correct, ServiceForm is the intended solution for multi-CDN.  Using
round-robin AliasForm for multi-CDN would give less fallback capability to
clients (they could only use one CDN or the other), but would reduce
coupling between the CDN and customer (no need to copy SvcParams into the
customer zones, where they might be hard to update).

...

>
> I'm willing to drop the Answer vs Additional section for in-bailiwick
> TargetName (plus A/AAAA) placement.
> (However, I'm not the only person in the WG other than the authors; others
> may have stronger feelings about this, since at least one person concurred
> with my original post.)
> It's up to the WG on this latter issue (placement), I'm good with whatever
> the consensus is.
>

I wonder if the most popular option would be to allow either behavior, and
instruct recipients to check both sections.

>