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

[Roman Danyliw <[e-mail]>]

Hi!

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Thursday, August 8, 2019 11:51 AM
> To: Adam Roach <[e-mail]>; Roman Danyliw <[e-mail]>;
> The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-
> [e-mail]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37:
> (with DISCUSS and COMMENT)
> 
> 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.

Ok.  That makes sense.  Thanks for this explanation.

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

This editorial approach would clean it up for me.  I wasn't sure whether something was missing.

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

Makes sense.

>    ---
> 
>     >> (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'd think normative.

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

Makes sense to me.
 
>     ---
> 
>     >> (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.

Generically referring to RFC8445 as done in this pull request works too.

Regards,
Roman 

>     Regards,
> 
>     Christer
> 
>