Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes]

[Stephen Farrell <[e-mail]>]

On 30/10/14 07:07, Lorenzo Miniero wrote:
> On Thu, 30 Oct 2014 05:20:37 +0530 "Parthasarathi R"
> <[e-mail]> wrote:
> 
>> Hi Lorenzo,
>> 
>> I'm not seeing the convincing mechanism in your proposal which
>> overcome MITM issue except trusting B2BUA. The most complex
>> requirement in your e-mail is that
>> 
>> <snip> " Without preventing additional mechanismsto be involved
>> for
>>> end-to-end validation of some kind, of course.
>> </snip>
>> 
>> Could you please elaborate end-to-end validation in your mind.
>> 
> 
> 
> Hi Partha,
> 
> sorry, I should have been clearer about an aspect. I agree it's still
> MITM: when I said "everything else's MITM" I actually meant
> "everything else is not any different from a MITM attack", and that's
> why I believe the trust is an important aspect.

And the IETF has also decided a number of times to not MITM TLS.
The impact of making that mistake would be huge and none of the
proponents of the various MITM schemes have ever evaluated that
impact as part of their proposal. That, and the fact that changing
from a two-part to a multi-party security protocol is very very
hard are among the reasons that all such proposals so far have
been DOA.

Gratuitously throwing the misplaced word "trust" into such a
discussion does not help.

S.

> 
> About the additional mechanism, I don't have any specific solution in
> mind. It's my understanding, though, that the IETF community has
> understood there's a problem to solve there, and is already trying to
> address it somehow, which is why I continue to believe we shouldn't
> give up on it either. For insta,ce, I do recall a presentation at the
> AVTCORE session in Toronto which tried to address a similar concern:
> 
> http://www.ietf.org/proceedings/90/slides/slides-90-avtcore-6.pdf
> 
> The presentation was called "Requirements for Secure RTP Media
> Switching", which should at least allow for a more proper management
> of media-aware as well, for instance.  I believe there are use cases
> that justify both media-aware and media-termination in secure
> scenarios, and ignoring them will result in the same unpredictable
> consequences that lead to WGs like BLISS or STRAW itself: without
> some guide from IETF documents, developers will either drop security
> entirely (something we obviously don't want) or start doing things
> one way or another to make it work.
> 
> Lorenzo
> 
> 
>> Thanks Partha
>> 
>>> -----Original Message----- From: Lorenzo Miniero
>>> [mailto:[e-mail]] Sent: Wednesday, October 29, 2014
>>> 12:49 PM To: Christer Holmberg Cc: Parthasarathi R; 'Stephen
>>> Farrell'; [e-mail]; 'Richard Barnes'; 'Sean Turner' 
>>> Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE:
>>> IETF#90: Draft STRAW minutes]
>>> 
>>> On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg
>>> <[e-mail]> wrote:
>>> 
>>>> (As co-chair)
>>>> 
>>>> Hi,
>>>> 
>>>> If anyone has an issue with the general approach suggested by
>>>> Partha,
>>> please indicate to on the list, so that we in Honolulu can focus
>>> on the technical aspects.
>>>> 
>>> 
>>> 
>>> I'm not convinced that we should give up on those. Media Aware
>>> and Media Termination are part of the STRAW taxonomy, and act as
>>> if they just didn't exist doesn't seem the right thing to do
>>> IMHO.
>>> 
>>> In Toronto it has been made clear that there are issues and
>>> concerns about what looked like standardizing a MITM for media.
>>> My personal feeling is that this can be considered mostly a
>>> matter of trust. The B2BUA should not necessarily be a sneaky or
>>> "transparent" component as long as participants are involved.
>>> This means that, as long as I trust the B2BUA in any scenario
>>> that involves Media Aware/Terminartion stuff, and so trust the
>>> B2BUA to secure the session on the other end or not do anything I
>>> didn't sign up for, the B2BUA is actually my "peer" in that 
>>> respect. Without preventing additional mechanismsto be involved
>>> for end-to-end validation of some kind, of course. Everytihng
>>> outside of that is, I agree, MITM and shouldn't be avalled or
>>> fostered in any way.
>>> 
>>> These are just some thoughts I tried to give to the idea, and how
>>> I basically changed the related text in the RTCP draft as well to
>>> try and address the issue, so I guess there will be plenty of
>>> time to bash me when I talk about this in Honolulu :-)
>>> 
>>> Lorenzo
>>> 
>>> 
>>>> Regards,
>>>> 
>>>> Christer
>>>> 
>>>> -----Original Message----- From: Parthasarathi R
>>>> [mailto:[e-mail]] Sent: 29. lokakuuta 2014
>>>> 1:28 To: 'Stephen Farrell'; Christer Holmberg; [e-mail] 
>>>> Cc: 'Richard Barnes'; 'Sean Turner' Subject: RE: B2BUA handling
>>>> in DTLS-SRTP [was RE: [straw] IETF#90:
>>> Draft STRAW minutes]
>>>> 
>>>> Hi all,
>>>> 
>>>> One of the way to address MITM issue in STRAW WG B2BUA handling
>>>> of
>>> DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of
>>> draft- ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or
>>> Media Termination" (Sec 3.2 of
>>> draft-ram-straw-b2bua-dtls-srtp-00).
>>>> 
>>>> By this proposal, the scope of the work is to cover only
>>>> end-to-end
>>> DTLS-SRTP through B2BUA. The media relay provides end-to-end
>>> security but there are challenges w.r.t NAT, forking, ICE,
>>> identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted
>>> out in this milestone.
>>>> 
>>>> During IETF-90 and in the mailing alias, I haven't heard any
>>>> concern
>>> for Media relay handling in B2BUA. please let me know your
>>> opinion on the same.
>>>> 
>>>> Thanks Partha
>>>> 
>>>>> -----Original Message----- From: Stephen Farrell
>>>>> [mailto:[e-mail]] Sent: Wednesday, July 30,
>>>>> 2014 3:05 PM To: Parthasarathi R; 'Christer Holmberg';
>>>>> [e-mail] Cc: 'Richard Barnes'; 'Sean Turner' Subject:
>>>>> Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: 
>>>>> Draft STRAW minutes]
>>>>> 
>>>>> 
>>>>> on vacation, back in a week
>>>>> 
>>>>> terminating DTLS-SRTP is maybe fine but means being one of
>>>>> the endpoints intended to be involved in the TLS session.
>>>>> Doing a MITM
>>> on
>>>>> TLS is  not at all fine.
>>>>> 
>>>>> S.
>>>>> 
>>>>> On 30/07/14 02:34, Parthasarathi R wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I have different view than the security folks look at this
>>>>>> draft.
>>>>> This draft
>>>>>> intention is not to violate RFC 2804. In case this draft is
>>>>>> not standardized, all B2BUA handling DTLS-SRTP will end up
>>>>>> in
>>> violating
>>>>> RFC 2804
>>>>>> due to the lack of guidelines/standards to follow. Please
>>>>>> look
>>> into
>>>>> this
>>>>>> draft from SIP recording architecture in B2BUA (Fig 1 of
>>>>>> RFC
>>> 7245)
>>>>> usage
>>>>>> perspective wherein the senders/receiver is informed about
>>>>>> the
>>> call
>>>>>> recording (like call centre usage scenario) and no RFC
>>>>>> 2804
>>>>> violation.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> In IETF-90 meeting, the security concerns are raised about
>>>>>> this draft
>>>>> usage.
>>>>>> It will be good to document as part of this document if it
>>>>>> is
>>> really
>>>>>> security issue. I'm not seeing any major security concerns
>>>>>> as
>>> B2BUA
>>>>> is yet
>>>>>> another UA. Please let me know the list of security
>>>>>> concern
>>> specific
>>>>> to
>>>>>> B2BUA in DTLS-SRTP.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> In reality, B2BUA terminating DTLS-SRTP is not avoidable
>>>>>> because
>>> of
>>>>> the
>>>>>> different codec profile between the deployed SIP UAs. Say
>>>>>> SIPoWS
>>> in
>>>>> browser
>>>>>> (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as
>>>>>> of
>>> today
>>>>> and SIP
>>>>>> Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion
>>>>>> to
>>>>> terminate the
>>>>>> media in the middle as there is no solution exists in IETF
>>>>>> for
>>> the
>>>>> same. The
>>>>>> lack of standard leads to proprietary session border
>>>>>> controller (SBC) solutions which breaks other SIP
>>>>>> enhancements as well.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> Partha
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> From: straw [mailto:[e-mail]] On Behalf Of
>>>>>> Christer
>>>>> Holmberg
>>>>>> Sent: Saturday, July 26, 2014 7:54 PM To: [e-mail] 
>>>>>> Cc: Richard Barnes ([e-mail]); Sean Turner; Stephen
>>>>>> Farrell Subject: [straw] IETF#90: Draft STRAW minutes
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> (Co-chair)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Below are the STRAW minutes that the chairs intend to
>>>>>> upload.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> However, before we do that, we would like to ask the
>>>>>> community to
>>>>> take a
>>>>>> look at least at the notes associated with the DTLS-SRTP
>>>>> presentation, as it
>>>>>> caused lots of discussion.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Note that the minutes do not contain who-said-what
>>>>>> information
>>> (that
>>>>> can be
>>>>>> found elsewhere), but if you think there are some
>>>>>> important
>>> things
>>>>> missing,
>>>>>> or if you think something is wrong, please let the chairs
>>>>>> now.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Christer & Victor
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -------------------
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> IETF 90 - STRAW
>>>>>> 
>>>>>> 1150-1320 EDT    Friday Afternoon Session I
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Topic:     Agenda bashing, IETF Note Well and WG status
>>>>>> 
>>>>>> Presenter: Christer Holmberg (co-chair)
>>>>>> 
>>>>>> Slides: 
>>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf
>>>>>>
>>>>>>
>>>>>> 
Draft:     N/A
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> No issues were identified.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Topic:     Guidelines to support RTCP in B2BUAs
>>>>>> 
>>>>>> Presenter: Lorenzo Miniero
>>>>>> 
>>>>>> Slides: 
>>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf
>>>>>>
>>>>>>
>>>>>> 
Draft:     draft-ietf-straw-b2bua-rtcp
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that XR needs to be looked into, to see
>>>>>> whether
>>>>> something
>>>>>> needs to be covered in the draft.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that the terminology will be aligned with
>>>>>> the grouping-taxonomy draft. In case there are conflicts,
>>>>>> or other issues
>>>>> are
>>>>>> found, the STRAW community is requested to provide comments
>>>>>> on
>>> the
>>>>>> grouping-taxonomy draft.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was requested whether the draft should also cover RTP
>>>>>> specific
>>>>> issues. It
>>>>>> was indicated that the scope of the RTCP, and that we
>>>>>> should be
>>> very
>>>>> careful
>>>>>> about introducing RTP issues. It was recommended to talk to
>>>>>> Colin
>>>>> Perkins
>>>>>> whether he has any opinions regarding the need to cover
>>>>>> RTP.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I was asked how the document will relate to the work on
>>> multisource
>>>>>> optimisation taking place in AVTEXT.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that the text recommending man in the
>>>>>> middle
>>>>> functionality
>>>>>> for SRTP most likely will cause issues with IESG. After
>>>>>> the DTLS-SRTP discussion (see further down) it was
>>>>>> suggested that the RTCP draft
>>>>> should
>>>>>> not talk about SRTP.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Topic:     Taxonomy Discussion
>>>>>> 
>>>>>> Presenter: Lorenzo Miniero
>>>>>> 
>>>>>> Slides: 
>>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf
>>>>>>
>>>>>>
>>>>>> 
Draft:     All STRAW deliveries
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was agreed the STRAW shall use the terms in the avtext-
>>> grouping-
>>>>> taxonomy
>>>>>> document in preference to definitions elsewhere is they
>>>>>> are
>>>>> appropriate,
>>>>>> with a note indicating any differences in other documents
>>>>>> that
>>> may
>>>>> influence
>>>>>> understanding.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Topic:     STUN handling in B2BUAs
>>>>>> 
>>>>>> Presenter: Lorenzo Miniero (on behalf of the draft
>>>>>> authors)
>>>>>> 
>>>>>> Slides: 
>>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf
>>>>>>
>>>>>>
>>>>>> 
Draft:     draft-ram-straw-b2bua-stun
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that B2BUA, due to policy reasons, may
>>>>>> strip
>>>>> candidates
>>>>>> from SDP.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that B2BUAs must be very careful to not
>>>>>> perform
>>>>> actions
>>>>>> that will cause ICE mismatch.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The chair informed the community that a WG adoption request
>>>>>> will
>>> be
>>>>> sent out
>>>>>> within the upcoming weeks.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that the group needs to follow the ICE bis
>>>>>> work
>>>>> taking
>>>>>> place in MMUSIC, in case there will be any impacts on the
>>>>>> STRAW
>>>>> draft.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Topic:     DTLS-SRTP handling in B2BUAs
>>>>>> 
>>>>>> Presenter: Lorenzo Miniero (on behalf of the draft
>>>>>> authors)
>>>>>> 
>>>>>> Slides: 
>>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf
>>>>>>
>>>>>>
>>>>>> 
Draft:     draft-ram-straw-b2bua-dtls-srtp
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The presentation triggered lots of discussions and
>>>>>> controversy,
>>> as
>>>>>> it
>>>>> was
>>>>>> seen as an attempt to standardize MITM (man in the middle
>>>>> procedures). While
>>>>>> people did realize such actions take place in deployments,
>>>>>> they
>>>>> claimed that
>>>>>> IETF/STRAW should not standardize such procedures. It was
>>>>>> also
>>>>> indicated
>>>>>> that it goes against a number of BCP specifications, and
>>>>>> RFC
>>> 2804.
>>>>> Others
>>>>>> indicated that the purpose is to make sure that entities
>>>>>> doing
>>> this
>>>>> kind of
>>>>>> functionality do it in a way which does not cause
>>> interoperability
>>>>> problems,
>>>>>> which could cause people to not use security to begin
>>>>>> with.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> It was indicated that one possible way forward could be to
>>>>>> simply
>>>>> document,
>>>>>> in an informal delivery, how different vendors do things in
>>>>>> the
>>>>> network, but
>>>>>> in such case the vendors should also be listed in the
>>>>>> document.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Before the draft is adopted as a WG item, further
>>>>>> discussions
>>> need
>>>>>> to
>>>>> take
>>>>>> place. The ADs will help with finding the correct people
>>> (security,
>>>>> IESG,
>>>>>> etc) to involve in such discussions. The chair indicated
>>>>>> that the
>>>>> draft
>>>>>> implements a charter delivery, but that one possible
>>>>>> outcome will
>>> be
>>>>> to
>>>>>> remove/re-scope the charter delivery.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> _______________________________________________ straw mailing
>>>> list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/straw
>>> 
>>> 
>>> -- Lorenzo Miniero, COB
>>> 
>>> Meetecho s.r.l. Web Conferencing and Collaboration Tools 
>>> http://www.meetecho.com
>> 
>> _______________________________________________ straw mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/straw
> 
>