Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi Adam,

Thanks for Your input! A few comments from me inline.
    
    >> (1) Section 8.1. Per “These require techniques for message integrity and
    >> encryption for offers and answers, which are satisfied by the TLS mechanism
    >> [RFC3261] when SIP is used”, the guidance is right (use TLS), but this
    >> reference is outdated.  Section 26.2.1 of RFC3261 provides rather old guidance
    >> on the ciphersuite.  Is there a reason why not to use BCP195 for guidance on
    >> versions/ciphersuites?
    >
    > As much as SIP has a convoluted layering story, the separation between 
    > SIP and SDP remains pretty clean (both from a protocol perspective and 
    > organizationally within the IETF). While it's likely the case that RFC 
    > 3261 could use some updating to its security story [1], I don't think it 
    > makes sense to hold up this document on that work. It's really rather 
    > far outside the purview of this document to make changes to the 
    > underlying cipher suite; in fact, I would argue that doing so would be 
    > disallowed in MMUSIC, since it is part of the core protocol work that 
    > clearly falls in SIPCORE's charter.

    I agree. If we need to update the security properties of SIP, let's do it properly in SIPCORE.
    
    ---    

    >> (2) Section 8.2.1, The “voice hammer attack” appears to be an artifact of SDP.
    >> The text explicitly notes that this attack is not “specific to ICE but that ICE
    >> can help provide a remediation” (aside, should “remediation” be “mitigation”).
    >> However, the preceding introductory section (8.2) explicitly says “there are
    >> several attacks possible with ICE”.  These two statements aren’t consistent.
    >
    > It seems that the solution for this would be to promote section 8.2.1 to 
    > its own top-level section inside the security considerations section. 
    > Would that work for you?
    
   I would be ok with that.

   However, I think it would be good to add text to 8.2.1 saying that a "Voice hammer attack" attack can take place even when the 
   attacker is an authenticated user, and then go on describing how ICE can be used to prevent the attack. 


   ---
    
    >> (3) Section 8.2.2.  This section reads like an operational consideration.  The
    >> setup scoped in the parent Section 8.2, “there are several attacks possible
    >> with ICE when the attacker is an authenticated and valid participant in the ICE
    >> exchange”, isn’t discussed here (i.e., how is the presence or absence of an ALG
    >> germane to an attacker who is a participant in the ICE exchange)
    >
    > It seems that the solution for this would be to promote 8.2.2 to its own 
    > top-level section within the document, preceding the Security 
    > Considerations section, possibly with a renaming along the lines of 
    > "Operational Considerations: Interactions with Application Layer 
    > Gateways and SIP". Does that work for you?
    
    I am fine making it its own top-level section. But, do you think it should be a normative section, or an Appendix?

    > I note that making both of these changes leaves section 8.2 empty save 
    > for the introductory text; I propose that we simply remove the section.
    
    I am fine with that.
    
    ---

    >> (4) Section 8.  Is there a reason why the security considerations from RFC8445
    >> are not noted as also applying (e.g., Section 19.1 - .4.
    >
    > Would the addition of text at the top of section 8 that says "Please 
    > note that the security considerations from sections 19.1 through 19.4 of 
    > [RFC8445] also apply to this document." address your concern?
    
    Others have commented on this, and there is a pull request addressing it:

    https://github.com/suhasHere/ice-sip-sdp/pull/18/files

    Please see the last change in the pull request.

    Regards,

    Christer