Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Thu, May 20, 2021 at 09:13:52AM -0700, Randy Bush wrote:
> Russ wrote:
> > Responding to Part 1 of your DISCUSS and a few of your comments.  My
> > co-authors will address the other parts, including the NITS.
> 
> turning attention to this now.  i was in the RIPE meetings getting this
> through their sausage machine.

mmm, sausage, tasty.

> > OLD:
> > 
> >1.  Obtain the signer's certificate from an RPKI Repository.  The
> >certificate SubjectKeyIdentifier extension [RFC5280] MUST match
> >the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
> >[RFC5286].  If the key identifiers do not match, then validation
> >MUST fail.
> > 
> > NEW:
> > 
> >1.  Obtain the signer's certificate from the CMS SignedData 
> > CertificateSet
> > [RFC5652].  The certificate SubjectKeyIdentifier extension [RFC5280]
> >MUST match the SubjectKeyIdentifier in the CMS SignerInfo 
> > SignerIdentifier
> >[RFC5652].  If the key identifiers do not match, then validation
> >MUST fail.
> 
> done

+1

> > [snip]
> > 
> >> 
> >> Section 3
> >> 
> >>   The URL's use of the web PKI can not provide authentication of IP
> >>   address space ownership.  It is only used to authenticate a pointer
> >>   to the geofeed file, [...]
> >> 
> >> I'm a little confused by the use of the phrase "authenticate a pointer
> >> to the geofeed file".  My understanding is that the "pointer to the
> >> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
> >> stanza to the geofeed file, and that dereferencing the URL retrieves the
> >> geofeed file itself (i.e., not a pointer).  In particular, the URL (and
> >> any Web PKI usage therein) does not do anything to authenticate the RPLS
> >> stanza in which the URL appears.  IIUC, it would be okay to just drop
> >> that bit and say "It is only used to authenticate the domain name in the
> >> URL, and provide confidentiality and integrity for the geofeed file in
> >> transit".  Am I missing something?
> > 
> > I think it would be more accurate to say that the WebPKI provides
> > authentication and integrity of the geofeed file that is fetched.  However,
> > as I said in response to Roman's ballot comments, the ultimate integrity
> > check is the signature that is validated with the RPKI certificate.
> 
> the current text is close to this.  please indicate any tweaks that
> would improve it
> 
>The URL's use of the web PKI can not provide authentication of IP
>address space ownership.  It is only used to authenticate a pointer
>to the geofeed file, authenticate the domain name in the URL, and
>provide confidentiality and integrity for the geofeed file in
>transit.  In contrast, the Resource Public Key Infrastructure (RPKI,
>see [RFC6481]) can be used to authenticate IP space ownership; see
>optional authentication in Section 4.
[handled in other thread]
> > OLD:
> > 
> >One needs a format that bundles the relevant RPKI
> >certificate with the signature and the digest of the geofeed text.
> > 
> > NEW:
> > 
> >One needs a format that bundles the relevant RPKI
> >certificate with the signature of the geofeed text.
> 
> easy

+1

> > OLD:
> > 
> >Borrowing detached signatures from [RFC5485], after file
> >canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
> >would be used to create a detached DER encoded signature which is
> >then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
> >or fewer characters.
> > 
> > NEW:
> > 
> >Borrowing detached signatures from [RFC5485], after file
> >canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
> >would be used to create a detached DER encoded signature which is
> >then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
> >or fewer characters.  The same digest algorithm MUST be used for
> >calculating the message digest on content being signed, which is the
> >geofeed file, and calculating the message digest on the SignerInfo 
> >SignedAttributes [RFC8933].  The message digest algorithm identifier
> >MUST appear in both the SigenedData DigestAlgorithmIdentifiers and
> >the SignerInfo DigestAlgorithmIdentifier [RFC5652].
> 
> ok

+1
and thanks again to Russ for getting 8933 done

> >>   text.  Trailing space characters MUST NOT appear on a line of text.
> >>   That is, the space or tab characters must not be followed by the
> >>sequence.  [...]
> >> 
> >> Is the restriction on Unicode characters of category "space separator"
> >> ("space characters") or the two listed characters?  (Why just those two,
> >> and not form feed as well?)
> > 
> > Looking at the ABNF in RFC 8805, It does not look like there should be
> > any trailing whitespace, this was more for consistency with RFC 5485.
> 
> perhaps a clearer phrasing would be
> 
> Trailing space characters MUST NOT appear on a line of text.  That
> is, space 

Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

I'll try to respond to the thread in reverse order to avoid duplication...

On Thu, May 20, 2021 at 03:11:51PM -0700, Randy Bush wrote:
> ok, let me try to cover what russ has not.  good reviews are much
> appreciated
> 
>   [ in the cs academic social circle, there has been comment that,
> though reviews can be a pita, they are substantial revwiews.  one
> gets useful feedback.  in man other fields, one gets one or two
> sentences saying useless and even rude things.  the ietf review
> cycle, once one gets to last call (yes, that is a problem), is even
> more thorough and constructive. ]
> 
> > We are careful to note that:
> > 
> >The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
> >present exactly as shown.
> > 
> > How do we construct the bits (CIDR block?) that come after the quoted
> > strings?  Do they only matter for matching start/end, or are we supposed
> > to check them in the validation procedure?
> 
> how about
> 
>The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
>present following the model as shown.  The IP address range MUST
>match that of the signer's certificate.
> 
> and the cert is already in the validation

That removes the ambiguity I was worried about.  It seems like it should
work.

> > Thanks to Kyle Rose for the secdir review, and all who participated in
> > the subsequent discussion.
> 
> indeed
> 
> > Publishing this document on the stanards-track does make one wonder
> > whether RFC 8805 should be adopted at least into the IETF stream and
> > possibly to the standards-track as well...
> 
> and it could use a bit of work in the process.  can you say "let's open
> a can of worms?"  but yes, geofeed has seriously 8805 deployment, and it
> is showing cracks.

The analogies to DMARC do kind of write themselves...

> > Section 1
> > 
> >This document specifies how to augment the Routing Policy
> >Specification Language (RPSL) [RFC2622] inetnum: class to refer
> > 
> > Interestingly, I don't see "inetnum" at all in RFC 2622 (but the
> > treatment in RFC 2725 is helpful to some extent).  Should we be
> > referencing 2725 (or something else) in addition to 2622?
> 
> grumph!  i though i had fixed this.  clearly i had not.
> 
> > Section 3
> > 
> >The URL's use of the web PKI can not provide authentication of IP
> >address space ownership.  It is only used to authenticate a pointer
> >to the geofeed file, [...]
> > 
> > I'm a little confused by the use of the phrase "authenticate a pointer
> > to the geofeed file".  My understanding is that the "pointer to the
> > geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
> > stanza to the geofeed file, and that dereferencing the URL retrieves the
> > geofeed file itself (i.e., not a pointer).  In particular, the URL (and
> > any Web PKI usage therein) does not do anything to authenticate the RPLS
> > stanza in which the URL appears.  IIUC, it would be okay to just drop
> > that bit and say "It is only used to authenticate the domain name in the
> > URL, and provide confidentiality and integrity for the geofeed file in
> > transit".  Am I missing something?
> 
> no.  my current edit buffer has
> 
>The URL uses HTTPS, so the WebPKI provides authentication, integrity,
>and confidentiality for the fetched geofeed file.  However, the
>WebPKI can not provide authentication of IP address space assignment.
>In contrast, the Resource Public Key Infrastructure (RPKI, see
>[RFC6481]) can be used to authenticate IP space assignment; see
>optional authentication in Section 4.

Excellent, thanks.

> >If a geofeed CSV file describes multiple disjoint ranges of IP
> >address space, there are likely to be geofeed references from
> >multiple inetnum: objects.
> > 
> > We might note that such files with geofeed references from multiple
> > inetnum: objects are not compatible with our signing procedure (right?)
> > and thus vaguely discouraged.
> 
> i am not sure i would discourage the use, as i suspect the rpki
> authentication will mostly remain unused.
> 
>If a geofeed CSV file describes multiple disjoint ranges of IP
>address space, there are likely to be geofeed references from
>multiple inetnum: objects.  Files with geofeed references from
>multiple inetnum: objects are not compatible with the signing
>procedure in Section 4.

ok.
(We do have plenty of examples of shiny cryptographic schemes that remain
mostly unused, but I will refrain from naming names...)

> > Maybe I'm just confused about what "covered by he range of the inetnum:"
> > means, but I only see (at least so far) requirements that the signing
> > cert cover all addresses in the file, and that we fetch from the
> > most-specific inetnum: object with a geofeed reference.  Can't I still
> > sign with a cert that covers a broader range of addresses than the
> > intenum: object used to fetch?
> 
> i am trying to think of two examples 

[OPSAWG] I-D Action: draft-ietf-opsawg-finding-geofeeds-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Finding and Using Geofeed Data
Authors : Randy Bush
  Massimo Candela
  Warren Kumari
  Russ Housley
Filename: draft-ietf-opsawg-finding-geofeeds-13.txt
Pages   : 23
Date: 2021-05-20

Abstract:
   This document specifies how to augment the Routing Policy
   Specification Language inetnum: class to refer specifically to
   geofeed data CSV files, and describes an optional scheme to use the
   Routing Public Key Infrastructure to authenticate the geofeed data
   CSV files.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-finding-geofeeds-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-finding-geofeeds-13


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Randy Bush]

ok, let me try to cover what russ has not.  good reviews are much
appreciated

  [ in the cs academic social circle, there has been comment that,
though reviews can be a pita, they are substantial revwiews.  one
gets useful feedback.  in man other fields, one gets one or two
sentences saying useless and even rude things.  the ietf review
cycle, once one gets to last call (yes, that is a problem), is even
more thorough and constructive. ]

> We are careful to note that:
> 
>The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
>present exactly as shown.
> 
> How do we construct the bits (CIDR block?) that come after the quoted
> strings?  Do they only matter for matching start/end, or are we supposed
> to check them in the validation procedure?

how about

   The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
   present following the model as shown.  The IP address range MUST
   match that of the signer's certificate.

and the cert is already in the validation

> Thanks to Kyle Rose for the secdir review, and all who participated in
> the subsequent discussion.

indeed

> Publishing this document on the stanards-track does make one wonder
> whether RFC 8805 should be adopted at least into the IETF stream and
> possibly to the standards-track as well...

and it could use a bit of work in the process.  can you say "let's open
a can of worms?"  but yes, geofeed has seriously 8805 deployment, and it
is showing cracks.

> Section 1
> 
>This document specifies how to augment the Routing Policy
>Specification Language (RPSL) [RFC2622] inetnum: class to refer
> 
> Interestingly, I don't see "inetnum" at all in RFC 2622 (but the
> treatment in RFC 2725 is helpful to some extent).  Should we be
> referencing 2725 (or something else) in addition to 2622?

grumph!  i though i had fixed this.  clearly i had not.

> Section 3
> 
>The URL's use of the web PKI can not provide authentication of IP
>address space ownership.  It is only used to authenticate a pointer
>to the geofeed file, [...]
> 
> I'm a little confused by the use of the phrase "authenticate a pointer
> to the geofeed file".  My understanding is that the "pointer to the
> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
> stanza to the geofeed file, and that dereferencing the URL retrieves the
> geofeed file itself (i.e., not a pointer).  In particular, the URL (and
> any Web PKI usage therein) does not do anything to authenticate the RPLS
> stanza in which the URL appears.  IIUC, it would be okay to just drop
> that bit and say "It is only used to authenticate the domain name in the
> URL, and provide confidentiality and integrity for the geofeed file in
> transit".  Am I missing something?

no.  my current edit buffer has

   The URL uses HTTPS, so the WebPKI provides authentication, integrity,
   and confidentiality for the fetched geofeed file.  However, the
   WebPKI can not provide authentication of IP address space assignment.
   In contrast, the Resource Public Key Infrastructure (RPKI, see
   [RFC6481]) can be used to authenticate IP space assignment; see
   optional authentication in Section 4.

>If a geofeed CSV file describes multiple disjoint ranges of IP
>address space, there are likely to be geofeed references from
>multiple inetnum: objects.
> 
> We might note that such files with geofeed references from multiple
> inetnum: objects are not compatible with our signing procedure (right?)
> and thus vaguely discouraged.

i am not sure i would discourage the use, as i suspect the rpki
authentication will mostly remain unused.

   If a geofeed CSV file describes multiple disjoint ranges of IP
   address space, there are likely to be geofeed references from
   multiple inetnum: objects.  Files with geofeed references from
   multiple inetnum: objects are not compatible with the signing
   procedure in Section 4.

> Maybe I'm just confused about what "covered by he range of the inetnum:"
> means, but I only see (at least so far) requirements that the signing
> cert cover all addresses in the file, and that we fetch from the
> most-specific inetnum: object with a geofeed reference.  Can't I still
> sign with a cert that covers a broader range of addresses than the
> intenum: object used to fetch?

i am trying to think of two examples [ yes, certs and inetnum:s may
express ranges as well as cidr blocks ]

two inetnums:
   1.2.3.0 - 1.2.3.7 
   1.2.3.6 - 1.2.3.13
and a cert for 1.2.3.0 - 1.2.3.13

and conversely

two certs:
   1.2.3.0 - 1.2.3.7 
   1.2.3.6 - 1.2.3.13
and an inetnum: for 1.2.3.0 - 1.2.3.13

and i m starting to think i am rat-holing on complexlow-payoff corner
cases, a disease i rather dislike.

the current state is simple and clear.  are there seriously useful cases
it does not cover?  i will keep thinking.  and listening, of course.

>Identifying the private key associated with the certificate, and
>getting the department 

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[Benjamin Kaduk]

On Thu, May 20, 2021 at 01:36:52PM -0700, Randy Bush wrote:
> >> ever see the cat herding video?
> > https://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$
> > 
> > Does not render. Oh well, I’ve seen cat videos before, I’ll use my
> > imagination.
> 
> i suspect your corporate nannyware put some strange rubbish after the
> ".mov"
> 
> but you can also try https://archive.psg.com/catherding.mpg
> 
> >>> 3. Section 3:
> >>> 
> >>>   Any particular inetnum: object MUST have at most, one geofeed
> >>>   reference, whether a remarks: or a proper geofeed: attribute when it
> >>>   is implemented.  If there is more than one, all are ignored.
> >>> 
> >>> This makes me think the geofeed: attribute will never, ever be
> >>> adopted, because you’ve just created a flag day requirement.
> >> 
> >> no.  this is per inetnum: object, not per registry.  see beginning of
> >> para.  perhaps i should add an example of an inetnum: object.
> > 
> > I know what an inetnum: is (although it’s a fair point that maybe not
> > everybody does). In thinking about it a little more, yes “flag day”
> > was too strong, however I think there’s still potentially a problem,
> > depending on what entity has the issues.
> > 
> > If it’s only the RIR (“server”) side that lags, then presumably
> > clients will be built to consume both geofeed: and inetnum: from day
> > one. In that case cutover is easy: once the RIR implements geofeed:,
> > you cut over to it in all the inetnum:s that RIR serves, done.
> 
> it's even simpler.  the whois server would support both flavors of
> attribute in an inetnum:, remarks: and geofeed:.  (note that it MUST
> support the remark: form.)  it is the individual inetnum: objects
> registered by ISPs that cut over one by one at their leisure.  an isp
> with 42 inetnum: objects could cut them over one at a time on wednesday
> afternoons.

I was going to comment something similar to John until I noticed this
snippet:

   Until all producers of inetnum:s, i.e. the RIRs, state that they have
   migrated to supporting a geofeed: attribute, consumers looking at
   inetnum:s to find geofeed URLs MUST be able to consume both the
   remarks: and geofeed: forms.  [...]

So, AFAICT, we already do require that all clients will be able to consume
both forms, and the complications that John is worried about "just go away".

> > On the other hand, if there are clients (now, or ever) that implement
> > only inetnum:, then I do think we’re in for an eternity of supporting
> > both.
> 
> i think you mean if there are clients that do not support the geofeed:
> attribute form in inetnum:s.  yup, then they are not going to get the
> urls from inetnum:s which have moved to the new form.  such is forward
> migration.
> 
> >>> 4. Section 5:
> >>> 
> >>>   If and only if the geofeed file is not signed per Section 4, then
> >>>   multiple inetnum: objects MAY refer to the same geofeed file, and the
> >>>   consumer MUST use only geofeed lines where the prefix is covered by
> >>>   the address range of the inetnum: object they have followed.
> >>> 
> >>> Presumably this only works with unsigned geofeeds because you’re
> >>> implicitly requiring that the geofeed file be signed only once. Is
> >>> there any particular driver for this sign-only-once requirement? On a
> >>> cursory review of §4, I don’t see anything that would make multiple
> >>> signatures impracticable.
> >> 
> >> the geofeed lines would then need to be sorted, clumped, ...  seems a
> >> bit complex for not much win.  due to the administrative structure and
> >> process, inetnum: objects tend to the same granularity as RPKI objects.
> >> so having the geofeed files follow seems natural.
> > 
> > OK. My fear was that there might already be substantial investment in
> > geofeed:s that cover multiple objects, and resistance to shredding
> > them down to individual object-level feeds. But maybe there isn’t and
> > won’t be.
> 
> in parallel, i am thinking of the implications of a question in this
> space from ben.  i think the comparitive granularity of inetnum:s and
> the corresponding rpki data is important but unknown.
> 
> my head hurts.  i want to keep thinking about this space.

Makes sense (on both counts, unfortunately).

> > I took a look and it looks good. I have one new nit, in §4, because of
> > course I do:
> > 
> >The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
> >present exactly as shown.
> > 
> > A pedant might say “exactly as shown” means verbatim "# End Signature:
> > 192.0.2.0/24”
> 
> the quote marks were insufficiently explicit?
> 
> > it may be worth being even clearer. It would be possible to write it
> > out in excruciating detail of course, but possibly replacing “exactly
> > as shown” with something like “following the model shown” might be
> > enough. (I say “ish” because I wonder if “192.0.2/24”, the way
> > right-thinking people 

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[Randy Bush]

>> ever see the cat herding video?
> https://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$
> 
> Does not render. Oh well, I’ve seen cat videos before, I’ll use my
> imagination.

i suspect your corporate nannyware put some strange rubbish after the
".mov"

but you can also try https://archive.psg.com/catherding.mpg

>>> 3. Section 3:
>>> 
>>>   Any particular inetnum: object MUST have at most, one geofeed
>>>   reference, whether a remarks: or a proper geofeed: attribute when it
>>>   is implemented.  If there is more than one, all are ignored.
>>> 
>>> This makes me think the geofeed: attribute will never, ever be
>>> adopted, because you’ve just created a flag day requirement.
>> 
>> no.  this is per inetnum: object, not per registry.  see beginning of
>> para.  perhaps i should add an example of an inetnum: object.
> 
> I know what an inetnum: is (although it’s a fair point that maybe not
> everybody does). In thinking about it a little more, yes “flag day”
> was too strong, however I think there’s still potentially a problem,
> depending on what entity has the issues.
> 
> If it’s only the RIR (“server”) side that lags, then presumably
> clients will be built to consume both geofeed: and inetnum: from day
> one. In that case cutover is easy: once the RIR implements geofeed:,
> you cut over to it in all the inetnum:s that RIR serves, done.

it's even simpler.  the whois server would support both flavors of
attribute in an inetnum:, remarks: and geofeed:.  (note that it MUST
support the remark: form.)  it is the individual inetnum: objects
registered by ISPs that cut over one by one at their leisure.  an isp
with 42 inetnum: objects could cut them over one at a time on wednesday
afternoons.

> On the other hand, if there are clients (now, or ever) that implement
> only inetnum:, then I do think we’re in for an eternity of supporting
> both.

i think you mean if there are clients that do not support the geofeed:
attribute form in inetnum:s.  yup, then they are not going to get the
urls from inetnum:s which have moved to the new form.  such is forward
migration.

>>> 4. Section 5:
>>> 
>>>   If and only if the geofeed file is not signed per Section 4, then
>>>   multiple inetnum: objects MAY refer to the same geofeed file, and the
>>>   consumer MUST use only geofeed lines where the prefix is covered by
>>>   the address range of the inetnum: object they have followed.
>>> 
>>> Presumably this only works with unsigned geofeeds because you’re
>>> implicitly requiring that the geofeed file be signed only once. Is
>>> there any particular driver for this sign-only-once requirement? On a
>>> cursory review of §4, I don’t see anything that would make multiple
>>> signatures impracticable.
>> 
>> the geofeed lines would then need to be sorted, clumped, ...  seems a
>> bit complex for not much win.  due to the administrative structure and
>> process, inetnum: objects tend to the same granularity as RPKI objects.
>> so having the geofeed files follow seems natural.
> 
> OK. My fear was that there might already be substantial investment in
> geofeed:s that cover multiple objects, and resistance to shredding
> them down to individual object-level feeds. But maybe there isn’t and
> won’t be.

in parallel, i am thinking of the implications of a question in this
space from ben.  i think the comparitive granularity of inetnum:s and
the corresponding rpki data is important but unknown.

my head hurts.  i want to keep thinking about this space.

> I took a look and it looks good. I have one new nit, in §4, because of
> course I do:
> 
>The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
>present exactly as shown.
> 
> A pedant might say “exactly as shown” means verbatim "# End Signature:
> 192.0.2.0/24”

the quote marks were insufficiently explicit?

> it may be worth being even clearer. It would be possible to write it
> out in excruciating detail of course, but possibly replacing “exactly
> as shown” with something like “following the model shown” might be
> enough. (I say “ish” because I wonder if “192.0.2/24”, the way
> right-thinking people write prefixes, would also be OK, or if it’s not
> “exactly as shown” enough.)

i'll try it.  but the previous complaint there was that the text was
insufficiently prescriptive.

> I was sad to see the tweezers left on the cutting room floor but I
> understand why.

for you, i would throw them back.  but the strength of the current
"brute force" phrasing appeals.

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Francesca Palombini's No Objection on draft-ietf-opsawg-finding-geofeeds-12: (with COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-12: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/



--
COMMENT:
--

Thanks for addressing my DISCUSS and answering my question.

Thank you for the work on this document, and thank you to the shepherd for a
very well-written and in-depth shepherd write up: it was very informative and
very appreciated.

Francesca



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[John Scudder]

Hi Randy,

Further replies below. I’ve snipped where I had nothing further to say; please 
consider me to have chuckled at your bons mots, thanked you for updates, etc.

> On May 19, 2021, at 11:00 PM, Randy Bush  wrote:

[…]

>> 1. Section 3:
>> 
>>   Ideally, RPSL would be augmented to define a new RPSL geofeed:
>>   attribute in the inetnum: class.  Until such time, this document
>> 
>> I, too, am curious as to why this ideal solution isn’t considered
>> achievable.
>> 
>> I’m also a little confused by the way you seem to be arguing with
>> yourself in this section. First you tell me that change control for
>> RPSL is vested in the operator community (by implication, not the
>> IETF). A few paragraphs later you say:
>> 
>>   While we leave global agreement of RPSL modification to the
>>   relevant parties, we specify that a proper geofeed: attribute in
>>   the inetnum: class MUST be "geofeed: ", and MUST be followed by a
>>   single URL which
>> 
>> Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine
>> with what you’ve specced, but when you fence it off with disclaimers
>> that say RPSL modification isn’t up to you, it leaves me confused.
>> 
>> Perhaps your point is that the IETF gets to specify the geofeed:
>> attribute, but only the RIRs get to decide when they will start using
>> it?
> 
> really, if the ripe community adopts it.  and progress is good there.
> 
> ever see the cat herding video?  
> https://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$

Does not render. Oh well, I’ve seen cat videos before, I’ll use my imagination.

If your point is “the process is convoluted, so the description of it is too” 
then… ok. I won’t further belabor the point.

[…]

>> 3. Section 3:
>> 
>>   Any particular inetnum: object MUST have at most, one geofeed
>>   reference, whether a remarks: or a proper geofeed: attribute when it
>>   is implemented.  If there is more than one, all are ignored.
>> 
>> This makes me think the geofeed: attribute will never, ever be
>> adopted, because you’ve just created a flag day requirement.
> 
> no.  this is per inetnum: object, not per registry.  see beginning of
> para.  perhaps i should add an example of an inetnum: object.

I know what an inetnum: is (although it’s a fair point that maybe not everybody 
does). In thinking about it a little more, yes “flag day” was too strong, 
however I think there’s still potentially a problem, depending on what entity 
has the issues.

If it’s only the RIR (“server”) side that lags, then presumably clients will be 
built to consume both geofeed: and inetnum: from day one. In that case cutover 
is easy: once the RIR implements geofeed:, you cut over to it in all the 
inetnum:s that RIR serves, done. On the other hand, if there are clients (now, 
or ever) that implement only inetnum:, then I do think we’re in for an eternity 
of supporting both.

[…]

>> Why not permit both the remarks: and geofeed: versions to enable
>> transition?
> 
> because then, as you point out, it is three paragraphs if they disagree.

As long as my supposition above is the expected case, I agree that keeping it 
simple is fine. If it’s not the expected case, then three paragraphs seems a 
small price to pay.

>> 4. Section 5:
>> 
>>   If and only if the geofeed file is not signed per Section 4, then
>>   multiple inetnum: objects MAY refer to the same geofeed file, and the
>>   consumer MUST use only geofeed lines where the prefix is covered by
>>   the address range of the inetnum: object they have followed.
>> 
>> Presumably this only works with unsigned geofeeds because you’re
>> implicitly requiring that the geofeed file be signed only once. Is
>> there any particular driver for this sign-only-once requirement? On a
>> cursory review of §4, I don’t see anything that would make multiple
>> signatures impracticable.
> 
> the grofeed lines would then need to be sorted, clumped, ...  seems a
> bit complex for not much win.  due to the administrative structure and
> process, inetnum: objects tend to the same granularity as RPKI objects.
> so having the geofeed files follow seems natural.

OK. My fear was that there might already be substantial investment in geofeed:s 
that cover multiple objects, and resistance to shredding them down to 
individual object-level feeds. But maybe there isn’t and won’t be.

> i figure that, if signing actually is used, and folk whine, we can beg
> russ to do a bis.

One counterargument to my scenario above, is that tooling up to sign the 
geofeed:s is probably a bigger effort than subdividing them in order to permit 
the signatures.

[…]

>> At the very least, if there is a requirement that only a single signature be
>> present in a geofeed file, can you say that explicitly in §4?
> 
> sure.

Thanks.

> i am about to push -11.  check diff if you have the time.  right now i
> am panicked that i can not find that i sent 

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-finding-geofeeds-12: (with COMMENT)

[Russ Housley]

Roman:

Responding to just one comment.

> ** Appendix A.  The end-user certificate has a sbgp-ipAddBlock field which is
> “IPv4: inherit IPv6: inherit”.  However, the parent CA is encoding an IPv4 
> only
> range so it seems misplaced that there is a IPv6 reference there.
> 
> See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/
> for follow-up discussion on this.

I will be glad to make this change to the example.  It took some time to make 
the changes and edit the file.

I just sent it to Randy for incorporation into the next version of the I-D.

Russ


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Randy Bush]

> Responding to Part 1 of your DISCUSS and a few of your comments.  My
> co-authors will address the other parts, including the NITS.

turning attention to this now.  i was in the RIPE meetings getting this
through their sausage machine.

> OLD:
> 
>1.  Obtain the signer's certificate from an RPKI Repository.  The
>certificate SubjectKeyIdentifier extension [RFC5280] MUST match
>the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
>[RFC5286].  If the key identifiers do not match, then validation
>MUST fail.
> 
> NEW:
> 
>1.  Obtain the signer's certificate from the CMS SignedData CertificateSet
> [RFC5652].  The certificate SubjectKeyIdentifier extension [RFC5280]
>MUST match the SubjectKeyIdentifier in the CMS SignerInfo 
> SignerIdentifier
>[RFC5652].  If the key identifiers do not match, then validation
>MUST fail.

done

> [snip]
> 
>> 
>> Section 3
>> 
>>   The URL's use of the web PKI can not provide authentication of IP
>>   address space ownership.  It is only used to authenticate a pointer
>>   to the geofeed file, [...]
>> 
>> I'm a little confused by the use of the phrase "authenticate a pointer
>> to the geofeed file".  My understanding is that the "pointer to the
>> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
>> stanza to the geofeed file, and that dereferencing the URL retrieves the
>> geofeed file itself (i.e., not a pointer).  In particular, the URL (and
>> any Web PKI usage therein) does not do anything to authenticate the RPLS
>> stanza in which the URL appears.  IIUC, it would be okay to just drop
>> that bit and say "It is only used to authenticate the domain name in the
>> URL, and provide confidentiality and integrity for the geofeed file in
>> transit".  Am I missing something?
> 
> I think it would be more accurate to say that the WebPKI provides
> authentication and integrity of the geofeed file that is fetched.  However,
> as I said in response to Roman's ballot comments, the ultimate integrity
> check is the signature that is validated with the RPKI certificate.

the current text is close to this.  please indicate any tweaks that
would improve it

   The URL's use of the web PKI can not provide authentication of IP
   address space ownership.  It is only used to authenticate a pointer
   to the geofeed file, authenticate the domain name in the URL, and
   provide confidentiality and integrity for the geofeed file in
   transit.  In contrast, the Resource Public Key Infrastructure (RPKI,
   see [RFC6481]) can be used to authenticate IP space ownership; see
   optional authentication in Section 4.

> OLD:
> 
>One needs a format that bundles the relevant RPKI
>certificate with the signature and the digest of the geofeed text.
> 
> NEW:
> 
>One needs a format that bundles the relevant RPKI
>certificate with the signature of the geofeed text.

easy

> OLD:
> 
>Borrowing detached signatures from [RFC5485], after file
>canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
>would be used to create a detached DER encoded signature which is
>then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
>or fewer characters.
> 
> NEW:
> 
>Borrowing detached signatures from [RFC5485], after file
>canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
>would be used to create a detached DER encoded signature which is
>then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
>or fewer characters.  The same digest algorithm MUST be used for
>calculating the message digest on content being signed, which is the
>geofeed file, and calculating the message digest on the SignerInfo 
>SignedAttributes [RFC8933].  The message digest algorithm identifier
>MUST appear in both the SigenedData DigestAlgorithmIdentifiers and
>the SignerInfo DigestAlgorithmIdentifier [RFC5652].

ok

>>   text.  Trailing space characters MUST NOT appear on a line of text.
>>   That is, the space or tab characters must not be followed by the
>>sequence.  [...]
>> 
>> Is the restriction on Unicode characters of category "space separator"
>> ("space characters") or the two listed characters?  (Why just those two,
>> and not form feed as well?)
> 
> Looking at the ABNF in RFC 8805, It does not look like there should be
> any trailing whitespace, this was more for consistency with RFC 5485.

perhaps a clearer phrasing would be

Trailing space characters MUST NOT appear on a line of text.  That
is, space or tab characters must not immediately preceed a 
sequence.

> OLD:
> 
>4.  Verify that the IP Address Delegation certificate extension
>[RFC3779] covers the address range of the geofeed file.  If the
>address range is not covered, then validation MUST fail.
> 
> NEW:
> 
>4.  Verify that the IP Address Delegation certificate extension
>[RFC3779] covers all of 

Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Russ Housley]

Ben:

Responding to Part 1 of your DISCUSS and a few of your comments.  My co-authors 
will address the other parts, including the NITS.

> --
> DISCUSS:
> --
> 
> Roman and Russ did the heavy lifting already, but I think I have a bit more
> fiddling to do regarding the validation procedures (just getting them
> internally consistent, I think)...
> 
> (1)
> Here:
> 
>   As the signer specifies the covered RPKI resources relevant to the
>   signature, the RPKI certificate covering the inetnum: object's
>   address range is included in the [RFC5652] CMS SignedData
>   certificates field.
> 
> we say that the signing certificate is included in the SignedData
> certificates field.  That makes sense, as SignedData is a SEQUENCE
> including "certificates [0] IMPLICIT CertificateSet OPTIONAL", and
> CertificateSet, as a SET OF CertificateChoices, allows for the literal
> "Certificate" branch of CertificateChoices.
> 
> But later on, we say that:
> 
>   1.  Obtain the signer's certificate from an RPKI Repository.  The
>   certificate SubjectKeyIdentifier extension [RFC5280] MUST match
>   the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
>   [RFC5286].  If the key identifiers do not match, then validation
>   MUST fail.
> 
> which entails fetching the certificate from a directory, based on the
> SubjectKeyIdentifier.
> 
> Why do we need to obtain the certificate twice in two different ways?

Thanks for catching this error that I introduced yesterday.  Here is a 
correction.

OLD:

   1.  Obtain the signer's certificate from an RPKI Repository.  The
   certificate SubjectKeyIdentifier extension [RFC5280] MUST match
   the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
   [RFC5286].  If the key identifiers do not match, then validation
   MUST fail.

NEW:

   1.  Obtain the signer's certificate from the CMS SignedData CertificateSet
[RFC5652].  The certificate SubjectKeyIdentifier extension [RFC5280]
   MUST match the SubjectKeyIdentifier in the CMS SignerInfo 
SignerIdentifier
   [RFC5652].  If the key identifiers do not match, then validation
   MUST fail.

[snip]

> --
> COMMENT:
> --

[snip]

> 
> Section 3
> 
>   The URL's use of the web PKI can not provide authentication of IP
>   address space ownership.  It is only used to authenticate a pointer
>   to the geofeed file, [...]
> 
> I'm a little confused by the use of the phrase "authenticate a pointer
> to the geofeed file".  My understanding is that the "pointer to the
> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
> stanza to the geofeed file, and that dereferencing the URL retrieves the
> geofeed file itself (i.e., not a pointer).  In particular, the URL (and
> any Web PKI usage therein) does not do anything to authenticate the RPLS
> stanza in which the URL appears.  IIUC, it would be okay to just drop
> that bit and say "It is only used to authenticate the domain name in the
> URL, and provide confidentiality and integrity for the geofeed file in
> transit".  Am I missing something?

I think it would be more accurate to say that the WebPKI provides
authentication and integrity of the geofeed file that is fetched.  However,
as I said in response to Roman's ballot comments, the ultimate integrity
check is the signature that is validated with the RPKI certificate.

[snip]

> Section 4
> 
>   address range.  One needs a format that bundles the relevant RPKI
>   certificate with the signature and the digest of the geofeed text.
> 
> If the signature is distributed alongside the file being signed, why is
> it necessary to bundle the digest of the file being signed with the
> signature?  This just invites security-relevant implementation bugs
> where the validator just accepts the precomputed digest and does not
> validate that the contents of the geofeed file actually have that
> digest.

This comes from the fact that CMS does carry the message digest in a
signed attribute, but this is probably too much detail at this point in the
discussion.

OLD:

   One needs a format that bundles the relevant RPKI
   certificate with the signature and the digest of the geofeed text.

NEW:

   One needs a format that bundles the relevant RPKI
   certificate with the signature of the geofeed text.

> (There is, however, value in the CMS SignedData including the digest
> *algorithms* used in signatures.  I don't know if that was the intent
> here.)

Yes, CMS carries the digest algorithm identifier.  We can be more explicit.

OLD:

   Borrowing detached signatures from [RFC5485], after file
   canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
   would be used to create a detached DER encoded 

Re: [OPSAWG] Murray Kucherawy's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Murray S. Kucherawy]

On Thu, May 20, 2021 at 5:34 AM Randy Bush  wrote:

> > I may have missed something, but why does Section 5 advocate for use
> > of HTTPS to fetch geofeed files in the second paragraph, and then FTP
> > in the seventh?
>
> the former is for getting one file through direct reference.  the latter
> is bulk transfer of the totality of the repository's data through bulk
> query.
>

Ah, thanks, I did miss that subtlety.  I suggest something like this to
spell it out for people like me:

OLD:

   To minimize the load on RIR whois [RFC3912
] services, use of the
   RIR's FTP [RFC0959 ]
services SHOULD be the preferred access.  This
   also provides bulk access instead of fetching by brute force search
   through the IP space.

NEW:

   To minimize the load on RIR whois [RFC3912
] services, use of the
   RIR's FTP [RFC0959 ]
services SHOULD be the preferred access for
   retrieval of the entire repository.  This provides bulk access
   instead of fetching by brute force search through the IP space.

-MSK
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-finding-geofeeds-12: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-12: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/



--
COMMENT:
--

(Updated ballot)
Thank you to Kyle Rose for the SECDIR review.

Thank you for addressing my DISCUSS and various COMMENTs.

==
** Section  4. Per “the RPKI certificate covering the inetnum: object's address
range is included in the [RFC5652] CMS SignedData certificates field”, can a
more specific statement be made highlight which certificate field in providing
the IP information.  Propose:

OLD
... the RPKI certificate covering the inetnum: object's address range is
included in the [RFC5652] CMS SignedData certificates field

NEW
... the RPKI certificate covering the inetnum: object's address range is
included in the IP Address Delegation certificate extension [RFC3779] field.

See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/
for follow-up discussion on this.

** Section 4.  Per the format of the signature appended to the geofeed file:
   # RPKI Signature: 192.0.2.0/24
   # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
   # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
   ...
   # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
   # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
   # End Signature: 192.0.2.0/24

-- The does the label “192.0.2.0/24” relate to the rest of the geofeed file and
the inetnum: value?

** Appendix A.  The end-user certificate has a sbgp-ipAddBlock field which is
“IPv4: inherit IPv6: inherit”.  However, the parent CA is encoding an IPv4 only
range so it seems misplaced that there is a IPv6 reference there.

See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/
for follow-up discussion on this.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)

[John Scudder]

One quick reply, more pending —

To be clear, that was me thanking George for a job well done. I didn’t intend 
to imply the authors hadn’t provided credit where due, I did see that you had, 
and thanks for that. 

—John

> On May 19, 2021, at 11:01 PM, Randy Bush  wrote:
> 
>> 0. I’d like to thank George Michaelson for a thorough and helpful, not
>> to say exemplary, shepherd’s report.
> 
> it's odd.  the acks have thanked ggm twice, once for shepherding, and
> folk seem to miss it.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Murray Kucherawy's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Randy Bush]

> I may have missed something, but why does Section 5 advocate for use
> of HTTPS to fetch geofeed files in the second paragraph, and then FTP
> in the seventh?

the former is for getting one file through direct reference.  the latter
is bulk transfer of the totality of the repository's data through bulk
query.

> In Section 5, "https" should be "HTTPS" since you're describing a
> protocol and not a URI scheme (or if you meant to do the latter,
> please say so).

sure

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg