Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt

Laura Liess <laura.liess.dt@googlemail.com> Wed, 04 November 2015 10:52 UTC

Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482E51B2D20 for <dispatch@ietfa.amsl.com>; Wed, 4 Nov 2015 02:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXlbec0QTYoY for <dispatch@ietfa.amsl.com>; Wed, 4 Nov 2015 02:52:42 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F081B2D18 for <dispatch@ietf.org>; Wed, 4 Nov 2015 02:52:41 -0800 (PST)
Received: by qkcl124 with SMTP id l124so18232494qkc.3 for <dispatch@ietf.org>; Wed, 04 Nov 2015 02:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N5XK5RIBmjNsA+K2jBY7lj335Urn3KFdKP2AmBxo8Wg=; b=MK3nqA5oTncG4gFEZgyIEg+rfspvRnr5pDt3+Xa846gJwW4ezsoDBWfgdHReVb637p yxDZRk2ZL/E5JOfZ3mvEiVgJuCrBn5sSFJZeinXNSkJ5CYdvTYLsjzObiNqGeWpweCk6 DvJaBwlifCHrcz9lfTDlDtzw7GCh40K0U2u3KFa4qsHDHnQ54j4WDjuK7/1K5cq9OPuH Fedn1XYVZmVeaM6JS83xdwoZehRZcvZpr00M3X2x6RIRDHrsben+g+21pdWVn1Q3D8dm KRauZ617MGgOxo6T8oR6/xKRO3rGSZ0fNNeichHYiKO5LR8YYFfoBkIoZqVsvn/5fMZw 9AMQ==
MIME-Version: 1.0
X-Received: by 10.55.18.40 with SMTP id c40mr662910qkh.99.1446634361202; Wed, 04 Nov 2015 02:52:41 -0800 (PST)
Received: by 10.55.39.82 with HTTP; Wed, 4 Nov 2015 02:52:41 -0800 (PST)
In-Reply-To: <004101d116b6$1d3a3d30$57aeb790$@gmail.com>
References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> <CAKhHsXH73Uf7_dafmwwDk+CShHHfF7mMhsD1X1aVjXm7pjR8mg@mail.gmail.com> <004101d116b6$1d3a3d30$57aeb790$@gmail.com>
Date: Wed, 04 Nov 2015 11:52:41 +0100
Message-ID: <CACWXZj2xM=izmPAWGrR3YfUqsUqjs3B3hPjBwrsM4eHaLJ6O9Q@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Roni Even <ron.even.tlv@gmail.com>
Content-Type: multipart/alternative; boundary="001a114764d238339f0523b4cf6d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/-SsZ-OuJjqmvKolwgHcKNaC7x5g>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 10:52:44 -0000

Hi Roni,

[MMUSIC-SDP <https://tools.ietf.org/html/rfc5763#ref-MMUSIC-SDP>] is now
RFC 5939 and it seems to be a MUST for implementations of the  RFC 5763
(SRTP with DTLS).

At Deutsche Telekom we plan to connect SIP-PBXe in the near future using
SRTP with SDES.  We are not aware of any existing SIP-PBX which supports
RFC 5763, most existing SIP-PBXs suport different flavors of the
kaplan-draft. RFC 5763 seems to be too complex so that PBX vendors are not
willing to support it, at least in connection with SDES. This is also the
case for our service provider call control vendors.  So, a less complex
mechanism is needed for best effort SRTP.

Thank you
Laura

2015-11-04 5:05 GMT+01:00 Roni Even <ron.even.tlv@gmail.com>:

> Hi,
>
> In my view this approach contradict section 6.11 of RFC5763
>
>
>
> *Best Effort Encryption*
>
>
>
>
>
>    [RFC5479] describes a requirement for best-effort encryption where
>
>    SRTP is used and where both endpoints support it and key negotiation
>
>    succeeds, otherwise RTP is used.
>
>
>
>    [MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP
>
>    as an alternative.  This allows an offerer to express a preference
>
>    for SRTP, but RTP is the default and will be understood by endpoints
>
>    that do not understand SRTP or this key exchange mechanism.
>
>    Implementations of this document MUST support [MMUSIC-SDP
> <https://tools.ietf.org/html/rfc5763#ref-MMUSIC-SDP>].
>
>
>
>
>
> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Alan
> Johnston
> *Sent:* Wednesday, July 08, 2015 2:03 PM
> *To:* dispatch@ietf.org
> *Subject:* [dispatch] Fwd: I-D Action:
> draft-johnston-dispatch-osrtp-00.txt
>
>
>
> All,
>
>
>
> Many of us have been talking about "Best Effort SRTP" for many years, and
> there are a number of deployments.  In addition, the IMTC has recommended
> it, and the SIP Forum would like to recommend it in SIPconnect 2.0 which
> for the first time includes SRTP media.  With the publication of RFC 7435 (
> https://tools.ietf.org/html/rfc7435) the IETF has endorsed this approach
> as Opportunistic Security (OS), so it would be nice to bring standards in
> line with industry practice.
>
>
>
> Comments on the draft, "An Opportunistic Approach for Secure Real-time
> Transport Protocol (OSRTP)" and the best way forward are most welcome!
>
>
>
> - Alan -
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Mon, Jul 6, 2015 at 1:48 PM
> Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
> To: i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : An Opportunistic Approach for Secure Real-time
> Transport Protocol (OSRTP)
>         Authors         : Alan Johnston
>                           Bernard Aboba
>                           Andy Hutton
>                           Laura Liess
>                           Thomas Stach
>         Filename        : draft-johnston-dispatch-osrtp-00.txt
>         Pages           : 8
>         Date            : 2015-07-06
>
> Abstract:
>    Opportunistic Secure Real-time Transport Protocol (OSRTP) allows
>    encrypted media to be used in environments where support for
>    encryption is not known in advance, and not required.  OSRTP is an
>    implementation of Opportunistic Security, as defined in RFC 7435.
>    OSRTP does not require advanced SDP extensions or features and is
>    fully backwards compatible with existing secure and insecure
>    implementations.  OSRTP is not specific to any key management
>    technique for SRTP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announce%0d%0aInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>