IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt

Russ Housley <housley@vigilsec.com> Mon, 12 June 2023 18:52 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EC4C14CF18 for <sidrops@ietfa.amsl.com>; Mon, 12 Jun 2023 11:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmiXcnUn8Uox for <sidrops@ietfa.amsl.com>; Mon, 12 Jun 2023 11:52:18 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0724CC14F6EC for <sidrops@ietf.org>; Mon, 12 Jun 2023 11:52:18 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 524A7181DC3; Mon, 12 Jun 2023 14:52:17 -0400 (EDT)
Received: from smtpclient.apple (216-196.icannmeeting.org [199.91.196.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 2CAC8181D2F; Mon, 12 Jun 2023 14:52:17 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <D100381E-6498-4EAD-B056-18F89836C097@ripe.net>
Date: Mon, 12 Jun 2023 14:52:06 -0400
Cc: Martin Hoffmann <martin@nlnetlabs.nl>, Job Snijders <job=40fastly.com@dmarc.ietf.org>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <96D52BC8-C3BA-43C8-90E1-DD2621C2292F@vigilsec.com>
References: <168621843689.33017.6897451444105786551@ietfa.amsl.com> <ZIGogKIH4Srb8Nxt@snel> <20230608181440.33d6926f@glaurung.nlnetlabs.nl> <0C543A94-F70E-4A40-8350-C98FAAB5A9B5@vigilsec.com> <D100381E-6498-4EAD-B056-18F89836C097@ripe.net>
To: Ties de Kock <tdekock@ripe.net>
X-Mailer: Apple Mail (2.3731.600.7)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QYR-3XRVMYlLEwncYCerym-skWQ>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jun 2023 18:52:19 -0000


> On Jun 9, 2023, at 9:28 AM, Ties de Kock <tdekock@ripe.net> wrote:
> 
> Hi Russ,
> 
>> On 9 Jun 2023, at 15:57, Russ Housley <housley@vigilsec.com> wrote:
>> 
>> 
>> 
>>> On Jun 8, 2023, at 12:14 PM, Martin Hoffmann <martin@nlnetlabs.nl> wrote:
>>> 
>>> Job Snijders wrote:
>>>> 
>>>> The internet-draft changes is best viewed by comparing -13 and -15:
>>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-profile-13&url2=draft-ietf-sidrops-aspa-profile-15
>>> 
>>> | ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF ASID
>>> 
>>> This should probably be a SET rather than a SEQUENCE? This gives you no
>>> duplicates and a canonical DER encoding for free.
>> 
>> Martin:
>> 
>> DER encoding of a SET requires a sort.  DER encoding of a SEQUENCE preserves the sender's order.  So, while I agree with your observation about the semantics, I'd rather avoid the sort.
> 
> We have
>> The elements of providers MUST be ordered in ascending numerical  order.
> 
> In the text. My understanding of how a DER encoded SET is that this would imply
> this order. Is this correct?

Not really.  The sort includes the tag, the length, and the value, so it depends of the SET definition whether you will get ascending order.

Russ

v2.23.0 | Report a Bug | By Email