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

"Roni Even" <ron.even.tlv@gmail.com> Wed, 04 November 2015 04:06 UTC

Return-Path: <ron.even.tlv@gmail.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 930951A90D3 for <dispatch@ietfa.amsl.com>; Tue, 3 Nov 2015 20:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 8_Fb46ySkoT0 for <dispatch@ietfa.amsl.com>; Tue, 3 Nov 2015 20:06:07 -0800 (PST)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 37ED91A90C0 for <dispatch@ietf.org>; Tue, 3 Nov 2015 20:06:07 -0800 (PST)
Received: by padhx2 with SMTP id hx2so31397279pad.1 for <dispatch@ietf.org>; Tue, 03 Nov 2015 20:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=wbBENnHBRUOSg6zTtc9dUWwSN9Aqwjze/A8SFQRDCog=; b=vaA28KkqTZdKZ+nq0TPC+yhFpqFLM3eJHQ/IAT/VJ4hHhK8cvSxDTMvwfJNlT2HXpU FOywCgnxwXV2vNB0WzWuDnTEYCt8qwg0dpw4lHyyfw6u0Jesxhi2RDRftC01jItlmmYm zdu3C8X8dp906rYFKfE8/uMYJlcqWkon+05EPRNTgxFqKlagAdE9tDKfN+peZ+nZhQ3v ykbRAitlTM6qToUjxDWwUCyABfcciNlQ7DAP0tuthmc9ysYBUobXpt2kWt6x7MxNL2XI FY53o/XyKYkrAtl2KLt6lAWztBxy1cpaD6kTAhXH0p1aJKkQPxmE/VfHKGndaLRlLUK9 wgBg==
X-Received: by 10.68.213.99 with SMTP id nr3mr38034039pbc.107.1446609966888; Tue, 03 Nov 2015 20:06:06 -0800 (PST)
Received: from RoniPC (t20010c4000003032fd96360715ab615e.v6.meeting.ietf94.jp. [2001:c40:0:3032:fd96:3607:15ab:615e]) by smtp.gmail.com with ESMTPSA id ey2sm32240339pbd.77.2015.11.03.20.06.04 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Nov 2015 20:06:05 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Alan Johnston' <alan.b.johnston@gmail.com>, dispatch@ietf.org
References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> <CAKhHsXH73Uf7_dafmwwDk+CShHHfF7mMhsD1X1aVjXm7pjR8mg@mail.gmail.com>
In-Reply-To: <CAKhHsXH73Uf7_dafmwwDk+CShHHfF7mMhsD1X1aVjXm7pjR8mg@mail.gmail.com>
Date: Wed, 04 Nov 2015 06:05:56 +0200
Message-ID: <004101d116b6$1d3a3d30$57aeb790$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D116C6.E0C493D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF1yENlE6yHyEUvqkOwv7lEvrYecwFMUzNtnzd43UA=
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/NG0GCK0srLkKV1pEzCY-de2fUDI>
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 04:06:09 -0000

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 <https://www.ietf.org/mailman/listinfo/i-d-announce%0d%0aInternet-Draft> 
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt