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

[Adam Roach <[e-mail]>]

I'm not generally around this week, but had a few moments and wanted to 
weigh in on these discuss points, as they don't appear to have responses 
yet. :)

On 8/5/19 21:28, Roman Danyliw via Datatracker wrote:
> (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.


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


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


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

/a

____
[1] And there is some work happening in this area, albeit not with TLS; 
see https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ 
for example.