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

[Eric Rescorla <[e-mail]>]

On Wed, Jul 8, 2015 at 11:42 AM, Alan Johnston <[e-mail]>
wrote:

> Hi Ekr,
>
> Thanks for the feedback.  See below.
>
> More feedback on #3 from others would be very helpful.
>
> - Alan -
>
> On Wed, Jul 8, 2015 at 1:00 PM, Eric Rescorla <[e-mail]> wrote:
>
>> 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.
>>
>
> Agreed - I'll put that in.
>
>
>>
>> 2. You probably shouldn't relax the need to send SDES over HTTPS because
>> 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, the problem is on my end.


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.
>>
>>
> 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?
>

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

-Ekr


>
>> -Ekr
>>
>>
>> On Wed, Jul 8, 2015 at 9:17 AM, Alan Johnston <[e-mail]>
>> wrote:
>>
>>> 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 <
>>> [e-mail]> wrote:
>>>
>>>> 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 <[e-mail]>
>>>> wrote:
>>>> > 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: <[e-mail]>
>>>> > Date: Mon, Jul 6, 2015 at 1:48 PM
>>>> > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
>>>> > To: [e-mail]
>>>> >
>>>> >
>>>> >
>>>> > 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
>>>> > [e-mail]
>>>> > 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
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > dispatch mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/dispatch
>>>> >
>>>>
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>>
>>
>