Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK)

[Bernard Aboba <[e-mail]>]

Stephen said:

"Yes, but is that actually in common use now for SIP?"

[BA] In "legacy SIP", no - but for implementations that shipped this
decade, yes.  For example, today's SIP handsets and ATAs routinely support
SIP over TLS and SRTP (even handsets selling for less than $150).  In the
PBX space, both protected signaling and SRTP are widely supported
features.  For example, signaling and media security can be configured on
Asterisk and Skype for Business (SfB) uses SIP over TLS (and SRTP) by
default, including for SIP trunks and emergency calls.   In WebRTC,
signaling over a protected channel (HTTPS or WSS) is strongly encouraged
and widely used.  So signaling and media security is much more widely
supported today than it used to be.  If a recent deployment is not using it
(except perhaps for a secured SIP trunk provider which can be hard to find)
it is most likely because they don't care, rather than their equipment not
supporting it.

"And if it is could STIR be used to get e2e authentication with hbh confid?"

[BA] With STIR, yes.  AFAICT, there is nothing under consideration in SLIM
that would interfere with STIR.

On Tue, Sep 29, 2015 at 8:30 AM, Stephen Farrell <[e-mail]>
wrote:

>
>
> On 29/09/15 16:08, Bernard Aboba wrote:
> > Stephen Farrell said:
> >
> > "As to charter language, I'd be happy if the charter said that there is
> > a need to ensure that language, like other annotations of calls, does
> > need to be something one can, in practice, protect, including at the
> > very least hop-by-hop confidentiality, but with some form of e2e
> > confidentiality being highly desirable"
> >
> > [BA] Everything in the SLIM charter could potentially be protectable
> either
> > via the transport (e.g. SIP over TLS)
>
> Yes, but is that actually in common use now for SIP? And if it is could
> STIR be used to get e2e authentication with hbh confid?
>
> > or in principle via the
> > (non-deployed) S/MIME mechanism.  However, at this point, I think it is
> > safe to say that deployment of S/MIME in SIP is probably a lost cause, so
> > referencing that in the Charter would represent the triumph of hope over
> > experience.
>
> Fully agree - if the charter claimed e2e was needed I'd have a block
> on that for wishful thinking.
>
> S.
>
>
> >
> > On Mon, Sep 28, 2015 at 3:13 PM, Stephen Farrell <
> [e-mail]>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> (Answering this one as it may provide my best entry point in the
> >> thread...)
> >>
> >> On 28/09/15 19:36, Gunnar Hellström wrote:
> >>> Some modality needs can have privacy and security implications that
> make
> >>> it important to not communicate them openly.
> >>
> >> Yes, the possibility that emergency services could make it harder
> >> to do the above is my main concern. And even moreso because the way
> >> in which the WG choose to annotate a call with language information
> >> could well be copied for other annotations. The upshot could be
> >> that the need to consider emergency calls results in there being
> >> no effective way to provide confidentiality (in particular) for these
> >> kinds of annotation.
> >>
> >>> Some modality requirement combinations may indicate that you have a
> >>> disability that may make it slightly easier to commit a crime to you.
> >>
> >> I think that's another issue, but less of a deal for me. There's also
> >> the related issue that one might in some places/cases be more
> >> discriminated  against the more (some of) one's language preference(s)
> >> are more public. (I can envisage specific real cases where a caller
> >> might be reluctant to reveal an ability to speak language-X because
> >> they fear that would result in worse treatment of the person, regardless
> >> of the treatment of the call.)
> >>
> >>>
> >>> Therefore it adds to the other usual reasons to keep the SIP exchange
> >>> privacy protected.
> >>
> >> But isn't the reality that many SIP messages are not protected?
> >>
> >> As to charter language, I'd be happy if the charter said that there is
> >> a need to ensure that language, like other annotations of calls, does
> >> need to be something one can, in practice, protect, including at the
> >> very least hop-by-hop confidentiality, but with some form of e2e
> >> confidentiality being highly desirable (maybe based on TOFU or similar
> >> in cases where multiple calls may occur between the same parties).
> >> I'm not fussed about how exactly that is stated so long as the result
> >> is that the kind of can't-be-secured solution that might be attractive
> >> for emergency calling is not considered by itself sufficient.
> >>
> >> Or, if my impression of VoIP is outdated and in fact securing this
> >> kind of data is now routinely done, then I would agree that there
> >> might not be a need for specific charter text. (In that case, some
> >> pointers to descriptions of networks where that is the case would
> >> be useful.)
> >>
> >> Lastly, now that I'm thinking about it a bit more, it is not clear
> >> to me if the security and privacy requirements for the two different
> >> applications are considered the same or not. Either way, it could
> >> be good to be explicit about that in the charter too.
> >>
> >> Hope that helps,
> >> S.
> >>
> >>
> >>>
> >>> /Gunnar
> >>>
> >>> -----------------------------------------
> >>> Gunnar Hellström
> >>> Omnitor
> >>> [e-mail]
> >>> [phone]
> >>>
> >>> Den 2015-09-28 kl. 17:35, skrev Bernard Aboba:
> >>>> Stephen --
> >>>>
> >>>> I happen to share your concern about potential security and privacy
> >>>> issues with emergency services architectures.  For example, I have
> >>>> reviewed proposals for state NG911 architectures that may not function
> >>>> well if traffic is encrypted (e.g. they specify network-based
> >>>> intrusion detection systems that assume access to cleartext).
> >>>>
> >>>> That said, it is not clear to me how language negotiation makes that
> >>>> problem worse (or better).  Presumably the specifications referred to
> >>>> in the Charter would be compatible with IETF security standards (e.g.
> >>>> SIP over TLS, Secure WebSockets, SRTP,  DTLS/SRTP, etc.) so that an
> >>>> emergency call made using the SLIM specifications could be secured.
> >>>>
> >>>> Since SLIM is not chartered to focus on security and privacy issues
> >>>> relating to emergency services (or email), I'm not sure what more can
> >>>> be done within this Charter to address your concern.
> >>>>
> >>>> ========================================
> >>>>
> >>>>
> >>>>   [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with
> >> BLOCK)
> >>>>
> >>>> "Stephen Farrell" <[e-mail]
> >>>> <mailto:[e-mail]>> Thu, 17 September 2015 13:54
> >>>> UTCShow header
> >>>> <https://mailarchive.ietf.org/arch/search/?email_list=slim&qdr=y#>
> >>>>
> >>>> Stephen Farrell has entered the following ballot position for
> >>>> charter-ietf-slim-00-06: Block
> >>>>
> >>>> 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.)
> >>>>
> >>>> The document, along with other ballot positions, can be found here:
> >>>> https://datatracker.ietf.org/doc/charter-ietf-slim/
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>> BLOCK:
> >>>> ----------------------------------------------------------------------
> >>>>
> >>>> I wonder if the security and privacy considerations associated
> >>>> with email and WebRTC are so totally different that it might really
> >>>> be better to handle language separately for each.
> >>>>
> >>>> I'm also a bit leery of emergency calls being used to justify
> >>>> handling language in a way that exposes privacy unnecessarily.
> >>>> (I don't mean that language preference is highly sensitive,
> >>>> as it's usually not, but I think there is a meme where emergency
> >>>> services are used to justify doing all sorts of stuff without
> >>>> security, so the call is more likely to get through.)
> >>>>
> >>>> The first bit was a comment I made back in July and I don't
> >>>> think I saw any response. (But I may have forgotten.)
> >>>>
> >>>> We can chat about it on the call.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> SLIM mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/slim
> >>>
> >>>
> >>
> >
>