Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Joe Abley <jabley@hopcount.ca> Mon, 10 May 2021 17:13 UTC

Return-Path: <jabley@hopcount.ca>
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 762133A2411 for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 10:13:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=hopcount.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 koXciI2GArcv for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 10:12:58 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 441633A240E for <dnsop@ietf.org>; Mon, 10 May 2021 10:12:58 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id c11so12393140qth.2 for <dnsop@ietf.org>; Mon, 10 May 2021 10:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3Feh9OOqPt+6M6dFHUV+Z95oZ9h5dW10bGO05AB17Hk=; b=dKJ/aP+Snkk+//D0FE5yd5qDz6ziSiYN4Qa5NOO49UJ5tcj50dZllhiKxjhmQySyu8 plrD8SWzm0hx/6P8jokoZehvtUk3z+ewl4V77H/KBCpXfmacZJ9yGbZa9Iash+RS72IX MuaXxgTk/xYx4gFpnzUNp6eN2vEzyceybkV8U=
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=3Feh9OOqPt+6M6dFHUV+Z95oZ9h5dW10bGO05AB17Hk=; b=qbc7uEUll2ZNiL+np1hxPokaGDVZE2fnCp4HZOsVsTmHXNqCBxnfaksWo95+SckNeR TfgX1nP5gK1JBGERXirDB5QN3RXqX6KdJ4I/ulxqtrglR/CajJ8ZtrZ0whqtv75vC2JM C49hf7ow1DJBTg7zhL2i2biqleDX4o4PzQzfT64CMhrV+qI9ou8jqjyRgMyMdOsoXv6f KlgedFcr5FZgyAkNntOwzYcP1RiH2yHvx8XEn8fD8rL2x5wwlmdikRtm1yIoJmjBPhGK hybM563WQi52OdaphwUhw8ry7tBtmVCPkHcWdXoMyfWI0wcBL1V6pqFsWVBwSCEKVEqI pu3Q==
X-Gm-Message-State: AOAM530fCOQ7xtuVcGf5zaIqc6AkH8CC4QGue0fcJqJ1SsjflBC/hVdg qhUEtJ4uByDh0Kq/SmatH//lCRcZyqQjTM0bDow=
X-Google-Smtp-Source: ABdhPJwZ0iNEnIswCTtQzEGAggJyIuVWR45+vm+J4Ra9X88kyqSrvqdATaooWEcygGnKsBbA5rn6KQ==
X-Received: by 2002:ac8:76c9:: with SMTP id q9mr23629284qtr.260.1620666776163; Mon, 10 May 2021 10:12:56 -0700 (PDT)
Received: from smtpclient.apple ([2607:f2c0:e784:c7:f88a:8f71:955b:ab3]) by smtp.gmail.com with ESMTPSA id 44sm12103003qtb.45.2021.05.10.10.12.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 10:12:54 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <BD123B21-3396-49AE-BF95-58374C73C317@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_93C1A5DA-7531-4FD0-830F-1E255138192F"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 10 May 2021 13:12:53 -0400
In-Reply-To: <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com>
Cc: Pieter Lexis <pieter.lexis@powerdns.com>, dnsop <dnsop@ietf.org>
To: Ben Schwartz <bemasc@google.com>
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gWsU0SjRX90DaJMZ7zDqHsT-JgE>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
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: Mon, 10 May 2021 17:13:04 -0000

Hi Ben,

On 10 May 2021, at 12:56, Ben Schwartz <bemasc@google.com> wrote:

> I don't support breaking the SvcParams into separate RRs across the RRSet.  This would be an extremely inefficient encoding in wire format,

I think that assertion may well be worth challenging, and...

> and would conflict with the usual understanding of resource records as independently meaningful alternatives.

... I think we disagree about how we usually interpret the use of RRSets with more than one member RR.

>  It would also require a dramatic rewrite of a specification that is now widely deployed.

However, this seems clear (see my earlier horse/sailed comment). Given that the draft semantics of SVCB have already seen some implementation, any new semantics would need a new RRType (SVCC? :-)

I admit I have a certain aesthetic bias here since I find the entire concept of embedding a list of parameters inside a single RR to be very un-DNS-like. However, I found Mr Wouter's concerns (paraphrasing, "perhaps we should pre-allocate a set of CVE numbers for this") worth considering, and would hope that if there is a reason to burn the current RRType on security grounds (or any grounds more compelling than aesthetic) that we would do so.


Joe