[straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-straw-b2bua-dtls-srtp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1)
I have a fairly fundamental concern about this document that I'd like to
discuss. My impression is that most B2BUAs in the market today that
handle DTLS-SRTP do so with the explicit purpose of accessing the media.
That is, if I need a box that doesn't access the media I use a SIP proxy,
and if I need one that does access it I use a B2BUA. I realize that there
are more flavors of B2BUA defined in RFC 7092, but in terms of how real
SBCs work, it seems to me that they break DTLS-SRTP intentionally if they
do so at all. 

If that's the case, the question then arises about the value of writing
down normative recommendations that are more than likely to be ignored.
Perhaps this document would have made more sense as informational,
offering a non-normative explanation of what a B2BUA should do if it does
not want to break e2e security. Even as an informational document it's
still not obvious to me that there is much at all to say here for
media-aware B2BUAs that isn't entirely reductive -- "don't terminate
DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an
informational document it wouldn't be suggesting normative requirements
that are out of sync with real deployments.

Could you articulate the reasons why someone would build a B2BUA that
follows the recommendations in this draft? I note that the draft says
nothing about using a TURN server as a media relay, which seems like it
would be more common than using a B2BUA for the same purpose. Aren't
B2BUAs typically deployed *because* they are media-aware?

(2)
Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are
problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement for
inspection B2BUAs without explaining what the exception cases are, and
3.1.2.2 creates no normative requirements for modification B2BUAs. It's
not even clear to me why the distinction is being drawn between the two
kinds of B2BUAs if the bottom line is that in both cases the
recommendation is to not terminate DTLS-SRTP. But this brings us back to
the above comment. The problem here seems to be that what the WG and the
IETF would want to say here is that B2BUAs MUST NOT terminate DTLS-SRTP
to man-in-the-middle the media, but that is what B2BUAs generally do, so
instead the text waffles and the recommendations are watered down and
unclear.

(3)
The characterization of the RFC 4474 mechanism seems to contradict the
way the mechanism is actually specified. The 4474 mechanism was designed
such that intermediaries would be able to provide signatures on behalf of
users (e.g., see RFC 4474 Section 3, "This specification allows either a
user agent or a proxy server to provide identity services and to verify
identities ... in the initial use of this mechanism, it is likely that
intermediaries will instantiate the authentication service role"). So the
claim that terminating DTLS-SRTP would cause 4474 identity and integrity
checks to fail isn't true, because an SBC can decrypt and re-sign the
request itself. A B2BUA that bridges two administrative domains can check
the validity of the signature in the domain on on side as authorization
to form a new signature that is valid in the domain in the other side.

The fact that user-provided identity assertions are not guaranteed to
persist end-to-end is one key reason for the ongoing work in the STIR WG.
The work there and elsewhere shows that it's fairly widely acknowledged
that 4474 has not seen the deployment that was hoped for when it was
specified. Making its use a normative requirement here again seems out of
sync with deployment reality. I would encourage you to review
draft-ietf-stir-rfc4474bis and reconsider what security mechanism should
form the basis of the recommendations in this draft.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.1.1:

Is there anything new being specified here that isn't already specified
in other SIP documents?

Section 3.2:

Is this saying anything that RFC 5763 doesn't already say?