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

From: Alan Johnston <[email-masked]>
Date: Wed, 8 Jul 2015 06:02:47 -0500

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: <[email-masked]>
Date: Mon, Jul 6, 2015 at 1:48 PM
Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
To: [email-masked]

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jul 2015 09:14:53 -0700

How does this differ from:
https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01

On 8 July 2015 at 04:02, Alan Johnston <[email-masked]> wrote:
> 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
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 8 Jul 2015 11:17:47 -0500

Hi Martin,

It is the version of the draft that is actually implemented and used.
There are also a few slight differences due to the way that Opportunistic
Security is defined.

- Alan -

On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson <[email-masked]>
wrote:

> for

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jul 2015 11:00:53 -0700

This seems like a good idea.

I have three comments:

1. You should forbid the answerer from sending back two types of
keying parameters (e.g., a=crypto and a=fingerprint) because that creates
confusion.

2. You probably shouldn't relax the need to send SDES over HTTPS because
the security properties there are still fairly bad.

3. I would suggest that failure to negotiate a secure channel (for DTLS-SRTP
and ZRTP) should lead to media failure not falling back. There's basically
no good reason for this to fail and it seems like it will make diagnosing
issues easier.

-Ekr

---

From: Alan Johnston <[email-masked]>
Date: Wed, 8 Jul 2015 13:42:52 -0500

Hi Ekr,

Thanks for the feedback.  See below.

More feedback on #3 from others would be very helpful.

- Alan -

> keying parameters (e.g., a=crypto and a=fingerprint) because that creates

Agreed - I'll put that in.

> the security properties there are still fairly bad.

Right.  I tried to say that in the Security Considerations: "For SDP
Security Descriptions key agreement [RFC4568], an authenticated signaling
channel does not need to be used with OSRTP if it is not available,
although an encrypted signaling channel must still be used."  Did I get it
wrong?

> no good reason for this to fail and it seems like it will make diagnosing
I was on the fence about this one.  Agree that it shouldn't happen for
DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY
modes.  Should that really fail the whole session?

>> On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson <[email-masked]
>> > wrote:
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Jul 2015 12:50:20 -0700

On 8 July 2015 at 11:42, Alan Johnston <[email-masked]> wrote:
> DTLS-SRTP or ZRTP, but I could imagine it happening for certain MIKEY modes.
> Should that really fail the whole session?

At the point that you have established that both peers support a
common baseline, accepting downgrade from that baseline removes any of
the benefit that an opportunistic upgrade provided.  An attacker that
can't attack your signaling now has a chance to downgrade you.

I've no good information on what MIKEY mode might fail and how, but
that seems like a problem you could address specifically without
weakening other options.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 Jul 2015 16:25:11 -0400

> can't attack your signaling now has a chance to downgrade you.

+1

The idea is "opportunistic" in the sense of "if both peers can
negotiate in signaling", not in the sense of "keep going if the
security fails".

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jul 2015 13:30:06 -0700

> although an encrypted signaling channel must still be used."  Did I get it

No, the problem is on my end.

> modes.  Should that really fail the whole session?

I don't have a strong opinion about MIKEY on this one.

-Ekr

>>> On Wed, Jul 8, 2015 at 11:14 AM, Martin Thomson <
>>> [email-masked]> wrote:
>>>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 9 Jul 2015 20:18:31 -0500

Martin,

That makes perfect sense.  I'll change it in the next version to fail the
session if the key agreement fails.

- Alan -

On Wed, Jul 8, 2015 at 2:50 PM, Martin Thomson <[email-masked]>
wrote:

> modes.