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

[Christer Holmberg <[e-mail]>]

Hi,

I have now updated the pull request based on the discussion below. Again, the changes related to the Security Considerations are at the end of the pull request:

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

Regards,

Christer


On 08/08/2019, 18.50, "Christer Holmberg" <[e-mail]> wrote:

    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://protect2.fireeye.com/url?k=fc78358d-a0f2175b-fc787516-0cc47ad93dcc-f3a799884e91abda&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2Fice-sip-sdp%2Fpull%2F18%2Ffiles
    
        Please see the last change in the pull request.
    
        Regards,
    
        Christer