[mpls] Re: Roman Danyliw's Discuss on draft-ietf-mpls-ri-rsvp-frr-18: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

My two cents on this point is that I was surprised this document made a specific recommendation about what cryptographic algorithm to use. It seems like any such recommendation is out of scope. I would've expected it to say something more like “use RSVP-TE best practices”, which is basically the first sentence, and then proceed on to the second paragraph, which I think is quite a good analysis.

If it were up to me (which it’s not!) I’d fix the problem by deleting the sentence.

“Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away”. :-) 

To repeat: not my DISCUSS, not my document, everyone is free to ignore my opinion.

—John

> On May 28, 2024, at 5:06 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-mpls-ri-rsvp-frr-18: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!FZMclPVLzwIU9GLQGAqrafNvZRSxTxADkFAk91HDbvrfGdb512nlGsnT8gttmZTt6bS-4riwPrD5$
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/__;!!NEt6yMaO-gk!FZMclPVLzwIU9GLQGAqrafNvZRSxTxADkFAk91HDbvrfGdb512nlGsnT8gttmZTt6bS-4gk48yXh$
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** Section 5
>   When using RSVP
>   Cryptographic Authentication [RFC2747], more robust algorithms
>   [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed
>   message digest where possible.
> 
> I don’t intended to open the generic topic of RSVP authentication.  However, I
> need help understanding the proposed guidance on cryptographic authentication.
> 
> RFC2104 specifies the core HMAC construction and HMAC-MD5
> 
> RFC2747 says “HMAC-MD5 is required as a baseline to be universally included in
> RSVP implementations providing cryptographic authentication, with other
> proposals optional”
> 
> FIPS-180-3 = specifies SHA-1, SHA-256, SHA-384, and SHA-512
> 
> What exactly is the recommendation on the “more robust algorithms … where
> possible”?  Across all the referenced drafts, HMAC-MD5, -SHA1, -SHA256, -SHA386
> and -SHA512 were cited.
> 
> Is this document intending to recommend MD5 and SHA1 as “robust algorithms”? My
> recommendation would be that implementations using RSVP Cryptographic
> Authentication SHOULD use HMAC-256/-386/-512.  Based on the RFC2747, HMAC-MD5
> remains MTI.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to Reese Enghardt for the GENART review.
> 
> Idnits reports:
> 
>  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>     have content which was first submitted before 10 November 2008.  If you
>     have contacted all the original authors and they are all willing to grant
>     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
>     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>     (See the Legal Provisions document at
>     https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!FZMclPVLzwIU9GLQGAqrafNvZRSxTxADkFAk91HDbvrfGdb512nlGsnT8gttmZTt6bS-4pWpfbt6$  for more information.)
> 
>  == Unused Reference: 'RFC3936' is defined on line 1166, but no explicit
>     reference was found in the text
> 
> 
>