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

["Ben Campbell" <[e-mail]>]

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

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

[...]

>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------

[...]

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