Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

[Brian Haberman <[e-mail]>]

Hi Terry,

On 5/17/16 11:37 PM, Terry Manderson wrote:
> Terry Manderson has entered the following ballot position for
> draft-ietf-sidr-rpsl-sig-11: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thank you for putting substantial effort into this document.
> 
> I have a few discusses. I hope they can be resolved quickly.
> 
> In Section 2.1. The reference to the aligned certificate  which has the
> same private key that signed the RPSL object is mandatory, and defined by
> a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The
> architecture of RPKI (IIRC) is centered around RSYNC, and thus SIA/AIA
> values MUST have a RSYNC URL, and MAY have other types. By this are you
> leaving it to the issuing party to control the RPKI Distribution
> mechanisms of the Replying Party? I am quite comfortable with "or"
> personally, however this facet of fetching the RPSL Certificate to
> validate the private key usage is seemingly orthogonal to the RPKI
> architecture of RSYNC preferred and should be called out if 'or' is the
> clear intention. Or, has the consensus of the WG moved on from being
> wedded to RSYNC?

I am not aware of the WG moving away from their rsync leanings...

> 
> If it is truely "or", my observation is that the use of the RPKI
> repository is one of  convenience, and that should be called out, in fact
> it does appear that any valid certificate bearing RFC3779 extensions
> could be used to validate the digital signature associated with the RPSL
> object provided the relying party has trust anchor material that leads to
> the corresponding EE certificate and therefore private key. Is this
> observation correct?

You are correct that the use of the RPKI repository is one of
convenience. My original implementation of this approach used non-RPKI
certificates. I would be fine with putting a statement in the
Introduction along the lines of:

"While the approach outlined in this document mandates the use of the
RPKI for certificate distribution, it is not dependent upon the RPKI for
correct functionality. Equivalent functionality can be achieved with a
more traditional certificate authority, RFC 3779 extensions within the
certificates, and the appropriate trust anchor material to verify the
digital signature."

> 
> The Signature expiration time field ("x") currently has no time
> constraints, and I'm very surprised that it is optional with the text in
> s2.5, given that the expiration time, by my reading, could not be beyond
> the 'not after' time of the corresponding certificate. Can you please
> instruct me as to what the consensus position on this was? A criticism of
> many IRRs is that data becomes stale. have the signature expiration time
> field could aide in data freshness models and reduce load on automated
> import and validation of these RPSL signatures.

The validity of the signature is driven by the notAfter field of the
certificate described in 6487. My implementation does the validation
based on notAfter regardless of what is included in the "x" field. I
view "x" as a simple way for RPSL object signers to indicate the
lifetime, but not the authoritative way.

> 
> And lastly, IRRs tend to run over the (legacy?) whois port 43 that
> doesn't provide channel layer security. This means that while signature
> provide a means of detecting modification it may not stop a a MiTM event
> where the entire object is omitted. Do you agree? if so that might be
> appropriate for the Security Considerations section.
> 

I agree with the potential MiTM attack described, but view that as
orthogonal to digital signatures providing integrity protection. This
type of attack could easily occur regardless of whether objects are
signed or not.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> one nit:
> 
> "MUST reject the signature and threat the object as a regular" I think
> you mean `s/threat/treat`

Fixed in my pending edit buffer.

> 
> Misc comments:
> 
> * Thank you for the very clear canonicalisation requirements!
> 
> * For route6 objects, where two resource holder's signatures considered
> such that it might address the inability to properly sign the RPSL when
> one holder possesses the ASN and another possesses the prefix? (just a
> comment, nothing more)
> 

Not sure I can parse the above unless s/where/were/... If so, that was
originally in the document prior to -09, but the consensus of the WG was
to remove multiple signature support.

Regards,
Brian