Re: [DNSOP] SVCB and HTTPS SvcParam multiple value order on the wire

Mark Andrews <marka@isc.org> Fri, 31 July 2020 10:45 UTC

Return-Path: <marka@isc.org>
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 3A6A83A1270 for <dnsop@ietfa.amsl.com>; Fri, 31 Jul 2020 03:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sd7DUsn0nSSq for <dnsop@ietfa.amsl.com>; Fri, 31 Jul 2020 03:45:46 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82EAE3A11E7 for <dnsop@ietf.org>; Fri, 31 Jul 2020 03:45:45 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0EA033AB003; Fri, 31 Jul 2020 10:45:45 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id F28E8160043; Fri, 31 Jul 2020 10:45:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DB98416005D; Fri, 31 Jul 2020 10:45:44 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CxNRqyERLxdg; Fri, 31 Jul 2020 10:45:44 +0000 (UTC)
Received: from [1.0.0.3] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 2D79A160043; Fri, 31 Jul 2020 10:45:44 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <88b7c20d-3bf1-6019-5834-646f3d14ddaa@powerdns.com>
Date: Fri, 31 Jul 2020 20:45:38 +1000
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <90CBF367-6B8C-4137-870E-8B59CD7A61B9@isc.org>
References: <88b7c20d-3bf1-6019-5834-646f3d14ddaa@powerdns.com>
To: Pieter Lexis <pieter.lexis@powerdns.com>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/URWUWdWX6iIj-e8Sw2VkzhLfCBM>
Subject: Re: [DNSOP] SVCB and HTTPS SvcParam multiple value order on the wire
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, 31 Jul 2020 10:45:50 -0000


> On 31 Jul 2020, at 19:46, Pieter Lexis <pieter.lexis@powerdns.com> wrote:
> 
> Hi folks,
> 
> I'm working on implementing SVCB and HTTPS in PowerDNS and I have some
> questions about the wire-format for the multi-value parameters like
> ipv{4,6}hint and alpn.
> 
> When there are multiple IP addresses in a hint, in what order should
> they be on the wire?

As they are entered.

> I would expect them to be ordered like an A/AAAA
> RRSet's RDATA to be sorted as specified in 4034 section 6.3 ("… are
> sorted by treating the RDATA portion of the canonical form of each RR as a
> left-justified unsigned octet sequence in which the absence of an octet
> sorts before a zero octet."). The draft says the hints are "an unordered
> collection", but it would be great to mandate an on-the-wire ordering
> here.

RFC 4034 is about validating a RRset. One needs to have a defined order
to DIGEST the RRset.  The order of the records on the wire is UNDEFINED.

> This will only work, of course, if multi-valued SvcParams are a set
> (where duplicates are disallowed/ignored), which is also not explicit in
> the draft for ipv{4,6}hint and alpn.
> 
> For the "mandatory" key, a sensible ordering (ascending) is specified
> and it is explicit that a key can only be present once in the set.
> 
> Cheers,
> 
> Pieter
> 
> -- 
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org