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

[Terry Manderson <[e-mail]>]

Hi Brian,

On 18/05/2016, 11:08 PM, "Brian Haberman" <[e-mail]> wrote:
>
>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."

That is a fine snippet to include. Thank you.

>
>> 
>> 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.

Understood. I was considering a more operational triage of the signed
objects prior to validation.
But in reflection that can introduce an unintentional error situation. Put
aside this item.

>
>> 
>> 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.

Correct. I raise the point so that people who implement and/or use
rpsl-sig do not accidentally assume that by adding a signature some form
of magic happens that unreservedly protects the object - you can take this
now as 'comment' fodder.

>
>> 
>> ----------------------------------------------------------------------
>> 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.

Thanks

>
>> 
>> 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.

Yes, I typo'd. 

Thanks for the info on the WG consensus for multiple signature support.

I'll clear my discuss shortly.

Cheers
Terry