[Sidrops] Roadmap towards shorter-lived Trust Anchor certificates
Job Snijders <job@sobornost.net> Wed, 18 December 2024 17:11 UTC
Return-Path: <job@instituut.net>
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 F4177C14F5E6 for <sidrops@ietfa.amsl.com>; Wed, 18 Dec 2024 09:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.653
X-Spam-Level:
X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20230601.gappssmtp.com
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 HKWQkrBqHipC for <sidrops@ietfa.amsl.com>; Wed, 18 Dec 2024 09:11:29 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186DAC14EB1E for <sidrops@ietf.org>; Wed, 18 Dec 2024 09:11:23 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5d7e527becaso2470260a12.3 for <sidrops@ietf.org>; Wed, 18 Dec 2024 09:11:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20230601.gappssmtp.com; s=20230601; t=1734541881; x=1735146681; darn=ietf.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=lQIIxhRF+adjq367nt/Sskv13QoYsBpfs0kAUO3BRvA=; b=sDcSuro1PnUwBZ1LaGU7fVRZDpWJ7+TEKMmlHADdXVJTUcAlCKShWY/F+gGw7VTNwV ZzmAnhUT59WeGW/DdbNzVVHR7EzEMNEJxkQbmg9iB0KtxAi07wIOpjjGACUHAyh9Tfkr U/kdg+dCGBUOCmqzF9lX/EGeNfThTQAdaClqQgRRQs137g2AcMUyoRCTC5i7e3mrhRcW vSXQ4sWIWM3ecsF5vCLe7f4Pr2SsL3aXof31QberPr7r2nvJTNt+nNPYSbv/I4bGt7QP +qzofAaNeBjIgsNuVOo+GpE1qgWgJCNx6xuof7dzOl/VMDFsUwWZuURZoeYuvfkiovAf 2fFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734541881; x=1735146681; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lQIIxhRF+adjq367nt/Sskv13QoYsBpfs0kAUO3BRvA=; b=t43lF41XRYs51/10Pu/ILZSOtRlbTsFEEo4fwvz15ENUwRsgDwuUR+q97yMpavwlbv YQvOJ/orSJjouvRN84CT4Ymrv5fx/yAZ/ljUG8pdb/LzMjghYm8u1aUCD3zlDmKlXy8E QWpd+HwPQtoWc76oWX0r3MxQRol9atNswJifQ5dbUvYct/NT1IdpaTfnla21Ss/ucf27 jPL2b1YJRNCY0m2ytxK/tECILV81wTcXh7ItHLXnJI02CoUcHtnitJOv2HbgsW4QOaIl 5aJsDrxHWBlbzPe2OLDc5wmBITna+seQnZwZ9cS/M1qii5tm5QTfbqKOTMCbGXADNUpB lc9Q==
X-Gm-Message-State: AOJu0Yz14+9Xdmopi7pLyLWEKIcWODppAo5NGIkZNkk6cZL36UGzvdZC QanILzQhk3AgnVIJkHGHX2yJHRhmkPODMedNwLxkYp5M5qNHH5v2GJQVBoyq3DneN/Os5hLrmBz 6
X-Gm-Gg: ASbGncuZ0SHPKAqiZZMRckcjcta7dP2RQ/ToNhG1DP+hnCyg+L293K9Y0EJYgdgmf2G jlEXKVkhOZz0DyP8fg/ZhLHxgZw4UiPFO45zdaTqvswtqgz4PfLiMKwx4XwBVkut0vTxz4XZpvl lKsuKRpQQc94jS0oY3b1dNlWz8QWb4zdcbBAZ1ItCX+6FcL0hQ7iCyVtcKcJDsjlTxPHFIGrMOc qvqU5dYhGaLrFNB0aVS9nVRbnO8lyopVFHnhWVqi4e6FOxSB86CIa2b7yE4T+ary7URVdaQbA==
X-Google-Smtp-Source: AGHT+IHZlGKWDyBFYSf+25/4628tbQHEgbOsXVmOSZ6lPhbhuUyc/5uusWaFSllWDEs/U1O8/fshVg==
X-Received: by 2002:a05:6402:3605:b0:5d3:f55f:8349 with SMTP id 4fb4d7f45d1cf-5d7ee3fe303mr8709970a12.33.1734541880747; Wed, 18 Dec 2024 09:11:20 -0800 (PST)
Received: from anton.sobornost.net (anton.sobornost.net. [192.147.168.5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aab960065d1sm572835866b.6.2024.12.18.09.11.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Dec 2024 09:11:20 -0800 (PST)
Date: Wed, 18 Dec 2024 17:11:18 +0000
From: Job Snijders <job@sobornost.net>
To: sidrops@ietf.org
Message-ID: <Z2MCNtgid5giDLVa@anton.sobornost.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Erik Bais
Message-ID-Hash: AFKM25BDDIZ6LL6HOAKHTCJHH77ETC64
X-Message-ID-Hash: AFKM25BDDIZ6LL6HOAKHTCJHH77ETC64
X-MailFrom: job@instituut.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Sidrops] Roadmap towards shorter-lived Trust Anchor certificates
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-Y5NfXnGfDbeGOCAFj5xHgU90Zo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>
Dear all, The RPKI ecosystem suffers from a partially unmitigated risk related to long-lived Trust Anchor certificate issuances. *** skip to the end for a simple schedule & todo overview *** For this to make sense, don't confuse certificates and keypairs! TA keypairs (and TALs) are expected to be very long-lived and are to be used periodically to issue new instances of (shorter-lived) TA certificates. Issues could arise when a on-path attackers (or, imagine operational errors such as restoring a super old backup of a webserver) bring back into circulation old (but still valid) TA certificate. Older certificates remain valid for the duration of their validity period, because TA certificates - being top of the chain - cannot be revoked. Here I shared real world examples of potential replayable certificates. Old problematic TA certificates that - today - still would pass validation: https://mailarchive.ietf.org/arch/msg/sidrops/NxzvSFH0sPXEmyfOS99cLApFKqM/ The trouble with these replayable TA certificates is that when an on-path entity ends up presenting such an outdated-but-still-valid certificate to RPs, the RP accepting that cert would damage the RP's local validated cache. Parts of the validated output will disappear, in an unpredictably manner. Periodic reissuance is important because TA certificates are not entirely static, which of course is why replay might even be an issue in the first place!. There are 3 'dynamic' fields in TA certificates: - the validity period (notBefore, notAfter) - the SubjectInfoAccess (where can the RP find the first repository?) - the extensions for IP addresses & AS identifiers (RFC 3779 INRs) (the RFC 3779 extensions are of critical importance to the RPKI's chain validation algorithm) RIRs will want RPs to validate using the 'latest' issuance of the TA certificate, because a TA cert from 10 years ago obviously will be 10 years behind on operational decisions, potential SIA migrations, resource transfers, new IANA assignments, or any other updates to the RIR's current holdings. So how do we make good on this situation again? (Preferably without all RIRs having to rekey & redistribute new TALs?) The plan to overcome this risk has three steps: step 1) RPs to prefer shorter-lived Trust Anchor certificates over longer-lived ones. (rpki-client already implemented this) https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ta-tiebreaker step 2) RPs ship with scheduled future refusal of ultra long-lived Trust Anchor certificates, rpki-client has implemented the following schedule: Before February 2nd, 2026, warn on TA certs valid for longer than 15 years. After February 2nd, 2026, reject TA certs valid for longer than 15 years. Before March 3rd, 2027, warn on TA certs valid for longer than 3 years. After March 3rd, 2027, reject TA certs valid for longer than 3 years. step 3) Consequently, RIRs have to reissue shorter-lived TA certificates to avoid being rejected by RPs. The end result is that after anno 2026 / 2027, even when 100 year or 10 year certs somehow be brought back into circulation, RPs will simply refuse such long-lived certs, despite them technically being 'valid'. Why this works: The ta-tiebreaker mechanism provides an incentive for TA operators to reissue with reasonable (1 or 2 year) validity periods, as those certs will be preferred. In turn, RPs scheduling future refusal of long-lived certs at a predetermined future point in time relieves TA operators from worrying about previously issued ultra long-lived certs. It is a win win for everyone in the ecosystem! Scheduling details: I picked February 2nd, 2026 for phase 1, because 02-02-2026 is an unambiguous date both in the US and elsewhere. I picked March 3rd, 2027 for phase 2, because 03-03-2027 also is unambiguous and visually is very distinct from the phase 1 timestamp. My hope is that a schedule like this will make global coordination less error-prone, I also wouldn't want to impose undue burden forcing TA operators to reissue at short notice without adequate preparation time. I discussed this with various RIRs, so far everyone seems to think this is a reasonable approach. DEPLOYMENT STATUS ================= The above schedule will be programatically enforced starting with rpki-client 9.4, to be released in January 2025. Our hope is that more Relying Party implementations embrace this concept & schedule. In short - this has not yet been deployed in the wild! OVERVIEW WHO HAS TO DO WHAT =========================== Starting 02-02-2026, TA certs with a validity period longer than 15 years will be rejected by rpki-client. Starting 03-03-2027, TA certs with a validity period longer than 3 years will be rejected by rpki-client. LACNIC uses 100 year period, needs to reissue before 02-02-2026 RIPE NCC uses 100 year period, needs to reissue before 02-02-2026 APNIC uses 5 year periods, need to reissue before 03-03-2027 AfriNIC uses 10 year periods, need to reissue before 03-03-2027 ARIN already uses shorter lived TA certs, no need to take additional actions. ARIN's current TA certificate is valid for roughly 2 years. Closing Words ============= If anyone sees significant issues with this, PLEASE SPEAK UP. There is still time to change the schedule, or even back out the change to rpki-client. Thoughts? Should we also upload an internet-draft (not necessarily for RFC publication) to have a stable point of reference? Kind regards, Job
- [Sidrops] Roadmap towards shorter-lived Trust Anc… Job Snijders
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Job Snijders
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Tim Bruijnzeels
- [Sidrops] Re: Roadmap towards shorter-lived Trust… David Njuki
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Job Snijders
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Ties de Kock
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Dale W. Carder
- [Sidrops] Re: Roadmap towards shorter-lived Trust… William McCall
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Tony Tauber
- [Sidrops] Re: Roadmap towards shorter-lived Trust… Tom Harrison