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

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 30 Nov 2015 20:58:18 -0800

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?

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 01 Dec 2015 12:40:23 -0600

(Commenting on discuss items 1 and 2. See separate email for comments on 
3).

I think items 1 and 2 come down to having a clear scope and purpose. 
This version actually made progress in that direction (see section 1.2), 
but clearly didn't reach the goal.

Normally, I I would favor making this informational, and removing the 
normative language. But on reflection, I see that the straw charter 
calls for describing normative requirements to make certain features 
work. In this case, the "certain feature" is e2e dtls-srtp.

Alissa: Would it help if we clarified the scope along the following 
lines:

- This draft defines certain behaviors that a b2bua needs to engage (or 
not engage) in in order to allow the "feature" of e2e dtls-srtp.

- Define what we mean by e2e. I _think_ we are talking about end-user 
devices, and that we don't want to leave room for semantic games along 
the line of calling a b2bua an "end". (This would change the arguments 
around certain requirements, e.g."don't terminate srtp".)

- Recognize that there are b2buas that intentionally do not allow e2e 
protection. We cannot stop those, and we don't need to get wrapped 
around reasons why or whether that's good or bad.

We would also need to be more consistent with the use of 2119 keywords.

Authors/Shepherd/Chairs: Please indicate your thoughts. It would be 
really nice to have an idea of the way forward by Thursday's telechat.

Thanks!

Ben.

On 30 Nov 2015, at 22:58, Alissa Cooper wrote:

> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Dec 2015 06:07:06 -0800

> On Dec 1, 2015, at 10:40 AM, Ben Campbell <[email-masked]> wrote:
> 
> (Commenting on discuss items 1 and 2. See separate email for comments on 3).
> 
> I think items 1 and 2 come down to having a clear scope and purpose. This version actually made progress in that direction (see section 1.2), but clearly didn't reach the goal.
> 
> Normally, I I would favor making this informational, and removing the normative language. But on reflection, I see that the straw charter calls for describing normative requirements to make certain features work. In this case, the "certain feature" is e2e dtls-srtp.
> 
> Alissa: Would it help if we clarified the scope along the following lines:
> 
> - This draft defines certain behaviors that a b2bua needs to engage (or not engage) in in order to allow the "feature" of e2e dtls-srtp.

I think the underlying question is, if such a document were written, would it say anything that isn’t entirely reductive, obvious, or already documented elsewhere? As I inquired about in my comments, it seems as though the substance of 3.1.1 and 3.2 may already be documented elsewhere. Presumably 3.1.2 would disappear in the approach you suggest, since the behavior amounts to “don’t do anything” or “be a proxy,” roughly.

> 
> - Define what we mean by e2e. I _think_ we are talking about end-user devices, and that we don't want to leave room for semantic games along the line of calling a b2bua an "end". (This would change the arguments around certain requirements, e.g."don't terminate srtp”.)

Yes, that was my assumption in reading the document.

> 
> - Recognize that there are b2buas that intentionally do not allow e2e protection. We cannot stop those, and we don't need to get wrapped around reasons why or whether that's good or bad.
> 
> Authors/Shepherd/Chairs: Please indicate your thoughts. It would be really nice to have an idea of the way forward by Thursday's telechat.

Yep, I’d like to understand where people see the value in publishing this or what impact they expect it to have on existing B2BUA implementations.

Thanks,
Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Dec 2015 10:07:44 -0500

> around certain requirements, e.g."don't terminate srtp".)

I think this is important! And I think it goes beyond this draft or 
perhaps even this WG.

ISTM that the definition of "end" is a matter of control. I may have a 
server somewhere (maybe in a cloud), as well as one or more local 
devices. As long as I control it and am aware of its behavior it can be 
considered an *end* representing me, and carry my identity in the signaling.

And this can be true even if it is not an "end" in the overall topology 
of a call. For instance, I could have a B2BUA (application server) 
between my phone and the "other" party in a call. It might record the 
call (on my behalf) or otherwise process the media. It could serve as 
the hub for a decomposed endpoint.

OTOH, a "traditional" SBC is typically *not* entirely under my control. 
It may well have policies that I disagree with, but can't avoid. I would 
like to ensure that it can't access the content of my media.

This gets tricky when my SP provides application services to me in a 
shared server. It may give me some configuration options to influence 
the behavior of that server. But it may also have other policies of its 
own that it doesn't allow me to control.

	Thanks,
	Paul

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Dec 2015 07:17:42 -0800

> On Nov 30, 2015, at 9:31 PM, Ben Campbell <[email-masked]> wrote:
> 
> A couple of quick comments on your discuss item 3 below. (I will leave it to the authors to respond to the rest)
> 
> 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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 2 Dec 2015 16:14:35 +0000

Please see inline for few responses.

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Wednesday, 2 December 2015 at 12:10 AM
To: Alissa Cooper <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: Alissa Cooper's Discuss on
draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

>around certain requirements, e.g."don't terminate srtp".)

Ok. We can add text like what Ben is suggesting to the draft if its going
to make it clearer.

>around reasons why or whether that's good or bad.

Agree. OTOH there are B2BUAs that do allow DTLS-SRTP end-to-end. See below
for some points on this.

>> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/

I am aware of B2BUAs that pass-through SRTP (in this case DTLS-SRTP) end to
end as well. In several deployments B2BUAs/SBCs are used for address
hiding / media latching (as described in
https://tools.ietf.org/html/rfc7362).
In these scenarios the B2BUAs will be in media path as well but it just
changes the UDP/IP headers and relay the UDP payload as is with out
inspecting/modifying payload.

>> follows the recommendations in this draft?

B2BUAs used in deployments like the above mentioned scenarios can use the
recommendations in this draft.

>>I note that the draft says
>> would be more common than using a B2BUA for the same purpose.

Not all endpoints support ICE yet which is one of the reasons
B2BUAs are used for simple media latching as well (described in RFC7362).

>> Aren't

They can be media-aware or can just switch the media with out being aware
of media as well.

Regards,
Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 2 Dec 2015 16:23:28 +0000

Hi Paul,

-----Original Message-----
From: straw <[email-masked]> on behalf of Paul Kyzivat
<[email-masked]>
Date: Wednesday, 2 December 2015 at 8:37 PM
To: "[email-masked]" <[email-masked]>
Subject: [straw] What is an "end"?

>like to ensure that it can't access the content of my media.

Agree with all the above. I don¹t see a way by which one endpoint can know
if the peer is a endpoint/B2BUA or SBC.
If both peers are using rfc4474 it can verify the identity of the peer but
it will still not tell whether that is the final destination
for the call or if the call goes beyond that device(like in the case of
B2BUA/SBC).

I don¹t see a way to solve this with existing mechanisms.

Ram

>_______________________________________________
>straw mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/straw

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Dec 2015 13:56:52 -0500

> if the peer is a endpoint/B2BUA or SBC.

No, it can't.

> for the call or if the call goes beyond that device(like in the case of

Yes,

> I don¹t see a way to solve this with existing mechanisms.

I don't think it is something to *solve*.

But it is a distinction that may be worth making when doing security 
analysis and review. And it is a distinction that would be good to make 
in product documentation.

If a user has an intermediary server that he puts into his calls, then I 
think he should be able to permit it to terminate the media for his calls.

Maybe such things should have a different name that just B2BUA.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 02 Dec 2015 17:26:04 -0600

On 2 Dec 2015, at 9:17, Alissa Cooper wrote:

>> A couple of quick comments on your discuss item 3 below. (I will 
>> leave it to the authors to respond to the rest)
>>

[...]

[...]

>> 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 document shouldn't be making recommendations (especially normative 
ones) about client behavior here. (I thought we had taken that out, but 
obviously missed an instance.)

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

I'm confident it will get done. At the time I recommended 4474 rather 
than 4474bis, I was concerned it might take a while. I feel better about 
that after Yokohama :-). But in any case, we should think about wether 
this can be demoted to an informational reference, if we remove the 
attempt to specify endpoint behavior.

Thanks!

Ben.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Dec 2015 21:17:45 -0800

> On Dec 2, 2015, at 8:14 AM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
>> 
>> 

Ok. What I am still missing is why this draft needs to be published to make that happen. This is the type of SBC to which the Section 3.1.1 guidance is directed. How does the behavior of existing media-latching SBCs differ from what 3.1.1 tells them to do? And if this type of SBC implementation is the key target audience, doesn’t that make the 3.1.2 guidance essentially no-ops?

Alissa

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 03 Dec 2015 15:12:11 -0600

On 2 Dec 2015, at 23:17, Alissa Cooper wrote:

> Ok. What I am still missing is why this draft needs to be published to 
> make that happen. This is the type of SBC to which the Section 3.1.1 
> guidance is directed. How does the behavior of existing media-latching 
> SBCs differ from what 3.1.1 tells them to do? And if this type of SBC 
> implementation is the key target audience, doesn’t that make the 
> 3.1.2 guidance essentially no-ops?

Authors:

After discussion on today's telechats, and some side discussions with 
Alissa, I believe this question is the lynch-pin for making any 
progress. I advise people to work this out first before worrying about 
the rest of the discussion: Can we articulate how we expect this draft 
will change implementer and/or operator behavior?

Obviously B2BUAs that exist for reasons that require modification of 
RTP/RTCP, or cleartext access to the encrypted bits of SRTP are not 
going to conform, and are therefore out of scope. The draft doesn't seem 
to concern itself with b2buas that are not in the media path at all. 
(Maybe it should, since there are plenty of purely signaling-plane ways 
to break dtls-srtp?).

That leaves the question of b2buas in the media path that do not require 
modification or cleartext access to protected bits in srtp--effectively 
media-relays as described in 3.1.1 Do we believe people do not know how 
to build or use such devices without breaking dtls-srtp? Are people 
aware of such devices that break dtls-srtp when they don't need to? 
Perhaps by misconfiguration, or because they use SBCs designed for more 
invasive use cases?

Thanks!

Ben.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 9 Dec 2015 10:50:49 -0800

> On Dec 3, 2015, at 1:12 PM, Ben Campbell <[email-masked]> wrote:
> 
> After discussion on today's telechats, and some side discussions with Alissa, I believe this question is the lynch-pin for making any progress. I advise people to work this out first before worrying about the rest of the discussion: Can we articulate how we expect this draft will change implementer and/or operator behavior?
> 
> Obviously B2BUAs that exist for reasons that require modification of RTP/RTCP, or cleartext access to the encrypted bits of SRTP are not going to conform, and are therefore out of scope. The draft doesn't seem to concern itself with b2buas that are not in the media path at all. (Maybe it should, since there are plenty of purely signaling-plane ways to break dtls-srtp?).
> 
> That leaves the question of b2buas in the media path that do not require modification or cleartext access to protected bits in srtp--effectively media-relays as described in 3.1.1 Do we believe people do not know how to build or use such devices without breaking dtls-srtp? Are people aware of such devices that break dtls-srtp when they don't need to? Perhaps by misconfiguration, or because they use SBCs designed for more invasive use cases?

As Ben says, I think this draft would add value if it could articulate the problem statement, including the kinds of B2BUAs that cause the problem, and then articulate a solution that those kinds of B2BUAs have a reasonable chance of implementing given what they are otherwise designed to do.

Alissa

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 09 Dec 2015 14:25:05 -0600

I had an offline discussion with Alissa and Barry yesterday. I think we 
have a proposed way forward to deal with the "big-picture" issues from 
Alissa's discuss. This does not necessarily cover every detail of her 
(or Stephen's) discuss and comments, but I think we need to deal with 
the existential stuff first.

The draft needs clarifications to the problem statement, the draft goals 
and scope, and a clearer separation between normative statements and 
non-normative considerations.

I think that would be easiest with some reorganization. Here's a 
proposed outline. (I don't think you need to stick to this outline in 
detail, as long as the points are clear)

Thanks!

Ben.
----------------

Problem:

- B2BUAs (especially SBCs) often make e2e dtls-srtp impossible. There 
are use cases where they could do their jobs and still allow e2e 
dtls-srtp.
- The dtls-srtp dependency on RFC 4474 makes that hard in many cases.
- What do we mean by e2e DTLS-SRTP? (I _think_ we mean from the 
perspective of the b2bua, where that b2bua is not a party to the 
DTLS-SRTP SA, and doesn't have the session key or private keys for DTLS 
cert(s).

Goals and Scope:

- Goal is to provide guidance on how b2buas that could possibly do their 
jobs without breaking e2e dtls-srtp to do so.
- B2BUAs exist that will still not allow e2e dtls-srtp for various 
reasons. These are out-of-scope, and the draft should not attempt to 
make value judgements about them.
- Termination of dtls-srtp at the b2bua is out of scope by definition 
(it's not e2e).

Normative rules for B2BUAs to allow e2e DTLS-SRTP:

  - Consider both media signaling layers (including for non-media-path 
b2buas)
  - Discuss differences for 4474 and 4474bis, including how a b2bua 
might tell them apart.(Hopefully 4474 will be obsolete soon, but we 
should still discuss it, since it has significant impact on things like 
media-latching since it signs the entire SDP payload.)
  - Discuss differences if the b2bua acts as a 4474/4474bis 
authenticator and/or verifier.

Implications/considerations for each b2bua type (non-normative):

  - How do the normative requirements in the previous sections impact 
the various b2bua types.

Normal security and privacy considerations.

On 9 Dec 2015, at 12:50, Alissa Cooper wrote:

>>> Ok. What I am still missing is why this draft needs to be published 
>>> to make that happen. This is the type of SBC to which the Section 
>>> 3.1.1 guidance is directed. How does the behavior of existing 
>>> media-latching SBCs differ from what 3.1.1 tells them to do? And if 
>>> this type of SBC implementation is the key target audience, 
>>> doesn’t that make the 3.1.2 guidance essentially no-ops?
>>
>> Authors:
>>
>> progress. I advise people to work this out first before worrying 
>> about the rest of the discussion: Can we articulate how we expect 
>> this draft will change implementer and/or operator behavior?
>>
>> going to conform, and are therefore out of scope. The draft doesn't 
>> seem to concern itself with b2buas that are not in the media path at 
>> all. (Maybe it should, since there are plenty of purely 
>> signaling-plane ways to break dtls-srtp?).
>>
>> That leaves the question of b2buas in the media path that do not 
>> require modification or cleartext access to protected bits in 
>> srtp--effectively media-relays as described in 3.1.1 Do we believe 
>> people do not know how to build or use such devices without breaking 
>> dtls-srtp? Are people aware of such devices that break dtls-srtp when 
>> they don't need to? Perhaps by misconfiguration, or because they use 
>> SBCs designed for more invasive use cases?
>
> As Ben says, I think this draft would add value if it could articulate 
> the problem statement, including the kinds of B2BUAs that cause the 
> problem, and then articulate a solution that those kinds of B2BUAs 
> have a reasonable chance of implementing given what they are otherwise 
> designed to do.
>
> Alissa
>
>>
>> Thanks!
>>
>> Ben.