IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 20 June 2023 12:47 UTC

Return-Path: <tim@nlnetlabs.nl>
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 319FEC151071 for <sidrops@ietfa.amsl.com>; Tue, 20 Jun 2023 05:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 BQR4_Sqrybzh for <sidrops@ietfa.amsl.com>; Tue, 20 Jun 2023 05:47:21 -0700 (PDT)
Received: from dane.soverin.net (dane.soverin.net [IPv6:2a10:de80:1:4092:b9e9:2295:0:1]) (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 238D5C14EB1E for <sidrops@ietf.org>; Tue, 20 Jun 2023 05:47:20 -0700 (PDT)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4QlmcQ0Yyqz10nb; Tue, 20 Jun 2023 12:47:18 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4QlmcP4N81zH3; Tue, 20 Jun 2023 12:47:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1687265238; bh=zfgb5N87pcXlet1lUmnfJrBpJLApeoHx/nTTGdcBXIs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gB9dndKhuxdc8XnFgmuktH5HlBO2P3jPoPt1hWdythO2jx2nOiFPFh7g5Hp7Xl/8g oKYof9kMAc/ZOi77XsiCe/+SaPdQnDuyrANhe9kYbwDHZVmDGJjZhbCrE8VzOhIUHY hyLX2wO4srlb6pSkFqEG0jgPGk81lJUZYYGs9dKH5fIQ82u1pyK2HCTBPWqB8OVQBl 2wlssFs5UFvA3bJ8PQXqR23U3Gm2IzFUvY10fT++f8bTl4USAxpE1wjxU9RAFrrvug N2gj+xqMztvFWUz9cxpa9XtTlc0bafQY0o3IhsbHW3hG+/jHH7Yi58cz3GyBpKf6rp bAS/mWJalgH9Q==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
X-Soverin-Authenticated: true
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <38DD326C-3AA7-4E60-8C0E-3F00D0BD217A@ripe.net>
Date: Tue, 20 Jun 2023 14:47:07 +0200
Cc: Russ Housley <housley@vigilsec.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5BA5703-65C1-4523-B463-8B44BC03BE64@nlnetlabs.nl>
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> <96D52BC8-C3BA-43C8-90E1-DD2621C2292F@vigilsec.com> <20230613094413.364aaa8c@smaug.local.partim.org> <26E1759F-08FA-430D-8F89-BDC6C3DC4B9D@vigilsec.com> <20230613150156.29022a0e@glaurung.nlnetlabs.nl> <ZIitpTWScXigugLD@feather.sobornost.net> <04D76EAA-AD2E-4A76-8709-0D063E4310EA@ripe.net> <D562E769-D436-46FD-BD20-520FA495B4F2@vigilsec.com> <38DD326C-3AA7-4E60-8C0E-3F00D0BD217A@ripe.net>
To: Ties de Kock <tdekock@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ApFNBcIc9y8GBKpYfVbVCmw0bK0>
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: Tue, 20 Jun 2023 12:47:25 -0000


> On 14 Jun 2023, at 18:53, Ties de Kock <tdekock@ripe.net> wrote:
> 
> Hi Russ,
> 
>> On 13 Jun 2023, at 17:24, Russ Housley <housley@vigilsec.com> wrote:
>> 
>> 
>> 
>>> On Jun 13, 2023, at 2:04 PM, Ties de Kock <tdekock@ripe.net> wrote:
>>> 
>>>> On 13 Jun 2023, at 10:55, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
>>>> 
>>>> On Tue, Jun 13, 2023 at 03:01:56PM +0200, Martin Hoffmann wrote:
>>>>> Russ Housley wrote:
>>>>>> I do not think we want to have decode failures if the INTEGERS are
>>>>>> not in sort order.
>>>>> 
>>>>> I agree, but in the past the consensus in this group has been to
>>>>> rigorously reject objects that have something wrong with them. By that
>>>>> consensus, an ASPA with unsorted provider ASNs would be rejected on
>>>>> grounds of violating the MUST further down. In which case it might as
>>>>> well be rejected during decoding.
>>> 
>>> I agree with Martin's perception of the opinion of the group. Having the SET
>>> may get us a little bit more implementation resiliency here.
>> 
>> 
>> How?  SEQUENCE leaves it entirely to the application.  SET seems to be handled inconsistently.
> 
> 
> SET should give you the proper semantics on encode (as a safety net). When
> decoding I would expect an implementer to use a lower-level API that gives
> access to the elements in the SET/SEQUENCE iff an implementation does not do the
> checks implicitly.
> 
> I do not have a strong preference between SET/SEQUENCE. However SET is
> semantically clearer to me.

So, as I understand the 'free' DER SET checks will not work for some implementations. And they could lead to decoding errors that leave users unclear about where the actual issue is. The SEQUENCE on the other hand makes it easier to have consistent handling and allows applications to be specific about sorting issues. So, while I agree that in a perfect world, DER SET would be better, I also think SEQUENCE and application-level order checks is the safer more pragmatic option here.

That aside I just wanted to say that I see no issues in implementing the -15 profile on the CA side in Krill, except that I will most likely only have time to work on this in about 2 months.

Tim



> 
> Kind regards,
> Ties
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email