Re: [AVT] Re: Changes in draft-ietf-avt-2833bis-13.txt

[Colin Perkins <[e-mail]>]

Okay, to summarise: there appears to be push back against making  
integrity protection via SRTP a "MUST" strength requirement. This is  
because:

1) SRTP keying is still in a state of flux, which makes  
implementation difficult

2) there are valid alternative architectures which do not use SRTP  
but which can provide appropriate security/integrity protection (e.g.  
with IPsec or DTLS)

As a result, I believe the draft needs revision to make SRTP a  
"SHOULD" level requirement.

Does this accurately state the consensus?

Colin




On 9 May 2006, at 22:05, Henning Schulzrinne wrote:
> Particularly since it is pretty clear that even a willing  
> implementor would find it very difficult today to build an  
> interoperable system that does SRTP key exchange. See the report  
> from the last SIPit for some evidence, as well as the various  
> discussions in the IETF of how to address this problem. Mandating  
> security that isn't ready for prime time seems kind of bold...
>
> Brian Rosen wrote:
>> I don't really know why I suddenly find myself in "what reality  
>> are you in
>> now?" mode, but the idea that anything over, say .1% of the SIP  
>> user agents
>> who implement 2833bis providing any sort of integrity protection  
>> outside of
>> the actual codec (the MUST) strikes me as more than a little wishful
>> thinking.
>> This is like marking a piece of dual carriage, limited access  
>> roadway with a
>> 15KM speed limit.  Yes, you can do that.  Yes, some law abiding  
>> citizens
>> will obey.  No, you won't get the behavior you are looking for in  
>> general.
>> I fully understand why we feel MUST is appropriate.  If I got to  
>> wave a
>> magic wand, I'd MUST a lot of security things into reality.  There  
>> is no
>> magic wand.  It isn't going to get implemented, MUST or no MUST.
>> If we were serious about it, we would define THE CODEC with integral
>> integrity protection.  That would have a much better chance of  
>> getting
>> implemented.
>> Now, I really, really, really would be tickled pink if SRTP was  
>> widely
>> implemented and widely deployed.  But I don't see that reality  
>> happening any
>> time soon, and MUSTing integrity protection here is, I think,  
>> pointless.
>> Unless of course we have an RFP in development for the protocol  
>> police
>> Brian
>> -----Original Message-----
>> From: Colin Perkins [mailto:[e-mail]] Sent: Tuesday, May  
>> 09, 2006 11:17 AM
>> To: David R Oran
>> Cc: Cullen Jennings; Magnus Westerlund; Pekka Nikander; IETF AVT  
>> WG; Tom-PT
>> Taylor; Michael A. Patton; [e-mail]; Sasha  
>> Vainshtein; Henning
>> Schulzrinne
>> Subject: Re: [AVT] Re: Changes in draft-ietf-avt-2833bis-13.txt
>> On 9 May 2006, at 15:15, David R Oran wrote:
>>> On May 9, 2006, at 9:49 AM, Colin Perkins wrote:
>>>> I agree with Magnus Westerlund: it makes sense to say one  
>>>> SHOULD  implement SRTP, since it provides appropriate security  
>>>> for many  environments, but we cannot absolutely mandate it,  
>>>> since there are  valid uses of RTP where SRTP isn't the right  
>>>> security solution.
>>>>
>>> I agree in general, but I'm having a hard time coming up with a  
>>> use  case where one is using rfc2833 (which goes to great lengths  
>>> to  save bandwidth) and where another security approach would be   
>>> superior to SRTP. However, I don't think this is worth obsessing   
>>> over given how much attention imlementors and deployers actually   
>>> pay to the nuances of these things.
>> I'm not sure I can see superior alternatives, but I wouldn't want  
>> to  prohibit use of IPsec or DTLS if they were suitable for the  
>> environment.
>>> Perhaps what we need to say is that the rfc2833 stream MUST have   
>>> some form of secure integrity protection, SHOULD have encryption   
>>> where sensitive data is carried (e.g. PINs as DTMF) and that  
>>> SRTP  is a natural fit for both of these functions.
>> That's a good phrasing, and in-line with previous payload formats.
>> Colin
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt


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