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

[Alissa Cooper <[e-mail]>]

> On Nov 30, 2015, at 9:31 PM, Ben Campbell <[e-mail]> wrote:
> 
> A couple of quick comments on your discuss item 3 below. (I will leave it to the authors to respond to the rest)
> 
> On 30 Nov 2015, at 22:58, Alissa Cooper wrote:
> 
>> 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.
> 
> There was discussion that a b2bua could terminate dtls-srtp if it provided an identity service, or acted in collusion with an identity service.  My understanding is that the authors felt that delving into special cases where it might be "okay" for a b2bua to terminate dtls-srtp would add too much complexity to the point. (There's also the fact that dtls-srtp says you SHOULD use 4474, not MUST).

If you look at this through the lens of 4474 deployment, it isn’t really a special case, since neither case is in much use. I think the complexity arises because the document is trying to make recommendations. If it were to just describe the implications of what would happen if B2BUAs in various scenarios encountered 4474 signatures, then at least it could be made to be a correct description of the behaviors one could theoretically encounter.

> 
> I tend to agree on the complexity--but I think it would make sense to clarify this to say that a b2bua that is not also providing an identity service is likely to break things.

I think the underlying problem here gets back to the question about whether this draft is making recommendations that anyone implementing a B2BUA is likely to follow, or whether it is making recommendations for the sake of writing them down and attaching an RFC number to them. Because if it’s the former, it doesn’t make much sense for the basis of this to be 4474.

> 
> As far as 4474bis is concerned--they originally referenced 4474bis, and I suggested that they not do so. My reasoning was that both 4474 and 4474bis (as written at that time) protected the fingerprint, which was the important bit here--and that since 4474bis was expected to obsolete 4474, a reference to 4474 would "self upgrade", so to speak. Do you disagree with that? (But to be totally honest, my concern was entirely about avoiding an extended stay in MISSREF land. Maybe that's not as big of a concern now?)

I think when we’re at the point where we spun up a working group for the purpose of replacing the original document, we’re better off not normatively requiring use of the original. But again here I question whether it’s appropriate for this document, which is nominally about B2BUA behavior, to be putting any requirements on endpoints in the first place.

The STIR work is advancing and there is demand for it to get done, so I wouldn’t be worried about 4474bis not finishing.

Alissa

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