[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