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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Thursday, December 03, 2015 4:56 AM
> To: Alissa Cooper
> Cc: [e-mail];
> [e-mail]; IESG; [e-mail];
> [e-mail]
> Subject: Re: Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09:
> (with DISCUSS and COMMENT)
> 
> 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.

Yes, the draft already discusses that B2BUA must not tamper the 4474 signatures, otherwise the identity integration procedure will fail. We can update the draft to point to 4474bis (In fact the doc was pointing to 4474bis in the previous versions).

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

It's making recommendations for the implementers of B2BUA to follow.

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

Yes.

> (I thought we had taken that out, but
> obviously missed an instance.)

Oops. We missed updating the Security considerations section to remove the normative reference, will correct in the next update.

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

Works for me, this draft can point to 4474bis instead of 4474 and 4474bis can be informational reference.

-Tiru

> 
> Thanks!
> 
> Ben.