Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)

Job Snijders <job@fastly.com> Tue, 13 February 2024 19:15 UTC

Return-Path: <job@fastly.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15982C151535 for <opsawg@ietfa.amsl.com>; Tue, 13 Feb 2024 11:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 ho6zRH7OAfGc for <opsawg@ietfa.amsl.com>; Tue, 13 Feb 2024 11:15:04 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 1BE15C19ECB3 for <opsawg@ietf.org>; Tue, 13 Feb 2024 11:15:03 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-558f523c072so7208842a12.2 for <opsawg@ietf.org>; Tue, 13 Feb 2024 11:15:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1707851702; x=1708456502; darn=ietf.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AfhCcV2WQ0clGu0ZNeqzjPX60mqsfjS/TvSe8TdTSoQ=; b=rxI4Uq32NV/+E9H0C9wjsotx0d062HmYvegEmh5cntOLYh9hhl8q1XQXR1fw+KOSxP svk3Gg7jkDVH4Lzsq/hfnBboI89X4MrvZAao4qUNmEpQVmZxC3uI4N+iyGf5Nj5uVY+9 LQL/8SVFEleh0PPRI1VonY7Ya8UsK/yCQ45B8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707851702; x=1708456502; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AfhCcV2WQ0clGu0ZNeqzjPX60mqsfjS/TvSe8TdTSoQ=; b=ae4tDIEXzeChzteGV1cxyWZrW/bg/vcwHWO345plpE6rsHUbVON9lU4xspftbRQAyr WVxxca0ss7emGeIDIIZrZtmNBbUZPuw+PZ6B5u1E0Q5YbZjLrol7jN9fc61RNlTBYOKp R2Ib+RVc5LUwU4lqlurADhZLiYb9r/jvTbtEZ5QW3h/hehR5wkhRe2Q/BAN5buO1K1NO C6scRVnWLhbXtkwbwhEUCKTlJfy5RfmqXVLO/Onvrf3Ev2Lu4mnbjQjCgXHttFvw/dJ3 Jv5Mwp0JVQay4sZ4RoKoDoLKcwa/PUjbymsDJ54s8mQZ9zMHByt5C4li0kIgw2ipRZ6/ d5fg==
X-Forwarded-Encrypted: i=1; AJvYcCVRnsrB+JVVO2M7s2e4WUFOqUr0xnMSUU2cbCIYyqSSFR9mrbas24Uy2o8c6Supx+OoTQgyPJVX55iI9WTooVk=
X-Gm-Message-State: AOJu0YwPZqB1aMvpEBkzE7eOsEmLWN+wJBFTg532g0CsY2hiDa9Zv4q7 Hat2qgRuzKBRZenlCEQCofEPyDpHFxehwp/FS9EUk25MZYG/qUdNiZ9MaNgRuys=
X-Google-Smtp-Source: AGHT+IHS95ulLf/u/ceuG9BhjTzxZnOgCtUeNvyD3ZNDEobuY/txXcoYlIG1j3uUD7m/Kx3C+ULy6Q==
X-Received: by 2002:aa7:cb4a:0:b0:561:a59f:a3cd with SMTP id w10-20020aa7cb4a000000b00561a59fa3cdmr440910edt.23.1707851701829; Tue, 13 Feb 2024 11:15:01 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCW996j1E2zU+O5dhL9v0jQIY71piuyFojW8a0XCs52vbK/74kpLt1H1LBCxKDMG9xMCbKrLRdoeJrxRY1xOM3ku95RjZFGyXG8MNduuhQoFfjrTFT2Ej0m7fbCcTN/2QFFdZqluZqdW8aLR1LzeL0si4VnWWLIrzwcT/pT3vDWOjeSCka55n0cl5+vKP91EDQ==
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id c3-20020a50d643000000b0056022d78141sm4231965edj.56.2024.02.13.11.15.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 11:15:01 -0800 (PST)
Date: Tue, 13 Feb 2024 20:14:59 +0100
From: Job Snijders <job@fastly.com>
To: Paul Wouters <paul.wouters@aiven.io>
Cc: The IESG <iesg@ietf.org>, opsawg@ietf.org, draft-ietf-opsawg-9092-update@ietf.org, opsawg-chairs@ietf.org
Message-ID: <Zcu_s7DEjld5vhPE@snel>
References: <170784829052.7939.16825522646369028165@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <170784829052.7939.16825522646369028165@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/LRkXreIhsZgs4eNoWFA8fhwfKJo>
Subject: Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2024 19:15:08 -0000

Dear Paul,

I implemented support for validating Geofeed signatures in OpenBSD's
RPKI implementation. Section 3 and 4 of your DISCUSS message relate to
this implementation work.

My implementation here is based on draft-ietf-opsawg-9092-update:
https://github.com/openbsd/src/blob/master/usr.sbin/rpki-client/geofeed.c
The geofeed_parse() function is passed contents of the entire Geofeed
file and the length, and then starts to parse the content, it should be
fairly straightforward to follow if you are familiar with C.

As to trailing lines, it seems pretty common practise for parsers to
ensure that they consumed the whole thing and no bytes are left
unparsed, as allowing (or not explicitly disallowing) trailing garbage
may lead to a potential for malleability.

The RPKI community (mostly folks around sidrops@ietf.org) in recent
years has made an effort and good progress to ensure that object
profiles contain *only* what's relevant for the validation at hand. This
massively helps implementers, because when reading an instruction such
as "The signing certificate MUST NOT include the Autonomous System
Identifier Delegation certificate extension [RFC3779]." - the
implementer will know that AS Identifiers play absolutely no role in
this context. If a superfluous extension is encountered the
authenticator is invalid. Nowadays, all RPKI profiles are explicit in
this regard. See for a comparable approach this IESG-approved draft:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rfc6482bis-09#name-roa-validation

I understood the goal of the draft-ietf-opsawg-9092-update effort to be
unambiguous, more explicit, prescriptive, and thus leaving nothing to
the imagination of the implementer.

As to re-use of keypairs: one certainly can issue multiple certificates
with the same keypair, the advantage of 'one-time-use' EE certificates
as used in this document is that the CA can revoke individual versions
of the Geofeed file. If the certificate is 'recycled' (same serial, wide
validity window) this property is lost. I think the 'SHOULD' is
appropriate here because is hard or impossible for Relying Party
implementations to actually force CAs to issue a certificate for each
Geofeed file.

Finally, I think what you might be missing is the natural language
equivalent of "goto out;" (as is sprinkled throughout my geofeed.c
file), but the draft (near the end of Section 5) concludes with: "All of
the above steps MUST be successful to consider the geofeed file
signature as valid." - which to me means that any deviation from the
MUST's results in an invalid authenticator.

Kind regards,

Job

On Tue, Feb 13, 2024 at 10:18:10AM -0800, Paul Wouters via Datatracker wrote:
> Paul Wouters has entered the following ballot position for
> draft-ietf-opsawg-9092-update-10: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> "Handling Ballot Positions" - see
> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> 
> I have a number of DISCUSSes, none of which should be hard to address or talk
> out :)
> 
> #1 document track
> 
> The document is Standards Track, and so are the docs is Obsoletes/Updates
> ([RFC2725] and [RFC4012]), but the document also claims "change control
> effectively lies in the operator community". Normally, that would mean the IETF
> publishes this as Informational. But of course that would raise the issue that
> an Informational would Obsolete a Standards Track document. Some discussion on
> this would be good.
> 
> #2 Transport Security
> 
> There are quite a few sentences scattered through the document about transport
> security that are not aligned, see:
> 
>         The URL uses HTTPS, so the WebPKI provides authentication
> 
> So is HTTPS mandatory? I guess not since (see below) FTP is allowed as URL too.
> 
>        the RIR's FTP [RFC0959] services SHOULD be used
> 
> To speak in the words of the great Monty Python, "An active or passive swallow?"
> 
> More seriously, can we avoid SHOULDing the FTP protocol?
> Are these resources not made available over HTTP? If they are, can we
> SHOULD that instead?  Note the paragraph above it says: "Historically,
> [...] often without consistent authentication". I wouldn't call that
> "Historically" if you are are promoting FTP and allow "unsigned" files.
> 
>         The geofeed files MUST be published via and fetched using HTTPS
>         [RFC9110].
> 
> Uhm. So what about FTP now?
> 
> The Security Considerations could bundle all the talk about HTTPS and FTP and
> put in one clear clause here, mentioning that due to lack of universal signing,
> it is sadly super important to have transport security protection (eg HTTPS,
> not FTP)
> 
> #3 Signature and white space requirements are a bit troubling
> 
>         Trailing blank lines MUST NOT appear at the end of the file.
> 
> That's rather strong. Should the file be rejected if a blanc line appears
> at the end? If not, I wonder why to even mention this, especially with 2119
> force. Based on:
> 
>         If the authenticator is not in the canonical form described above,
>         then, the authenticator is invalid.
> 
> That is a "yes the file should be rejected if it has a trailing blanc line". I
> think that is unwise, I would like to hear the reasoning behind this.
> 
>         When present, such end-of-file markers MUST NOT be covered by the
>         digital signature.
> 
> This is going to cause problems if people make detached signatures of the file.
> What is the reason for this requirement?
> 
>        The CMS signature does not cover the signature lines.
> 
> This gets really complicated now, when we read the above item on blanc lines.
> Does this mean the blanc line MUST NOT appear before these # comments? Or not
> after these comments? Or both? Can there be a blanc line between geofeed content
> and signature? How about two blanc lines?
> 
> #4 Misc. Security comments
> 
>        The address range of the signing certificate MUST cover all
>         prefixes in the signed geofeed file.
> 
> I vaguely remember huge problems with such similar requirement. The document is
> not clear what to do when this is not the case? Reject everything? Or only
> accept those entries that ARE covered? More guidance is needed here.
> 
>         The signing certificate MUST NOT include the Autonomous System
>         Identifier Delegation certificate extension [RFC3779].
> 
> What must one do if this does include it?
> 
>         As with many other RPKI signed objects, the IP Address Delegation
>         certificate extension MUST NOT use the "inherit" capability
>         defined in Section 2.2.3.5 of [RFC3779].
> 
> What must one do if this does include it?
> 
>         The Certificate Authority (CA) SHOULD sign only one geofeed file
>         with each generated private key and SHOULD generate a new key
>         pair for each new version of a perticular geofeed file. The CA
>         MUST generate a new End Entity (EE) certificate for each signing
>         of a particular geofeed file.
> 
> When can these SHOULDs be ignored? Eg it _is_ possible to use the same key but
> a different EE cert? Also, what is the reason for needing to generate a new EE
> cert per geofeed version file? What issue is solved by not allowing a long lived
> EE cert to do this job?
> 
>         When using data from a geofeed file, one MUST ignore data outside
>         the referring inetnum: object's inetnum: attribute address range.
> 
> How does this "MUST ignore" combine with the above mentioned "failed
> validation" ? eg here it would seem an entry to 0.0.0.0/0 must be ignored, but
> earlier text said to invalidate the entire file, not just the entry. So how
> would we ever get here?
> 
>         If and only if the geofeed file is not signed per Section 5,
>         then multiple inetnum: objects MAY refer to the same geofeed
>         file, and the consumer MUST use only lines in the geofeed file
>         where the prefix is covered by the address range of the inetnum:
>         object's URL it has followed.
> 
> We normally call this a downgrade attack. Strip the signature and modify the
> file? Are there any counter measures that can be used to prevent this attack?
> 
>         Importing datasets produced and/or processed by a third-party
>          places ill-advised trust in the third-party.
> 
> I don't think you can call all third-parties "ill-advised" by definition.
> eg is "google DNS" and ill-advised third-party for DNS ?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>         Since geofeed_1 contains geolocation data about 192.0.2.0/29,
>         it is discarded because 192.0.2.0/24 is within the more specific
>         inetnum: covering the address range and that inetnum: has a
>         geofeed reference.
> 
> This reads a bit odd, a 192.0.2.0/29 comes out of nowhere. I guess you meant
> to say "a client looking for geofeed data for 192.0.2.0/29" ?
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg