[AVT] Re: TLS-SRTP internet draft as a WG item in AVT

[David McGrew <[e-mail]>]

Hi Cullen,

On Jun 26, 2007, at 3:13 PM, Cullen Jennings wrote:

>
> I have no problem with that milestone if that is what you decide  
> on ...
>
> One question about it - would calling it "DTLS-SRTP" be better than  
> "TLS-SRTP"? I don't care but if we were going to change the name,  
> this would be the right time to do that.

I'm name agnostic.  Whatever Eric and/or the TLS folks say is the  
right TLS terminology.   I said TLS-SRTP here because that's the name  
of the current draft, though lots of people (including me) have used  
the other name.

David

>
> Cullen <with my AD hat on>
>
>
> On Jun 26, 2007, at 2:05 PM, David McGrew ((mcgrew)) wrote:
>
>> Hi Colin,
>>
>> how does this milestone sound?  "December 2007 Submit TLS-SRTP for
>> Proposed Standard"   Perhaps I'm aggressive in expecting us to have
>> the draft ready before the Vancouver meeting; we could push it back
>> to March 2008.
>>
>> David
>>
>> On Jun 26, 2007, at 4:00 AM, Colin Perkins wrote:
>>
>> > Hi David,
>> >
>> > What milestone(s) do you see this work adding to the AVT charter,
>> > if accepted?
>> >
>> > Colin
>> >
>> >
>> >
>> >
>> > On 20 Jun 2007, at 21:54, David McGrew wrote:
>> >> Hi Colin, Roni, and Tom,
>> >>
>> >> I would like to ask that draft-mcgrew-tls-srtp be taken up as a
>> >> working group action item in AVT, as part the plan for carrying
>> >> forward the RTPSEC work (as per Cullen's email of May 11 to the
>> >> rtpsec list).   I would like to continue on as an author of this
>> >> work, and Eric as agreed to do the same.  There are a small number
>> >> of minor open issues which I expect can be wrapped up quickly:
>> >>
>> >> 1.  The draft needs to be clarified so that, in the Symmetric RTP
>> >> case, only one handshake is needed.
>> >>
>> >> 2.  Section 3.6.2.1 needs to be resolved to either decide on a
>> >> "symmetry breaking" rule or not.  It may be desirable to have such
>> >> a rule to handle cases in which the signaling system can't tell a
>> >> device which should act as client and which should act as
>> >> server.   This would allow opportunistic probing, i.e. a TLS-SRTP
>> >> implementation could attempt to find out whether another RTP
>> >> implementation supports TLS-SRTP, absent any help from signaling.
>> >>
>> >> 3.  The "single DTLS session per SRTP session" issue needs to be
>> >> decided, and Appendix A should then be removed from the draft.
>> >>
>> >> 4.  It should be decided to use, or not to use the "TLS
>> >> Extractor", and Section 3.3 should be rewritten accordingly.
>> >>
>> >> 5.  The duplicate list of srtp profiles needs to be eliminated.
>> >>
>> >> Best regards,
>> >>
>> >> David
>> >>
>> >> --
>> >>
>> >> p.s. - here's the AVT-specific part of Cullen note, so that you
>> >> don't need to dig it out of your mailbox: "AVT - Describe how DTLS
>> >> is used to key SRTP and how SRTP is used in combination with DTLS.
>> >> This includes the issues of multiplexing DTLS and SRTP on one
>> >> port. draft-mcgrew-tls-srtp will be the starting draft for this."
>> >
>> >
>> >
>> > --
>> > Colin Perkins
>> > http://csperkins.org/
>>
>>

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt