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

Joe Abley <> Mon, 10 May 2021 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 762133A2411 for <>; Mon, 10 May 2021 10:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id koXciI2GArcv for <>; Mon, 10 May 2021 10:12:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 441633A240E for <>; Mon, 10 May 2021 10:12:58 -0700 (PDT)
Received: by with SMTP id c11so12393140qth.2 for <>; Mon, 10 May 2021 10:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ([2607:f2c0:e784:c7:f88a:8f71:955b:ab3]) by with ESMTPSA id 44sm12103003qtb.45.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 10:12:54 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
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.\))
Date: Mon, 10 May 2021 13:12:53 -0400
In-Reply-To: <>
Cc: Pieter Lexis <>, dnsop <>
To: Ben Schwartz <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 17:13:04 -0000

Hi Ben,

On 10 May 2021, at 12:56, Ben Schwartz <> 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.