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

Hello All

  Version 38 was just submitted. please let us know your thoughts

Cheers
Suhas

On Thu, Aug 8, 2019 at 6:27 PM Roman Danyliw <rdd@cert.org> wrote:

> Hi Christer!
>
> Adam and you clarifications; and this pull request addresses my discuss
> points.  Please go ahead and publish.
>
> I appreciate it the quick iteration.
>
> Thanks,
> Roman
>
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > Sent: Thursday, August 8, 2019 2:04 PM
> > To: Adam Roach <adam@nostrum.com>; Roman Danyliw <rdd@cert.org>;
> > The IESG <iesg@ietf.org>
> > Cc: fandreas@cisco.com; mmusic-chairs@ietf.org; mmusic@ietf.org; draft-
> > ietf-mmusic-ice-sip-sdp@ietf.org
> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37:
> > (with DISCUSS and COMMENT)
> >
> > 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"
> > <christer.holmberg@ericsson.com> 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%2F
> > ice-sip-sdp%2Fpull%2F18%2Ffiles
> >
> >         Please see the last change in the pull request.
> >
> >         Regards,
> >
> >         Christer
> >
> >
> >
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>