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

[Russ Housley <[e-mail]>]

Paul:

I am writing to address #3 and #4.

Thanks for your careful review.

> #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?

As the text says, we want canonical form to be the input to the signing process.  This is unchanged from RFC 9092, which has not caused the interoperability concerns that you suggest.  Also, this is the same approach that was used for digitally signing Internet-Drafts.


> #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 ?

I agree with the response that Job already offered.  In short, RPKI certificates are issued to match the privileges required for the object that will verified with the public key.  In this way, least privilege is always accomplished.

Since Section 5 is option, authentication is optional.  Thus, the Operational Considerations do include some discussion of unsigned geofeed files.

Suggested edits:

   The address range of the signing certificate MUST cover all prefixes
   in the signed geofeed file.  If not, the authenticator is invalid.

   The signing certificate MUST NOT include the Autonomous System
   Identifier Delegation certificate extension [RFC3779]. If it is
   present, the authenticator is invalid.

   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].  If "inherit" is used, the
   authenticator is invalid.

   The consumer of geofeed data SHOULD fetch and process the data
   themselves.  Importing datasets produced and/or processed by a third-
   party places significant trust in the third-party.

I think is is probably better to drop the following from Section 6:

   When using data from a geofeed file, one MUST ignore data outside the
   referring inetnum: object's inetnum: attribute address range.

Russ